HTML description property of term in WP_REST_Terms_Controller lacks display filters

[davecpage]

Working with the REST API i've noticed that with terms, either from custom taxonomies or default categories and tags, their descriptions are different within REST requests compared to outputting within a theme template.

Tracking it down and I've noticed that within themes these term descriptions are having term_description filters applied, whereas within WP_REST_Terms_Controller the term description is used as is from the database.

At its most basic example a user can add HTML to a term description (either manually or via a plugin that adds a visual editor), and paragraphs will be applied for a theme, but not for the REST requests.

But the schema for Terms says that it's the HTML description of the term, which IMO is slightly wrong without all the term description filters.

Comparing to the WP_REST_Posts_Controller it further raises the question, should the Term controller be providing a raw and rendered version of the term description to match Post content? Or should the filters simply be added as it's a smaller change?

[joehoyle]

Hmm well spotted. I don't think applying the filter on the current field would make sense as we run into the lossy issue of pushing the rendered value back to the DB.

I think to be backwards compatible we'd need to add a new field description_rendered which I'm not wild about. I'm interested in what @rmccue thinks here. I think we need to define a general precedent (which maybe we already have that I'm not aware of!) as this kind of problem could crop up again.

[jnylen0]

Ideally the term description should have raw and rendered properties, see #38679 for a similar change that we made before 4.7.

[TimothyBlynJacobs]

How terrible an idea would be not applying the filter when in an edit context?