Autoembeds not rendered in front-end post content

[needle]

The regex which identifies whether post content contains a possible oEmbed URL fails silently in front-end post content in some circumstances. As far as I can tell, this happens when PHP is not compiled with PCRE JIT - e.g. on Apple Silicon using MAMP and/or MAMP Pro - and regardless of the pcre.jit value in php.ini.

When post content is rendered via the_content() in a template, what happens is that in ​the `preg_match` test for possible oEmbed URLs, the \s escape sequence does not match \r\n in the post content and thus embeds are not rendered via the autoembed callback.

The following string based on ​the autoembed test strings should produce a match:

$foo = "test\r\nhttps://w.org\r\ntest";
echo preg_match( '#(^|\s|>)https?://#i', $content, $matches ) ? print_r( $matches, true ) : 'No matches.';

In my tests, this what happens:

Linux Intel

PCRE (Perl Compatible Regular Expressions) Support  enabled
PCRE Library Version  10.35 2020-05-09
PCRE Unicode Version  13.0.0
PCRE JIT Support  enabled
PCRE JIT Target  x86 64bit (little endian + unaligned)
pcre.jit  1  1

Success:

Array
(
    [matches] => Array
        (
            [0] => 
https://
            [1] => 

        )

)

Mac Intel

PCRE (Perl Compatible Regular Expressions) Support  enabled
PCRE Library Version  10.35 2020-05-09
PCRE Unicode Version  13.0.0
PCRE JIT Support  enabled
PCRE JIT Target  x86 64bit (little endian + unaligned)
pcre.jit  0  0

Success:

Array
(
    [matches] => Array
        (
            [0] => 
https://
            [1] => 

        )

)

Mac Apple Silicon running MAMP

--with-external-pcre=/Applications/MAMP/Library
PCRE (Perl Compatible Regular Expressions) Support  enabled
PCRE Library Version  10.36 2020-12-04
PCRE Unicode Version  13.0.0
PCRE JIT Support  not compiled in

Fail:

No matches.

Although it could be argued that this is an upstream problem with PHP, it seems that ​the PHP fix will only apply to versions of PHP greater than 8.1.11. This means many devs working on Apple Silicon machines are likely to encounter this issue. A simple fix in WordPress is to add the "vertical whitespace" \R escape sequence (which matches \n, \r and \r\n) to the regex:

if ( preg_match( '#(^|\s|\R|>)https?://#i', $content ) ) {
  // Find URLs on their own line.
  $content = preg_replace_callback( '|^(\s*)(https?://[^\s<>"]+)(\s*)$|im', array( $this, 'autoembed_callback' ), $content );
  // Find URLs in their own paragraph.
  $content = preg_replace_callback( '|(<p(?: [^>]*)?>\s*)(https?://[^\s<>"]+)(\s*<\/p>)|i', array( $this, 'autoembed_callback' ), $content );
}

This does not appear to affect systems where PHP is compiled with PCRE JIT, whether or not pcre.jit = 0 or pcre.jit = 1, though I appreciate that wider testing is needed.

Trac ticket: https://core.trac.wordpress.org/ticket/57699#ticket

[needle]

I'm not sure the tests will reveal the problem reported in this ticket, but it's a representative string that fails on PHP builds on Apple Silicon, e.g. those supplied by MAMP.