HTML entities in category and tag elements

[lavamind]

The script wp-admin/includes/export.php creates CDATA blocks for category and tag data which contain HTML entities. Normally, these characters should appear un-encoded in the CDATA blocks, see #4321.

I suspect this problem may have been considered at some point, but currently the line in question is commented out : ​http://core.trac.wordpress.org/browser/trunk/wp-admin/includes/export.php?rev=9148#L102

The solution, I think, would be to replace that comment with html_entity_decode($str)

[c3mdigital]

Patch refresh

[c3mdigital]

Refreshing patch.

[ianmjones]

Patch refreshed to apply cleanly on current repository layout.

[ianmjones]

Confirmed and tested refreshed patch (14584v3.diff) on 4.1-alpha-30000.
Tested import unaffected by change to more compliant CDATA format.

[ianmjones]

Patch refreshed for 4.2

[ianmjones]

Refreshed for 4.6, replaced commented out red-herring code with explanation of why encoded html entities are in CDATA.

[ianmjones]

The importer requires that the CDATA contain data in the same format that will be inserted into the database, which means html entity encoded characters are required.

[earnjam]

Replying to ianmjones:

The importer requires that the CDATA contain data in the same format that will be inserted into the database, which means html entity encoded characters are required.

So I guess changing it would break the importer. In order to patch in core, we'd have to also update the importer plugin to account for this.

This commented out line has been there since cats/tags were first included in exports. See #3403.

Given how little impact this appears to have had in 14 years, I don't think we should change it. We could clean it up a bit by removing the commented out code and explain why they are not decoded, like 14584.patch​ does. But if we do that, I would clarify the wording a bit that it's dependent on the importer.