Critical error but debug log doesn’t show any fatal error?

by | Aug 15, 2024 | 0 comments

When dealing with WordPress, encountering a critical error is never fun, especially when your debug log doesn’t clearly show what’s causing it. If you’ve ever found yourself staring at a log full of repetitive notices without any indication of the actual problem, you’re not alone. In this post, I’ll walk you through a recent experience I had, where the solution involved a bit of detective work—disabling plugins and clearing out misleading log entries until I could finally uncover the real issue.

The Problem: A Critical Error with No Clear Cause

Recently, one of my WordPress pages started showing a critical error message. Naturally, I enabled WP_DEBUG, WP_DEBUG_DISPLAY, and WP_DEBUG_LOG to track down the issue. But instead of finding a clear fatal error in the logs, I was greeted with repetitive notices:

  • The first notice was about a deprecated Jetpack hook:
    [15-Aug-2024 20:46:07 UTC] PHP Deprecated: Hook custom_css_loaded is <strong>deprecated</strong> since version jetpack-13.5! Use WordPress Custom CSS instead. Jetpack no longer supports Custom CSS. Read the WordPress.org documentation to learn how to apply custom styles to your site: https://wordpress.org/documentation/article/styles-overview/#applying-custom-css in /wordpress/core/6.6.1/wp-includes/functions.php on line 6085
  • The second notice was repeating over and over again for hundreds of lines each time I refreshed the page:
    [15-Aug-2024 20:46:08 UTC] PHP Notice: Function amp_is_available was called <strong>incorrectly</strong>. amp_is_available() (or amp_is_request(), formerly is_amp_endpoint()) was called too early and so it will not work properly. WordPress is currently doing the load_script_textdomain_relative_path hook. Calling this function before the wp action means it will not have access to WP_Query and the queried object to determine if it is an AMP response, thus neither the amp_skip_post() filter nor the AMP enabled toggle will be considered. Please see <a href="https://developer.wordpress.org/advanced-administration/debug/debug-wordpress/">Debugging in WordPress</a> for more information. (This message was added in version 2.0.0.) in /wordpress/core/6.6.1/wp-includes/functions.php on line 6085

Despite these notices filling up the log, there was no sign of a fatal error. It was clear that the debug log was being overwhelmed with irrelevant issues, masking the real problem.

Step 1: Addressing the Jetpack Notice

The first step I took was to disable the custom CSS feature in Jetpack. This deprecated feature was no longer supported, and keeping it active was generating unnecessary noise in the debug log. Once I disabled this option, the notice about the deprecated hook stopped appearing, cleaning up my log a bit.

Step 2: Disabling the AMP Plugin

The next issue was the repeated notice from the AMP plugin, which was being triggered too early in the WordPress execution process. This notice filled the log over and over again, making it impossible to see anything else. To move forward, I disabled the AMP plugin altogether.

With both the Jetpack and AMP issues addressed, I cleared the debug log and reloaded the problematic page to generate a fresh log.

Step 3: Uncovering the Real Issue

Once the AMP plugin was disabled, the debug log finally revealed the actual fatal error:
[15-Aug-2024 20:55:29 UTC] PHP Fatal error: Uncaught TypeError: count(): Argument #1 ($value) must be of type Countable|array, bool given in /srv/htdocs/wp-content/plugins/official-facebook-pixel/integration/FacebookWordpressWooCommerce.php:126
Stack trace:
#0 /srv/htdocs/wp-content/plugins/official-facebook-pixel/integration/FacebookWordpressWooCommerce.php(126): count(false)
#1 /srv/htdocs/wp-content/plugins/official-facebook-pixel/integration/FacebookWordpressWooCommerce.php(116): FacebookPixelPlugin\Integration\FacebookWordpressWooCommerce::getProductCategory(12768)
#2 [internal function]: FacebookPixelPlugin\Integration\FacebookWordpressWooCommerce::createViewContentEvent(Object(WC_Product_Simple))
#3 /srv/htdocs/wp-content/plugins/official-facebook-pixel/core/ServerEventFactory.php(203): call_user_func_array(Array, Array)
#4 /srv/htdocs/wp-content/plugins/official-facebook-pixel/integration/FacebookWordpressWooCommerce.php(96): FacebookPixelPlugin\Core\ServerEventFactory::safeCreateEvent('ViewContent', Array, Array, 'woocommerce')
#5 /wordpress/core/6.6.1/wp-includes/class-wp-hook.php(324): FacebookPixelPlugin\Integration\FacebookWordpressWooCommerce::trackViewContentEvent('')
#6 /wordpress/core/6.6.1/wp-includes/class-wp-hook.php(348): WP_Hook->apply_filters(NULL, Array)
#7 /wordpress/core/6.6.1/wp-includes/plugin.php(517): WP_Hook->do_action(Array)
#8 /wordpress/plugins/woocommerce/9.1.4/templates/content-single-product.php(76): do_action('woocommerce_aft...')
#9 /wordpress/core/6.6.1/wp-includes/template.php(812): require('/wordpress/plug...')
#10 /wordpress/plugins/woocommerce/9.1.4/includes/wc-core-functions.php(284): load_template('/srv/htdocs/wp-...', false)
#11 /wordpress/plugins/woocommerce/9.1.4/templates/single-product.php(37): wc_get_template_part('content', 'single-product')
#12 /wordpress/core/6.6.1/wp-includes/template-loader.php(106): include('/wordpress/plug...')
#13 /wordpress/core/6.6.1/wp-blog-header.php(19): require_once('/wordpress/core...')
#14 /wordpress/core/6.6.1/index.php(17): require('/wordpress/core...')
#15 {main}
thrown in /srv/htdocs/wp-content/plugins/official-facebook-pixel/integration/FacebookWordpressWooCommerce.php on line 126

This error was related to the Facebook Pixel plugin, which was trying to count something that wasn’t an array, but a boolean (false). Without addressing the earlier log noise, this error was entirely hidden.

The Solution: Fixing the Facebook Pixel Plugin

With the real issue finally exposed, I was able to debug the Facebook Pixel plugin. The solution involved checking the code to ensure that the count() function was only called on arrays or countable objects, preventing the fatal error.

Takeaways for WordPress Debugging

If you’re facing a critical error, but your debug log isn’t showing it, follow these steps:

  • Clean Up the Noise: Address any deprecated functions, notices, or warnings that are filling up your debug log. Disable plugins or features that are generating irrelevant messages.
  • Disable and Isolate: Temporarily disable plugins or themes that might be masking the real issue. Once you’ve isolated the problem, you can focus on the actual error.
  • Check the Logs Again: Clear the debug log and try to replicate the issue to see if a more relevant error surfaces. Often, once the noise is removed, the real problem becomes apparent.

By systematically addressing these misleading errors, you can clear the way to finding and fixing the actual issues on your site. Debugging WordPress might be a bit of a puzzle, but with the right approach, you can always find the missing piece.

Need some help?

Let’s discuss your project

Website Development