WordPress.org

Make WordPress Core

Opened 5 years ago

Closed 11 months ago

#8002 closed enhancement (duplicate)

Term names and descriptions are being encoded before being saved in the database

Reported by: josephscott Owned by:
Milestone: Priority: normal
Severity: normal Version:
Component: Taxonomy Keywords: close
Focuses: Cc:

Description

When a new term (tag or category) name or description is saved with an & in it, that gets stored in the database as &. The correct thing to do would be to store the value original value in the database and encode it when displaying it in certain contexts, like on the web. This would allow for the APIs (XML-RPC and AtomPub) to be able to expose the the non-encoded value.

I followed the code path to the sanitize_term_field function in wp-includes/taxonomy.php. Here the term values get different filters applied depending on the context. In the case of saving a new term the 'db' context is used and applies the 'pre_term_name' filter, which by default includes strip_tags, trim, wp_filter_kses and wp_specialchars.

It's wp_filter_kses that is changing the & to & before getting saved, but if that's removed then wp_specialchars will also try to encode it. As a test I saved a new term with a real & in the database by removing the wp_filter_kses and wp_specialchars filters for pre_term_name. This worked, but caused another problem because the & was no longer showing as & on the web. The assumption being that since it was encoded before being saved, no reason to try and encode it when displaying it on the web.

This will require targeted work on fixing the save and display filters. Unfortunately because of the timing we'll have to push this work to after 2.7 is released.

Change History (8)

comment:1 alexdunae5 years ago

  • Cc alexdunae added

comment:2 Denis-de-Bernardy5 years ago

wontfix imo. it's a complete workflow change, and existing installs are already relying on it to be encoded in the first place. the likelihood is that what's really needed is some kind of decode function to expose the non-encoded versions -- and the php built-in functions should work fine for this.

comment:3 janeforshort5 years ago

  • Milestone changed from 2.8 to Future Release

Punting due to feature freeze. Reconsider with next release.

comment:4 Denis-de-Bernardy5 years ago

I'm pretty sure there is a dup of this one somewhere

comment:5 Denis-de-Bernardy5 years ago

  • Keywords needs-patch added
  • Type changed from defect (bug) to enhancement

comment:6 solarissmoke3 years ago

  • Keywords close added; needs-patch removed

Still stored in the database as & but you can fetch it in raw context where it is converted back.

comment:7 nacin3 years ago

It's lame this occurs. We should try to fix it, and I do think it's doable if we tweak the save/display filters.

comment:8 johnbillion11 months ago

  • Milestone Future Release deleted
  • Resolution set to duplicate
  • Status changed from new to closed

Gonna close this as a dupe of #11311 which has a little more discussion and mentions other areas where the encoding occurs.

Note: See TracTickets for help on using tickets.