Opened 5 months ago
Last modified 7 weeks 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 (8)
#1
@
5 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
@
7 weeks 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
@
7 weeks 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
@
7 weeks 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.
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.