Gutenberg: Different behavior for default category term with editors

[enrico-sorcinelli]

I haven't found similar issue on archive so sorry in advance if it's a duplicate and you have already experienced a similar thing

Describe the bug
It seems that there is a different behavior on how default category term is handled with block/classic/quick/REST API/XML-RPC API editors.
In fact., with block editor you could remove all category terms (default included), but saving again the post after modifying other data, the default term will be set again.

To reproduce

Here are the test I've done with results.

• Create a post with empty category taxonomy

  |Editor|category result|
  |---|---|
  |Block|Uncategorized|
  |Classic|Uncategorized|
  |Quick|Uncategorized|
  |REST API|Uncategorized|
  |XML-RPC API|Uncategorized|

This case is OK and is the same with all editors (I've included for completeness).

• Update a post by removing all category terms

  |Editor|category result|Notes|
  |---|---|---|
  |Block|—|
  |Classic|Uncategorized|
  |Quick|Uncategorized|
  |REST API|—|This can be done by explicitly setting categories key to an empty string.|
  |XML-RPC API||This 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|
  |---|---|
  |Block|Uncategorized|
  |Classic|Uncategorized|
  |Quick|Uncategorized|
  |REST API|Uncategorized|
  |XML-RPC API|Uncategorized|

Also in this case we have the same results with all editors.
But I expect that block editor will leave the category empty.

Expected behavior
This different behavior 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.

Depending on which side you look, it could not be not really a bug but a different behavior that should be the same for all editors

Editor version

• WordPress version: 5.4.2, 5.5 beta 2

I also created trac ticket.

[youknowriad]

From what I can tell, it seems like the REST API kind of considers that there should be at least a category selected, so all "save" request "fill" the "categories" returned if empty, but there's an inconsistency when the user explicitly sends an empty "categories" set, In this case the returned value is still empty.

I think that's potentially a bug in the REST API.

• We should either consider the empty list possible in all requests
• Or we should always fill the "categories" with the default value, no matter what "save" request is made.

[TimothyBJacobs]

Example request flow.

1. Create the post.

POST /wp/v2/posts?_fields=id,categories
{
    "title": "Test Post",
    "content": "Test Content"
}

{
  "id": 2089,
  "categories": [
    1
  ]
}

1. Remove categories.

PUT /wp/v2/posts/2089?_fields=id,categories
{
    "categories":[]
}

{
  "id": 2089,
  "categories": []
}

1. Get item.

GET /wp/v2/posts/2089?_fields=id,categories

{
  "id": 2089,
  "categories": []
}

1. Make an unrelated update.

PUT /wp/v2/posts/2089?_fields=id,categories
{
  "title": "My New Title"
}

{
  "id": 2089,
  "categories": [
    1
  ]
}

---

This is coming from wp_insert_post() which is enforcing a default category when wp_update_post is called.

https://github.com/WordPress/wordpress-develop/blob/d2a1fb965d1feeb337eb96a69d8d0a66fbd9581d/src/wp-includes/post.php#L3728

[enrico-sorcinelli]

This happens because block editor send taxonomies fields values only if they have been changed. Classic/quick editors send them always, that's why this inconsistency doesn't happen in that case.
So, IMHO that's not a potentially REST API bug but t's a different block editor behavior compared to those editors.

I think that first we should standardize the auto-adding of a category when none set across the different editors.

[enrico-sorcinelli]

Relating to this issue I just submitted a patch on trac ticket in order to propose a simple solution.