Can't post comment with content "0" (string with zero)

[Cawa-93]

If you try to post a comment with content "0" (string with zero), the server will respond in error as if the content was missing.

Request code. Some headings are omitted as they are not important. Authorization uses plugin "JWT Authentication for WP-API".

fetch("http://example.com/wp-json/wp/v2/comments", {
  "headers": {
    "authorization": "Bearer ...",
    "content-type": "application/json"
  },
  "method": "POST",

  "body": `{
    "content":"0",

    "post":123,
    "parent":null,
    "author":1,
    "status":"approved",
    "date_gmt":"2019-02-09T14:47:12.000Z"
  }`,

});

Response:

{
  "code":"rest_comment_content_invalid",
  "message":"Invalid comment content.",
  "data":{"status":400}
}

<!--
Hi there! Thanks for contributing to WordPress!

Pull Requests in this GitHub repository must be linked to a ticket in the WordPress Core Trac instance (​https://core.trac.wordpress.org), and are only used for code review. No pull requests will be merged on GitHub.

See the WordPress Handbook page on using PRs for Code Review more information: ​https://make.wordpress.org/core/handbook/contribute/git/github-pull-requests-for-code-review/

If this is your first time contributing, you may also find reviewing these guides first to be helpful:

• FAQs for New Contributors: ​https://make.wordpress.org/core/handbook/tutorials/faq-for-new-contributors/
• Contributing with Code Guide: ​https://make.wordpress.org/core/handbook/contribute/
• WordPress Coding Standards: ​https://make.wordpress.org/core/handbook/best-practices/coding-standards/
• Inline Documentation Standards: ​https://make.wordpress.org/core/handbook/best-practices/inline-documentation-standards/
• Browser Support Policies: ​https://make.wordpress.org/core/handbook/best-practices/browser-support/
• Proper spelling and grammar related best practices: ​https://make.wordpress.org/core/handbook/best-practices/spelling/

-->

Trac ticket: https://core.trac.wordpress.org/ticket/49903#ticket

empty may have been anticipating one or both of _not set_ and _empty string_. Personally, I think rather than handling the exceptions, it could be framed as more targeted to the specific anticipated problem values.

`php

if ( ! isset( $prepared_commentcomment_content? )

$prepared_commentcomment_content? === ) {

`

Or, if comment_count is always set, and doesn't need to be checked:

`php
if ( $prepared_commentcomment_content? === ) {
`

[TimothyBlynJacobs]

Thanks for the ticket @Cawa-93!

It looks like wp_handle_comment_submission strictly rejects an empty string which would allow a comment of 0.

Originally, the REST API comments controller did the same check, but in #38720 this was loosened to an empty check. Looking at the ticket, I'm not entirely sure why that part of the change was necessary.

Yeah, I think it would be better to do an isset check and looking for an empty string exactly. That matches wp_handle_comment_submission.

@TimothyBJacobs I agree with you. I didn't think about matching the behavior in the wp_handle_comment_submission. Then, perhaps, should the same hook be added to allow empty comments?

`php
$allow_empty_comment = apply_filters( 'rest_allow_empty_comment', false, $prepared_comment );

$missing_content = ! isset( $prepared_commentcomment_content? )

=== $prepared_commentcomment_content?

if ( $missing_content && ! $allow_empty_comment ) {

return new WP_Error(

'rest_comment_content_invalid',
( 'Invalid comment content.' ),
array( 'status' => 400 )

);

}
`

Yeah I think it'd be great to make sure we realign ourselves with wp_handle_comment_submission.

Another related ticket: https://core.trac.wordpress.org/ticket/43177

[TimothyBlynJacobs]

This isn't an exact duplicate of #43177, but they'll both be the same fix. So closing as duplicate.

Fixed in 1e030c4062f87b3881012d977a9adc3ade9c63b9.