• philipwhiuk

    (@philipwhiuk)


    Hi folks,

    We have a WordPress 6.7.x site with a number of plugins installed, most of which are fairly widely deployed (BuddyBoss, WooCommerce).

    Since upgrading to 6.7 we’ve seen the i8n improvements cause an issue. But unlike other reports we’re seeing it cascade to cause more fundamental problems because of the way WP tries to handle the error:

    [24-Nov-2024 18:44:56 UTC] PHP Fatal error:  Uncaught Error: Class 'WP_Block_Parser' not found in /public_html/wp-includes/blocks.php:2225
    Stack trace:
    #0 /public_html/wp-includes/blocks.php(1820): parse_blocks('Function _load_...')
    #1 /public_html/wp-includes/formatting.php(5200): filter_block_content('Function _load_...', Array, Array)
    #2 /public_html/wp-includes/class-wp-hook.php(324): wp_pre_kses_block_attributes('Function _load_...', Array, Array)
    #3 /public_html/wp-includes/plugin.php(205): WP_Hook->apply_filters('Function _load_...', Array)
    #4 /public_html/wp-includes/kses.php(946): apply_filters('pre_kses', 'Function _load_...', Array, Array)
    #5 /public_html/wp-includes/kses.php(754): wp_kses_hook('Function _load_...', Array, Array)
    #6 /public_html/wp-includes/functions.php(6106): wp_kses('Function _load_...', Array, Array)
    #7 /public_html/wp-includes/functions.php(6054): wp_trigger_error('', 'Function _load_...')
    #8 / in /public_html/wp-includes/blocks.php on line 2225

    It seems like the _load failure is causing the entire blocks architecture to crash in a way that it fails to even run the class-autoloader. Surely WordPress should be a bit more resilient here.

    In fact to even work out that it was this change, I had to temporarily add an error_log to wp-includes/functions.php to log the raw message prior to it being passed into kses (as the fatal error above shows only a few characters)

    [18-Nov-2024 19:02:26 UTC] PHP Notice:  Function _load_textdomain_just_in_time was called <strong>incorrectly</strong>. Translation loading for the <code>buddyboss</code> domain was triggered too early. This is usually an indicator for some code in the plugin or theme running too early. Translations should be loaded at the <code>init</code> action or later. Please see <a href="https://developer.www.ads-software.com/advanced-administration/debug/debug-wordpress/">Debugging in WordPress</a> for more information. (This message was added in version 6.7.0.) in /public_html/wp-includes/functions.php on line 6114

    For now we’ve temporarily turned off WP_DEBUG in the hope this fixes it but it might just be hiding the problem. We’ve seen the following plugins report this error:

    • ajax-login-and-registration-modal-popup
    • buddyboss
    • buddyboss-pro
    • complianz-gdpr
    • gravityperks
    • woocommerce
    • woocommerce-gateway-stripe

    Some of these are very widely deployed (e.g. WooCommerce) Is there a plan to improve how WP handles this error in a coming release?

Viewing 3 replies - 1 through 3 (of 3 total)
  • threadi

    (@threadi)

    The fatal error displayed indicates to me that core files are missing or have been changed in your project. To fix this, I would recommend updating the core files manually as described here: https://www.ads-software.com/documentation/article/updating-wordpress/#manual-update

    The other messages are only notices, not errors related to plugins that are not yet compatible with changes in WordPress 6.7. Here you can either deactivate the debug mode or at least the output of the PHP messages, but you would have to contact the plugin developers concerned to find a solution. They already received an announcement about this some time ago: https://make.www.ads-software.com/core/2024/10/21/i18n-improvements-6-7/

    Thread Starter philipwhiuk

    (@philipwhiuk)

    The fatal error displayed indicates to me that core files are missing or have been changed in your project. To fix this, I would recommend updating the core files manually as described here:?https://www.ads-software.com/documentation/article/updating-wordpress/#manual-update

    Yes we did try this (we reinstalled via the option in WP Admin). It didn’t seem to make a difference. It feels to me like the trigger disrupts the class loading process which is odd to me but I don’t know how the WP class loader works.

    threadi

    (@threadi)

    That is strange. However, it could also be a subsequent error of the PHP hints for the incorrect integration of plugins. I would therefore recommend checking the above.

Viewing 3 replies - 1 through 3 (of 3 total)
  • You must be logged in to reply to this topic.