[graziano]

Hello,

We’re experiencing an intermittent PHP Fatal Error on our WordPress site that we believe may be related to W3 Total Cache, and we’d appreciate your help confirming or ruling this out.

Environment:
– WordPress version: 7.0
– W3 Total Cache version: latest
– PHP version: 8.4.22 (FPM, fpm-fcgi SAPI)
– Server: AlmaLinux 9, cPanel/WHM, Apache + PHP-FPM (an Nginx reverse proxy in front of Apache)
– memory_limit: 512M

The error (from our PHP-FPM pool’s error log):

[17-Jun-2026 15:11:09 UTC] PHP Fatal error: Allowed memory size of 536870912 bytes exhausted (tried to allocate 4295229440 bytes) in /wp-includes/theme.php on line 325

Line 325 of wp-includes/theme.php is inside get_template():
return apply_filters( ‘template’, get_option( ‘template’ ) );

The requested allocation size (~4GB) is suspicious and suggests either a recursive call chain or an integer overflow happening somewhere in a callback hooked to the ‘template’ filter.

What we’ve found so far:
– The error is intermittent (every few hours to a few days) and NOT tied to any specific user action. It has occurred while an admin was using the Elementor editor, but also on at least one occasion when no one was logged in at all — which makes us suspect it may be triggered during an automated page cache priming request rather than a real visitor or admin session.
– w3-total-cache/Generic_Plugin.php hooks the ‘template’ filter conditionally (template_preview() if a w3tc_theme query param + specific UA is present, or template() if mobile.enabled/referrer.enabled is true). In our config both mobile.enabled and referrer.enabled are False, so neither callback should currently be attached — yet the crash still occurs with the call stack pointing at get_template()/apply_filters(‘template’, …).
– We use Redis as the backend for the page cache only (object cache and database cache are disabled).

Questions for your team:
1. Does the page cache priming mechanism (pgcache.prime) make any request or call any code path that touches the ‘template’ or ‘stylesheet’ filters, e.g. when iterating sitemap URLs or regenerating cache after a new post?
2. Is there any other code path in W3 Total Cache (minify, CDN, output buffering, etc.) that hooks ‘template’/’stylesheet’ even when mobile/referrer features are disabled?
3. Are there known issues with PHP 8.4 compatibility involving theme detection in the version we’re running?

We’re happy to share our full W3TC configuration export, PHP error log excerpts, or any other diagnostic info you need. We’d prefer not to disable the plugin for an extended period since it’s important for site performance, so guidance on a safe diagnostic step (a setting to toggle, or a patched version to test) would be very helpful.

Thank you in advance for your help.

Best regards,
gomoot.com

[Marko Vasiljevic]

Hello Graziano,

Thank you for reaching out and I am happy to help!
Thank you for the detailed report and for providing the environment information.

Based on what you’ve shared, we would not currently expect W3 Total Cache itself to trigger this type of memory exhaustion error through page cache priming or normal page cache generation.

Regarding your first question, page cache priming works by making standard HTTP requests to the URLs being primed. Those requests go through the normal WordPress bootstrap process, which includes loading the active theme and calling functions such as get_template() and get_stylesheet(). As a result, a priming request could encounter the error if another plugin or theme callback attached to the template or stylesheet filters is causing a problem. However, the priming process itself does not modify or hook those filters.

For your second question, the primary W3 Total Cache code paths that hook the template and stylesheet filters are related to theme switching for Mobile Groups and Referrer Groups. Since both mobile.enabled and referrer.enabled are disabled in your configuration, those callbacks should not be active. We are not aware of other core page cache, minify, CDN, or output buffering features that attach to these filters under normal operation.

Regarding PHP 8.4 compatibility, we are not aware of any known issues in current W3 Total Cache releases that would cause recursive theme detection or excessive memory allocation through the template filter. The allocation size shown in the error log (approximately 4 GB) is unusual and is more consistent with a recursive callback chain or another component repeatedly invoking theme-related functions.

As a diagnostic step, we would recommend inspecting the callbacks currently attached to the template and stylesheet filters when the issue occurs. If another plugin or theme is calling get_template(), get_stylesheet(), or wp_get_theme() from within one of those filter callbacks, it could create the type of recursive behavior suggested by the error.

If you’re able to provide a W3 Total Cache configuration export, a stack trace, or a list of callbacks attached to the template filter, we’d be happy to review them and help determine whether W3 Total Cache is involved.

[Author]

Posts