Opened 13 years ago
Last modified 3 years ago
#14584 reopened defect (bug)
HTML entities in category and tag elements
| Reported by: |
|
Owned by: | |
|---|---|---|---|
| Milestone: | Priority: | normal | |
| Severity: | normal | Version: | 2.1 |
| Component: | Export | Keywords: | has-patch |
| Focuses: | Cc: |
Description
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)
Attachments (5)
Change History (12)
#2
@
9 years ago
- Resolution set to worksforme
- Status changed from new to closed
Confirmed and tested refreshed patch (14584v3.diff) on 4.1-alpha-30000.
Tested import unaffected by change to more compliant CDATA format.
@
7 years ago
Refreshed for 4.6, replaced commented out red-herring code with explanation of why encoded html entities are in CDATA.
#6
follow-up:
↓ 7
@
7 years ago
- Keywords needs-refresh removed
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.
#7
in reply to:
↑ 6
@
3 years ago
- Keywords needs-testing removed
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.
Patch refresh