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

[josephscott]

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.

[Denis-de-Bernardy]

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.

[janeforshort]

Punting due to feature freeze. Reconsider with next release.

[Denis-de-Bernardy]

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

[solarissmoke]

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

[nacin]

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.

[johnbillion]

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