Opened 6 years ago
Closed 6 years ago
#45644 closed defect (bug) (reported-upstream)
Warning: preg_match(): Compilation failed in class-wp-block-parser.php line 382
Reported by: |
|
Owned by: | |
---|---|---|---|
Milestone: | Priority: | normal | |
Severity: | normal | Version: | |
Component: | Editor | Keywords: | has-patch |
Focuses: | Cc: |
Description
Hi,
Since I updated to wordpress 5.01 I got the following warning in pages:
Warning: preg_match(): Compilation failed: unrecognized character after (?< at offset 10 in /disk2/wordpress/wp-includes/class-wp-block-parser.php on line 382
The PHP I'm using is:
PHP 5.3.3 (cli) (built: Oct 31 2014 09:53:00)
Copyright (c) 1997-2010 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2010 Zend Technologies
On a CentOS 5 distribution.
Attachments (1)
Change History (11)
#1
follow-up:
↓ 2
@
6 years ago
Hi there, welcome to Wordpress Trac!
I'm not a WP core committer, so please take their advice over mine :). I tried to reproduce the error but I'm failing to do so.
PHP 7.3 comes with PCRE version upgrade that might throw similar errors (https://ayesh.me/Upgrade-PHP-7.3#pcre2), but the regex compiles just fine across all versions from what I can see (https://3v4l.org/35aU0).
From the patch, it looks like you changed the regex named subpattern syntax. I don't know if Wordpress has a code styling guideline for this, but in all PHP versions >=5.3, /(?<name>pattern)/
should be identical to /(?P<name>pattern)/
(https://regex101.com/r/xmdEiL/1/, https://regex101.com/r/VSaJUI/1).
#2
in reply to:
↑ 1
@
6 years ago
Hi,
Thanks for the welcome and your fast reaction :)
Replying to ayeshrajans:
PHP 7.3 comes with PCRE version upgrade that might throw similar errors (https://ayesh.me/Upgrade-PHP-7.3#pcre2), but the regex compiles just fine across all versions from what I can see (https://3v4l.org/35aU0).
From the patch, it looks like you changed the regex named subpattern syntax. I don't know if Wordpress has a code styling guideline for this, but in all PHP versions >=5.3,
/(?<name>pattern)/
should be identical to/(?P<name>pattern)/
(https://regex101.com/r/xmdEiL/1/, https://regex101.com/r/VSaJUI/1).
I don't know either... It "should" indeed :)
What I can tell however is that I searched for other regexps like this in all the sources and this is the only one who is using that naming convention. All the others follows the same syntax as the changes I made (so the "(?P<" style).
In fact, IIRC this is the method recommended on the php site for better portability...
Regards,
David.
#3
follow-up:
↓ 4
@
6 years ago
Hi @ledavdotnet - May I ask the PCRE version your PHP setup is compiled with? A phpinfo()
should reveal it under PCRE Library Version
.
#4
in reply to:
↑ 3
@
6 years ago
Replying to ayeshrajans:
Hi @ledavdotnet - May I ask the PCRE version your PHP setup is compiled with? A
phpinfo()
should reveal it underPCRE Library Version
.
Sure, here it is:
PCRE Library Version 6.6 06-Feb-2006
#7
follow-up:
↓ 8
@
6 years ago
- Milestone changed from 5.0.3 to 5.1
Hey @ledavdotnet,
Thanks for opening this ticket!
First, I do highly recommend that you upgrade to a more recent version of PHP. 5.3 has not been supported since 2014 (over 4 years).
I am trying to reproduce the issue but have been unable to so far. I am running PHP v5.3.29, and PCRE v8.32.
Can you be more specific about when and how you are able to cause the issue? For example, does it happen when a specific type of block is in a post? Does it happen with an empty post? Specific steps will help someone else reproduce the problem you are seeing.
I am also going to bump this to 5.1 because the bug has not been reproduced yet and 5.0.3 RC is due out tomorrow.
#8
in reply to:
↑ 7
@
6 years ago
Hi @desroj,
Replying to desrosj:
Thanks for opening this ticket!
And thanks for your reply :-)
First, I do highly recommend that you upgrade to a more recent version of PHP. 5.3 has not been supported since 2014 (over 4 years).
Yeah I know, shame on me... This is an old CentOS 5 that I'm going to replace soon as possible... It will take some time though...
I am trying to reproduce the issue but have been unable to so far. I am running PHP v5.3.29, and PCRE v8.32.
As I reported above, mine is even older: php 5.3.3 and pcre 6.6 ... Probably your version don't suffer of this problem.
Can you be more specific about when and how you are able to cause the issue? For example, does it happen when a specific type of block is in a post? Does it happen with an empty post? Specific steps will help someone else reproduce the problem you are seeing.
I reverted the patch and did few more checks and the problem appears on all the pages and in all the posts, always right after the <div class="entry"> tag. There is no problem however in the administration interface.
Example:
<div class="post-1864 post type-post status-publish format-standard hentry category-blabla" id="post-1864"> <h2>title</h2> <small>Thursday, May 3rd, 2012</small> <div class="entry"> Warning: preg_match(): Compilation failed: unrecognized character after (?< at offset 10 in /wordpress/wp-includes/class-wp-block-parser.php on line 382 <blockquote><p>Some text....
However, something maybe more interesting: The same error could be reproduced using the pcregrep command line tool:
pcregrep version 4.2 09-Jan-2006 using PCRE version 6.6 06-Feb-2006:
bash $ echo "" | pcregrep '/<!--\s+(?<closer>\/)?/s' && echo TRUE || echo FALSE pcregrep: Error in command-line regex at offset 11: unrecognized character after (?< FALSE
pcregrep version 8.42 2018-03-20:
bash $ echo "" | pcregrep '/<!--\s+(?<closer>\/)?/s' && echo TRUE || echo FALSE FALSE
Note also that I just updated wordpress to v5.0.2: Same problem, same patch to fix the issue...
#10
@
6 years ago
- Milestone 5.1 deleted
- Resolution set to reported-upstream
- Status changed from new to closed
- Version 5.0.1 deleted
Aye, this syntax was introduced in PCRE 7.0. While we technically don't support custom builds of PHP, this is a fairly simple fix, so we can land it in 5.1.
I've reported this bug upstream in the Gutenberg repo (GB13310), it'll be fixed there, then core can import the fix.
Patch to fix the issue....