SOLVED: PHP Warning: preg_match(): Compilation failed on website with many dynamic tags

Hi! In both server error log, and WP debug I get:

[25-Mar-2026 14:40:53 UTC] PHP Warning: preg_match(): Compilation failed: regular expression is too large at offset 48175 in /var/www/vhosts/otthon-konyha.hu/httpdocs/wp-content/themes/bricks/includes/integrations/dynamic-data/providers.php on line 397

It’s running every ms.

I’m using Bricks 2.3, everything updated. (Php 8.5)

Any ideas how to handle it?

Browser: Chrome 110
OS: macOS / Windows / Linux / etc.
URL: Link to a page that illustrates this issue
Video: Short screen recording that illustrates this issue (free tool: jam.dev)

[Please describe this bug in as much detail as possible so we can replicate & debug this bug]

It could be because you are running PHP 8.5 and that is a new warning. From what I see, PHP 8.4 and PHP 8.5 are still only in beta support for WordPress. Try PHP 8.3 for now.

1 Like

Nope, give it a bit of time but Php 8.3 does the same

1 Like

Can you revoke the solution so it isn’t marked as solved?

Hi @razin ,

Kindly prepare a staging site and send admin credentials + FTP/SFTP access to help@bricksbuilder.io so we can check the root cause.

(Include this forum thread URL as a reference and use your purchased license email when composing the email for license verification purposes.)

Regards,
Jenn

Hello Jenn,

I’m experiencing the exact same issue on my site (Bricks 2.3.1, PHP 8.1, OpenLiteSpeed). I tried with 8.2 and 8.3, same issue.
In my case the error log was flooding with thousands of entries per minute, and it was also causing downstream issues with WS Form submissions failing intermittently.

Root cause: The render() method in providers.php builds a single regex pattern from ALL registered dynamic data tags on line ~389-392:

$escaped_tags = array_map( 'preg_quote', $registered_tags );
self::$run_again_pattern_cache[ $cache_key ] = '/\{(?:' . implode( '|', $escaped_tags ) . ')(?:[:\s]|$)/';

On sites with many ACF fields and CPTs, this compiled pattern exceeds PCRE2’s hard ~64KB size limit. No php.ini setting can fix this — we tried pcre.jit=0 and pcre.jit_stack_size = 512K, neither helped.

Fix that works: Split the pattern into smaller chunks. Replace the block around lines 389–397 with:

if ( ! isset( self::$run_again_pattern_cache[ $cache_key ] ) ) {
    $escaped_tags = array_map( 'preg_quote', $registered_tags );
    $chunks = array_chunk( $escaped_tags, 200 );
    $patterns = [];
    foreach ( $chunks as $chunk ) {
        $patterns[] = '/\{(?:' . implode( '|', $chunk ) . ')(?:[:\s]|$)/';
    }
    self::$run_again_pattern_cache[ $cache_key ] = $patterns;
}

$has_more_tags = false;
foreach ( self::$run_again_pattern_cache[ $cache_key ] as $chunk_pattern ) {
    if ( preg_match( $chunk_pattern, $content ) ) {
        $has_more_tags = true;
        break;
    }
}
if ( $has_more_tags && $rerun_attemps < $max_attempts ) {

Same logic, just chunked into groups of 200 tags so no single pattern exceeds the PCRE2 limit. Error log went completely silent immediately after applying this.

Obviously this gets overwritten on the next Bricks update, so it would be great to see an official fix. An alternative approach would be replacing this preg_match with a simple strpos loop since it’s only checking for tag presence, not extracting matches.

Hope this helps!

3 Likes

THANK YOU! This did stop the error logging :slight_smile:

1 Like

Same Issue here, site with multiple ACF cf and CPTs. Adrien fix worked fine, thanks!

2026/03/30  19:25:41 [error] 1513496#1513496: *3387 FastCGI sent in stderr: "PHP message: PHP Warning:  preg_match(): Compilation failed: regular expression is too large at offset 74500 in /var/www/site/wordpress/wp-content/themes/bricks/includes/integrations/dynamic-data/providers.php on line 397" while reading response header from upstream, client: 181.229.81.230, server: www.site.org.ar, request: "GET /?post_type=bricks_template&p=18844&bricks=run HTTP/1.1", upstream: "fastcgi://unix:/run/php/php8.4-fpm.sock:", host: "site.org.ar", referrer: "https://site.org.ar/wp-admin/edit.php?post_type=bricks_template" 

1 Like

Hi @Adrien,

Thank you so much for pointing out the issue.

I have added this to the bug tracker. We will discuss and come up with a fix.

Regards,
Jenn

1 Like

Hi @razin & @ariel

Can you please send an email to help@bricksbuilder.io so I can send you a potential fix for testing purposes? Thanks. (Please include this forum thread URL as a reference in the email)

Regards,
Jenn

1 Like

It is a clients, live webshop, so I wouldn’t be testing further there. @Adrien ‘s patch works fine. Server config below, if that helps. On my Hostinger staging server, with the same install I didn’t get these errors.

Server Environment
Server info: Apache
MySQL version: 10.11.16
Postmeta table meta_value type: longtext
PHP version: 8.3.30
PHP post max size: 1G
PHP execution time limit: 180
PHP max input vars: 15000
PHP safe mode:
PHP memory limit: 768M
PHP max upload file size: 1G
PHP wp_remote_post: Success

We’ve addressed this in Bricks 2.3.2, now available as a one-click update in your WordPress Dashboard.

Please read the changelog entry before updating, and let us know if you experience any issues.

1 Like