REST API: Updating comment via REST does not respect allow_empty_comment filter

[kadamwhite]

When updating a comment via the REST API we currently fail comment updates in the WP_REST_Comments_Controller::update_item method if the updated content is empty(). On REST comment creation and within traditional comment updates via wp_handle_comment_submission we respect the return value of the allow_empty_comment filter and permit empty comment content when this filter is set.

My understanding of the history here is that allowing empty comments permits moderation by allowing inappropriate comment content to be deleted without removing the content entity itself; or alternatively (and as discussed in #43177) to permit comments to be saved which only contain metadata and do not have any "content" in the traditional sense.

This may also unblock certain actions for editorial comments within the block editor.

[kadamwhite]

Note from @rmccue, one concept in this endpoint (and the API generally) is that we should support sending partial documents for updates -- if the content is empty that could indicate "no update". In other words, an empty string may signal different intent than an unset key

[kadamwhite]

Added link in description to #62684 which (most-recently that I can find) documents that editing a comment to be empty is desired functionality.

Originally proposed by @adamsilverstein in ​https://github.com/WordPress/wordpress-develop/pull/9988, this PR adds tests to his fix while also resolving a potential logical error which could prevent updates to unrelated comment object properties.

• #9988 as written causes an error in some existing unit tests (including my newly-added one for this ticket), Undefined array key "comment_content", because the controller expects to be able to process _partial objects_: For example, you can pass an object in a PUT which changes the author but alters no other fields.
• We therefore only want to check the content for emptiness (and verify using the filter whether that is allowable) when the property has been passed back.
• Currently, the only path through which check_is_comment_content_allowed() can be called is during the create_item method, which ensures comment_content is initialized to '' if not present — this should not result in any change to existing behavior on comment creation or updates.

Trac ticket: [](https://core.trac.wordpress.org/ticket/64049)

[kadamwhite]

@TimothyBlynJacobs @ryan I've refreshed @adamsilverstein's patch here and added a test to validate that content updates respect the filter value. Thoughts?

This was proposed as part of the block editor commenting initiative, but to me it feels like a good inconsistency to fix regardless of the ongoing work on that feature.

[TimothyBlynJacobs]

This makes sense to me!

[kadamwhite]

In 60937:

REST API: Allow comment content to be updated to empty when allow_empty_comment filter returns true

This filter was already respected during comment creation, but not updates. This was inconsistent between POST and PUT, and prevented erasing content of moderated comments via the API without deleting the entire object.

Props adamsilverstein, kadamwhite, davidbaumwald, mukesh27, timothyblynjacobs.
Fixes #64049.