Opened 22 months ago
Last modified 6 days ago
#58234 new defect (bug)
sanitize_title_with_dashes fatal error when query var value is an array in php 8
Reported by: |
|
Owned by: | |
---|---|---|---|
Milestone: | Awaiting Review | Priority: | normal |
Severity: | normal | Version: | |
Component: | Query | Keywords: | has-patch needs-unit-tests php80 reporter-feedback |
Focuses: | Cc: |
Description
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>
Attachments (1)
Change History (9)
#1
@
22 months ago
- Summary changed from sanitize_title_with_dashes fatal error when query var value is an array to sanitize_title_with_dashes fatal error when query var value is an array in php 8
#5
@
18 months ago
- Keywords reporter-feedback added
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.
#6
follow-up:
↓ 7
@
18 months ago
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.
#7
in reply to:
↑ 6
@
18 months ago
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.
#8
@
6 weeks ago
@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>
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.