Post/Page Content Renders Empty

[svgator]

• using php version 7.3.19, wp version 6.2.2
• function convert_smilies in formatting.php file
• when adding texts longer than 1,001,318 preg_split fails and content renders empty
• warning shown: Warning: count(): Parameter must be an array or an object that implements Countable in /var/www/html/wp-includes/formatting.php on line 3444 Notice: Trying to access array offset on value of type bool in /var/www/html/wp-includes/formatting.php on line 3451

[svgator]

A bit more detailed description:

Description
When page or post content exceeds a given size limit (1,001,318 length), preg_split returns false, thus the content renders empty.
A warning also shows up (in developer mode):
Warning: count(): Parameter must be an array or an object that implements Countable in /var/www/html/wp-includes/formatting.php on line 3444 Notice: Trying to access array offset on value of type bool in /var/www/html/wp-includes/formatting.php on line 3451
PHP version: 7.3.19
Wordpress version: 6.2.2
in /wp-includes/formatting.php, in function convert_smilies, line 3442
$textarr = preg_split( '/(<.*>)/U', $text, -1, PREG_SPLIT_DELIM_CAPTURE ); Capture the tags as well as in between.
function convert_smilies in formatting.php file

[petitphp]

Hi @svgator and welcome to trac !

Looking at the content you shared (thank you for providing a real example), you are embedding a PNG image in a SVG. The PNG image is 649x801 pixels which is a lot of text in base64. This cause the preg_split function to fail (probably hitting a limit of some kind).

IMHO this is more an issue with the content than with WordPress. Images should be inserted using a <img> tag and not inline because it creates really heavy content that take more time to download and are harder to parse for browsers.

[svgator]

Hi @petitphp,

Thanks for Your reply!

I get Your point, yet the problem reported is coming from an actual SVGator end user, thus it seems to be a legit one.

Having everything compressed & put inline into HTML is also a known technique, i.e. check HTML source of a sample ​Google Search.

Also this is something new, we believe from WordPress v6+, since same content & pages have been working before.

[cexopan]

Replying to petitphp:

IMHO this is more an issue with the content than with WordPress. Images should be inserted using a <img> tag and not inline because it creates really heavy content that take more time to download and are harder to parse for browsers.

I disagree. For two reasons:

1. It is not relevant that it was so much base64 data. It would fail with 1M dots or 0s or 100,000 empty divs or whatever. Although 1M chars is quite a bit and certainly not your typical amount of HTML content it is actually possible without exceptional circumstances: I ran into the same problem with a gallery of 200 images served by Meow Gallery/Lightbox shortcode. In this case there is no base64 data, just pure HTML with some really big attributes.
2. Moving on to PHP8 not dealing with an official return type ("false on failure") of preg_split() is asking for trouble. In PHP8 this results in a fatal TypeError in count().

I hope you reconsider your assessment