Make WordPress Core

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: ledavdotnet's profile ledavdotnet 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)

wordpress.patch (664 bytes) - added by ledavdotnet 6 years ago.
Patch to fix the issue.…

Download all attachments as: .zip

Change History (11)

@ledavdotnet
6 years ago

Patch to fix the issue....

#1 follow-up: @ayeshrajans
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 @ledavdotnet
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: @ayeshrajans
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 @ledavdotnet
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 under PCRE Library Version.

Sure, here it is:
PCRE Library Version 6.6 06-Feb-2006

#5 @SergeyBiryukov
6 years ago

  • Component changed from General to Editor

#6 @SergeyBiryukov
6 years ago

  • Milestone changed from Awaiting Review to 5.0.3

#7 follow-up: @desrosj
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 @ledavdotnet
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:

$ 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:

$ 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...

#9 @desrosj
6 years ago

#45969 was marked as a duplicate.

#10 @pento
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.

Note: See TracTickets for help on using tickets.