[wp-trac] [WordPress Trac] #49094: preg_match() expects parameter 2 to be string on line 417 of wp-includes/class-wp-block-parser.php
WordPress Trac
noreply at wordpress.org
Sun Dec 29 20:45:14 UTC 2019
#49094: preg_match() expects parameter 2 to be string on line 417 of wp-includes
/class-wp-block-parser.php
--------------------------+-----------------------------
Reporter: thenerdcave | Owner: (none)
Type: defect (bug) | Status: new
Priority: normal | Milestone: Awaiting Review
Component: General | Version: 5.3.2
Severity: normal | Keywords:
Focuses: |
--------------------------+-----------------------------
wp version 5.3.2
os MacOS 10.15.2
browser FireFox 71.0
Building a custom theme and on a very simple page if I have a qry param in
the url that is an array ''(ex. ?c[]=3&c[]=6)'' I get the following
warnings. If I change the url param to a string like ''c=3'' then the
warnings go away.
{{{
Warning: preg_match() expects parameter 2 to be string, array given in
/wp-includes/class-wp-block-parser.php on line 417
Warning: strlen() expects parameter 1 to be string, array given in /wp-
includes/class-wp-block-parser.php on line 489
}}}
The reason the url has these params is for a custom data filter with a
multi-select menu.
After a google search it appears that this bug was introduced in version
5.3.1 and based on my findings to fix the issue that is accurate.
The bug appears to be related to the parse_blocks() function, I was able
to trace the issue back to this location: blocks.php line 271 function
filter_block_content();
If I update the function like so,
{{{
function filter_block_content( $text, $allowed_html = 'post',
$allowed_protocols = array() ) {
$result = '';
if ( !is_array( $text ) ) {
$blocks = parse_blocks( $text );
foreach ( $blocks as $block ) {
$block = filter_block_kses( $block,
$allowed_html, $allowed_protocols );
$result .= serialize_block( $block );
}
}
return $result;
}
}}}
by adding the **if !is_array()** condition the page works properly and
warnings go away. I'm not 100% sure if this is the correct place for this
fix but wanted to let you know about the issue, since I don't believe WP
should be trying to parse qry params this way.
Hope this information is helpful.
--
Ticket URL: <https://core.trac.wordpress.org/ticket/49094>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform
More information about the wp-trac
mailing list