[wp-trac] [WordPress Trac] #57699: Autoembeds not rendered in front-end post content

[WordPress Trac]

#57699: Autoembeds not rendered in front-end post content
--------------------------+-----------------------------
 Reporter:  needle        |      Owner:  (none)
     Type:  defect (bug)  |     Status:  new
 Priority:  normal        |  Milestone:  Awaiting Review
Component:  Embeds        |    Version:
 Severity:  normal        |   Keywords:
  Focuses:                |
--------------------------+-----------------------------
 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 [https://github.com/WordPress/wordpress-
 develop/blob/0cb8475c0d07d23893b1d73d755eda5f12024585/src/wp-includes
 /class-wp-embed.php#L444 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 [https://github.com/WordPress/wordpress-
 develop/blob/0cb8475c0d07d23893b1d73d755eda5f12024585/tests/phpunit/tests/media.php#L303
 the autoembed test strings] ''should'' produce a match:

 {{{#!php
 $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 [https://github.com/php/php-
 src/commit/f8b217a3452e76113b833eec8a49bc2b6e8d1fdd 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:

 {{{#!php
 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.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/57699>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform