sanitize_title_with_dashes fatal error when query var value is an array in php 8

[mouhdev]

Using latest WordPress development version 6.3-alpha-55505-src, when submitting a form with field values that are array, and the array key is one of WordPress query vars, that causing sanitize error for 'post_name' parameter in get_posts function.

Example to replicate:

• make sure to register custom post type E.g custom_post_type.
• submit the following form on your test WordPress website.

  <form method="post" action="">
  <input type="text" name="custom_post_type['post_title']" value="This is a test post">
  <input type="submit" value="Send">
  </form>
  

[hellofromTonya]

I removed 6.2 as the Version as the PHP Warning (on < PHP8) or Fatal Error (on >= PHP 8.0) happens on WordPress versions older than 6.2.

[hellofromTonya]

Hello @mouhdev,

Welcome to WordPress Core's Trac!

I'm curious about the example code:

<form method="post" action="">
<input type="text" name="custom_post_type['post_title']" value="This is a test post">
<input type="submit" value="Send">
</form>

What is the purpose of the form? 'post_title' is not a valid label or arg for a custom post type (​see developer docs). I'm confused about the scenario where a form's input would have a 'name' in the form of a custom post type's 'post_title'.

I'm asking to understand the real world scenario of the example to evaluate if something should happen to catch and process the form input as an array before the WP_Query code in question.

[hellofromTonya]

Reviewed this ticket to determine if it is an incompatibility with PHP 8.0 and should be listed in the known incompatibilities for WP 6.3.

Findings: no, this is not seem to be an incompatibility with PHP 8.0. It might be a doing it wrong or potentially a case for further defensive coding. Thus, the php-compatibility focus should not be added to the ticket.

[peterwilsoncc]

Replying to hellofromTonya:

It might be a doing it wrong or potentially a case for further defensive coding. Thus, the php-compatibility focus should not be added to the ticket.

I think this is similar to #56311 in which site visitor input via the URL/form data also triggers a notice (in the other ticket's case, it's an out of range week, example.com/2022/?w=506).

I think it's a case in which a bunch of defensive coding needs to be added to the WP class to validate data before sending it to WP_Query. Throwing a notice in those cases isn't helpful to the site developer as they have no control over visitor data submitted via a URL.

[mouhdev]

@hellofromTonya An alternative way to reproduce this is to put the custom post type key as query var (array) and try to load the post type via post slug, for example, ​http://example.com/?custom_post_type[]=test+post

This will generate a fatal error if the query_var for the registered post type is true as default, whether it was a hierarchical post type or not.

An example of this could be a form to create a custom post or whatever in the front end, and having post fields as array keys of custom post type. Or it can be a name similarity when parsing the request.

<form method="post" action="">
 <label for="post-title"></label>
 <input type="text" id="post-title" name="custom_post_type[post_title]" value="">
 <label for="post-content"></label>
 <input type="text" id="post-content" name="custom_post_type[post_content]" value="">
 <input type="submit" value="Publish">
</form>