Make WordPress Core

Opened 3 years ago

Last modified 3 years ago

#50648 new defect (bug)

Different behavior for default category term with editors

Reported by: enricosorcinelli's profile enrico.sorcinelli Owned by:
Milestone: Awaiting Review Priority: normal
Severity: normal Version: 5.5
Component: Editor Keywords:
Focuses: Cc:

Description

During some tests related to #43517 I found a different behaviors on how default category term is handled with block/classic/quick/REST API/XML-RPC API editors.
I haven't found similar ticket on trac, so sorry in advance if it's a duplicate and you have already experienced a similar thing

Here are the test I've done with table of results.

New post with empty category taxonomy

Editor category result
BlockUncategorized
ClassicUncategorized
QuickUncategorized
REST APIUncategorized
XML-RPC APIUncategorized

Updating post by removing all category terms

Editor category result Notes
Block
ClassicUncategorized
QuickUncategorized
REST APIThis can be done by explicitly setting categories key to an empty string.
XML-RPC APIUncategorizedThis cannot be done through XML-RPC interface

Updating a post there doesn't has any category terms (and without changing that taxonomy)

Editor category result
BlockUncategorized
ClassicUncategorized
QuickUncategorized
REST APIUncategorized
XML-RPC APIUncategorized

This different behaviour seems to be related to block editor that send taxonomy fields values only if they have been changed.
And if you remove all categories, block editor will send explicitly an empty array: REST post controller calls wp_set_object_term() a second time in handle_terms() method: so it's the why the empty array will remove all terms.
This isn't currently possible with classic/quick/XML-RPC API editors.

The problem is with custom taxonomies as well.

Attachments (1)

50648.patch (3.4 KB) - added by enrico.sorcinelli 3 years ago.

Download all attachments as: .zip

Change History (7)

This ticket was mentioned in Slack in #core-editor by enrico.sorcinelli. View the logs.


3 years ago

This ticket was mentioned in Slack in #core-restapi by enrico.sorcinelli. View the logs.


3 years ago

#4 @enrico.sorcinelli
3 years ago

All administration post category term stuffs relies on default category settings: by creating or updating post without category terms and deleting a category terms as well, the default post category will be auto-added .
Block editor change this behavior by allowing to set empty terms disregarding the Settings > Writing > Default post category user choice.
This creates an inconsistence across the different editors.

This simple patch aims to fix that.
I added a --None-- option with a 0 value in order to explicitly allow posts with empty terms:

https://gist.githubusercontent.com/enrico-sorcinelli/627c125e3f45105b9a5f59cc917eddb5/raw/feea7256209d484cad1d3db2d56d18f8cfe20645/settings-writing.png

The REST posts controller adds (or not) the default category term according to the settings above.

This way, all editors (quick/classic/block) can empty category terms, as well custom taxonomies terms.

This ticket was mentioned in Slack in #core by enrico.sorcinelli. View the logs.


3 years ago

#6 @johnjamesjacoby
3 years ago

In addition to category, these core taxonomies also have defaults:

  • email_category
  • link_category
  • post_format

Because of this, I believe this patch would benefit from an update to replace the default_category check with something more inline with what is in the map_meta_cap::delete_term check, where both 'default_' . and 'default_term_' . are checked concatenated with $taxonomy->name.

I also suspect adding support for show_option_none and option_none_value is out of scope, even though I do support the idea, and have a hunch (but no evidence) that adding these will probably break stuff 🤣

Note: See TracTickets for help on using tickets.