Critical error after update to 6.3 due to WP_Metadata_Lazyloader

[alexpaterson]

Hi,

After trying to upgrade to 6.3, I've received a critical error:

Fatal error: Cannot declare class WP_Metadata_Lazyloader, because the name is already in use in /opt/bitnami/wordpress/wp-includes/class-wp-metadata-lazyloader.php on line 32

I've manually reinstalled WordPress through FileZilla, disabled all plugins, but still can't get access.

My website is completely inaccessible, both front and back end, so I'd appreciate if this could be looked into urgently - it appears that I'm not the only one reporting this error (​https://www.reddit.com/r/Wordpress/comments/15mqq4u/i_have_a_php_fatal_error_message_need_help/)

Many thanks,
Alex

[joemcgill]

Hi @alexpaterson, welcome to Trac! It sounds to me like something specific to your environment is trying to load this class twice. Could you share any more info about the callstack that is displayed when you see this error?

In case it's helpful, this class used to be loaded in wp-settings.php, but was moved to /wp-includes/meta.php in WP 6.3 so it would be loaded earlier for environments that tried to invoke the class during sunrise.php. See https://core.trac.wordpress.org/ticket/58185#comment:8 (and the resulting discussion).

[joemcgill]

#59059 was marked as a duplicate.

[alexpaterson]

Replying to joemcgill:

Hi @alexpaterson, welcome to Trac! It sounds to me like something specific to your environment is trying to load this class twice. Could you share any more info about the callstack that is displayed when you see this error?

In case it's helpful, this class used to be loaded in wp-settings.php, but was moved to /wp-includes/meta.php in WP 6.3 so it would be loaded earlier for environments that tried to invoke the class during sunrise.php. See https://core.trac.wordpress.org/ticket/58185#comment:8 (and the resulting discussion).

Hi @joemcgill,

Thanks for your quick response. That's all the information I can see displayed I'm afraid - I enabled logs through wp-config.php, but it's only logging the following:

[10-Aug-2023 18:45:21 UTC] PHP Fatal error: Cannot declare class WP_Metadata_Lazyloader, because the name is already in use in /opt/bitnami/wordpress/wp-includes/class-wp-metadata-lazyloader.php on line 32

Can you think of any possible solutions to this?

Thanks

[joemcgill]

Thanks @alexpaterson. If you could set the WP_DEBUG constant to true in your wp-config.php file, that might display more info. Is it possible that you have any plugins in your mu-plugins folder that is trying to load this file directly?

Here's a full stack trace that was shared by someone experiencing this same issue on the support forum:

PHP Fatal error: Cannot declare class WP_Metadata_Lazyloader, because the name is already in use in /var/www/html/wp-includes/class-wp-metadata-lazyloader.php on line 32
PHP Fatal error: Uncaught Error: Call to a member function set() on null in /var/www/html/wp-includes/l10n.php:806\nStack trace:\n#0 /var/www/html/wp-includes/l10n.php(900): load_textdomain()\n#1 /var/www/html/wp-includes/class-wp-fatal-error-handler.php(47): load_default_textdomain()\n#2 [internal function]: WP_Fatal_Error_Handler->handle()\n#3 {main}\n thrown in /var/www/html/wp-includes/l10n.php on line 806

Not much more help, I'm afraid, and am not sure that the issue with I10n is related to the WP_Metadata_Lazyloader problem.

[alexpaterson]

Yeah, that's the error I get with pretty much everything (I think) enabled in wp-config.php

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_DISPLAY', true );
define( 'WP_DEBUG_LOG', true );
define( 'SCRIPT_DEBUG', true );

I've had a look in mu-plugins and the only file in there was this (aios-firewall-loader.php):

<?php
// Begin AIOWPSEC Firewall
if (file_exists('/opt/bitnami/wordpress/aios-bootstrap.php')) {
	include_once('/opt/bitnami/wordpress/aios-bootstrap.php');
}
// End AIOWPSEC Firewall

That file contained this:

<?php
/**	
 * @version 1.0.2
 * WARNING: Please do not delete this file.
 * 
 * This will cause PHP to throw a fatal error and render your site unusable.
 * 
 * To safely delete this file, please check both your .user.ini file and your php.ini file and ensure this file is not set in the auto_prepend_file directive.
 * 
 * Please ask your web hosting provider if you need guidance with executing the aforementioned steps.
 */
$GLOBALS['aiowps_firewall_rules_path'] = __DIR__.'/wp-content/uploads/aios/firewall-rules/';

$GLOBALS['aiowps_firewall_data'] = array(
	'ABSPATH' => '/opt/bitnami/wordpress/',
);

// Begin AIOWPSEC Firewall
if (file_exists('/bitnami/wordpress/wp-content/plugins/all-in-one-wp-security-and-firewall/classes/firewall/wp-security-firewall.php')) {
	include_once('/bitnami/wordpress/wp-content/plugins/all-in-one-wp-security-and-firewall/classes/firewall/wp-security-firewall.php');
}
// End AIOWPSEC Firewall

And I can't find the php.ini file, but .user.ini contained this:

# Begin AIOWPSEC Firewall
auto_prepend_file='/opt/bitnami/wordpress/aios-bootstrap.php'
# End AIOWPSEC Firewall

I don't know if any of this could have anything to do with the error, but thought it'd be worth while sharing in any case (the fact that aios-bootstrap.php speaks about a fatal error did catch my eye).

Thanks

[joemcgill]

Thanks for verifying. Could you try temporarily commenting out the line in aios-bootstrap.php that includes the All In One WP Security and Firewall plugin to see if that resolves your issue? Example:

        // include_once('/bitnami/wordpress/wp-content/plugins/all-in-one-wp-security-and-firewall/classes/firewall/wp-security-firewall.php');

[swissspidy]

Not much more help, I'm afraid, and am not sure that the issue with I10n is related to the WP_Metadata_Lazyloader problem.

Hmm interesting. This could be related. WP_Fatal_Error_Handler calls load_default_textdomain(). The error indicates an unusual code path were the $wp_textdomain_registry global hasn't been set yet. We can keep an eye on this. If this happens on more usual setups too then it might be worth its own ticket.

This addresses an issue on some environments where the class-wp-metadata-lazyloader.php file is loaded twice, resulting in a fatal error.

Trac ticket: https://core.trac.wordpress.org/ticket/59057

[alexpaterson]

Hi @joemcgill,

That hasn't worked unfortunately.

[joemcgill]

If we determine this is something that needs to be addressed in core, I've added ​a potential patch that should avoid an unusual codepath that would end up loading the class-wp-metadata-lazyloader.php file twice.

@alexpaterson could you try applying this code change to your environment?

[alexpaterson]

That hasn't worked either I'm afraid

[joemcgill]

Thanks for your patience, @alexpaterson. It really seems like there is something specific to your hosting environment that is causing this class to be declared twice. It's unclear why this is being triggered in WP 6.3 whereas it wasn't in WP 6.2.

If you or anyone else is able to provide any additional info that could help us debug the issue, we can continue trying to determine a solution. I'm going to keep this open while we continue investigation.

[alexpaterson]

Hi @joemcgill,

I just tried another approach – when I manually reinstalled WordPress 6.3 through FileZilla I appended the old -admin and -includes folders to avoid a clash with the new ones. Anyway, I just tried reversing this (i.e. the new folders now appended with -new and renaming the old ones back to their original names) and I'm now receiving this log message:

Fatal error: Uncaught Error: Call to undefined function wp_lazyload_term_meta() in /opt/bitnami/wordpress/wp-includes/post.php:7720 Stack trace: #0 /opt/bitnami/wordpress/wp-includes/class-wp-query.php(3532): wp_queue_posts_for_term_meta_lazyload() #1 /opt/bitnami/wordpress/wp-includes/class-wp-query.php(3787): WP_Query->get_posts() #2 /opt/bitnami/wordpress/wp-includes/class-wp-query.php(3919): WP_Query->query() #3 /opt/bitnami/wordpress/wp-includes/block-template-utils.php(935): WP_Query->__construct() #4 /opt/bitnami/wordpress/wp-includes/blocks/template-part.php(213): get_block_templates() #5 /opt/bitnami/wordpress/wp-includes/blocks/template-part.php(257): build_template_part_block_instance_variations() #6 /opt/bitnami/wordpress/wp-includes/blocks/template-part.php(268): build_template_part_block_variations() #7 /opt/bitnami/wordpress/wp-includes/class-wp-hook.php(308): register_block_core_template_part() #8 /opt/bitnami/wordpress/wp-includes/class-wp-hook.php(332): WP_Hook->apply_filters() #9 /opt/bitnami/wordpress/wp-includes/plugin.php(517): WP_Hook->do_action() #10 /opt/bitnami/wordpress/wp-settings.php(623): do_action() #11 /bitnami/wordpress/wp-config.php(205): require_once('...') #12 /opt/bitnami/wordpress/wp-load.php(50): require_once('...') #13 /opt/bitnami/wordpress/wp-blog-header.php(13): require_once('...') #14 /opt/bitnami/wordpress/index.php(17): require('...') #15 {main} thrown in /opt/bitnami/wordpress/wp-includes/post.php on line 7720

I'm not sure if this helps any or whether it's making things worse, but obviously looks like a different kind of error. If the function is now undefined, does that mean there was maybe an issue when updating, and it never fully updated to 6.3?

Just thought I'd send it over before I end up having to try and revert back to 6.2.2.

Thanks,
Alex

[joemcgill]

@alexpaterson that error makes sense if you've reverted to the old admin and includes folders, because the wp_lazyload_term_meta function did not exist prior to WP 6.3. I'd suggest doing a clean reinstall of 6.2.2 to make sure things are all working as expected, prior to running an upgrade to 6.3 as a way of ruling out any file conflicts caused by manually uploading and renaming folders.

[alexpaterson]

Will try that now, thanks!

[SergeyBiryukov]

Replying to alexpaterson:

[10-Aug-2023 18:45:21 UTC] PHP Fatal error: Cannot declare class WP_Metadata_Lazyloader, because the name is already in use in /opt/bitnami/wordpress/wp-includes/class-wp-metadata-lazyloader.php on line 32

Can you think of any possible solutions to this?

Just to rule that out, could you make sure the wp-settings.php file is properly updated too, i.e. does NOT include the class-wp-metadata-lazyloader.php file on line 191?

[alexpaterson]

Hi @SergeyBiryukov - I've downgraded back to the previous version, but yes, it looks like it maybe still had lazyloader on line 191:

require ABSPATH . WPINC . '/class-wp-metadata-lazyloader.php';

In any case, I managed to get my WordPress back to 6.2.2 and everything appears to be stable. If I attempt to update it to 6.3 again, I'll make sure that line 191 doesn't reference lazyloader.

Thanks,
Alex

[Jeffinho2016]

Also having this error. Reverting to 6.2.2 solved all the issues. Curiously, backend and frontend still worked. Some xhr requests to the server (not made with admin-ajax) were failing and returning a 500. Also using the aiowps plugin.

BTW: i tried to edit manually meta.php to change require into require_once, it changed nothing

[SergeyBiryukov]

Replying to alexpaterson:

I've downgraded back to the previous version, but yes, it looks like it maybe still had lazyloader on line 191:

require ABSPATH . WPINC . '/class-wp-metadata-lazyloader.php';

Thanks for checking! Just to clarify, that line is supposed to be in wp-settings.php in 6.2.2, but not in 6.3.

For anyone having this issue, I would suggest verifying that the update was complete and wp-settings.php does not contain that line.

[dominickferone]

Hello,
I was running into the same issue with the fatal error from lazyload on line 32.
I have might site running from amazon lightsail into WordPress. I tried connecting through FileZilla to downgrade to 6.2.2 but I get most transfers failing.
Is there a way for me to either easily remove the line 191 issue or downgrade through lightsail?

I unfortunately messed up not making a backup of my site on lightsail.

[Jeffinho2016]

Just wanted to give a quick update on my side for this. Thought maybe could help.
I found out that I have somewhere a piece of code that does a wordpress "SHORTINIT", and includes a bunch of other extra files than the ones included with the shortinit. One of these files is class-wp-metadata-lazyloader.php. And it is just behind a required, not a required_once.
Haven't tested yet to adjust that code, but i'm kind of 100% confident that it's the problem behind it. At least on my side.

[joemcgill]

For anyone else experiencing this problem, can you confirm whether you've ruled out the issue @SergeyBiryukov mentioned in this comment, which would indicate that your wp-settings.php file was not updated when you upgraded to WP 6.3.

If you confirm that is not the problem, can you then try applying the change from ​this PR to your site and see if that fixes the issue (indicating that somehow that file is being included twice during the same application lifecycle).

[dominickferone]

I was able to fix my issues following the guide here. (​https://help.dreamhost.com/hc/en-us/articles/360028822932-Reinstall-WordPress-core-files-in-an-existing-site)
Logging into Lightsail, go to ssh, reinstall the core files, and then it fixed it.

[Jeffinho2016]

Tested this. On my side, I can confirm that it was third-party code the issue.
Wordpress Shortinit includes meta.php by default, but not settings.php.
Prior to 6.3, class-wp-metadata-lazyloader.php was added to the shortinit to get extra functions.
Since class-wp-metadata-lazyloader.php is now loaded by meta.php, it also gets loaded by default in shortinit mode. So it was being loaded, but not by WP, but by a third-party that didn't update for 6.3.

Replying to Jeffinho2016:

Just wanted to give a quick update on my side for this. Thought maybe could help.
I found out that I have somewhere a piece of code that does a wordpress "SHORTINIT", and includes a bunch of other extra files than the ones included with the shortinit. One of these files is class-wp-metadata-lazyloader.php. And it is just behind a required, not a required_once.
Haven't tested yet to adjust that code, but i'm kind of 100% confident that it's the problem behind it. At least on my side.

[treibstoff]

Last night, I had the same problem.
I have a site , Elementor, wordfence, rocket and some more running (done by a former webmaster) and the update from 6.2 to 6.3 via WP was done with no problems.
Due to inattention I delated the folder "wp-includes" via Filezilla.
So I downloaded the 6.3 package and updated the whole package (not just the delated includes folder) manually.
After that I just got a white screen while trying to login...and the fatal error (lazyloader already in use ) as described in the first post above.
Reinstalled 6.2 manually and everything back and fine.
I updated once more 6.2 to 6.3 via WP...
and no problem.
The settings.php was also updated but without the mentioned line 191 (metadata-lazyloader).
But also on two other platforms, containing no bigger plugs as Elementor or image plugs using lazyloader, I saw that the settings.php doesn't contain the line 191, while updating 6.2 to 6.3 via WP.

So this problem will show up, if you install 6.3 manually.

[spacedmonkey]

@joemcgill how about something like this.

function wp_metadata_lazyloader() {
  static $wp_metadata_lazyloader;

  if ( null === $wp_metadata_lazyloader ) {
    if( ! class_exists( ‘ WP_Metadata_Lazyloader’ ) {
         require ABSPATH . WPINC . '/class-wp-metadata-lazyloader.php';
     }
    $wp_metadata_lazyloader = new WP_Metadata_Lazyloader();
  }

  return $wp_metadata_lazyloader;
}

[mukesh27]

#59163 was marked as a duplicate.

[gyanendrasingh]

I have done following steps

1. Manual download WP 6.3 version
2. Replace wp_settings files using FTP
3. This allow me to login in WordPress admin
4. Give write only permission to wp-admin folder
5. Again update the 6.3 version from admin panel
6. Voila ,its working like charm
7. Remove write only permission from wp-admin

Regards
Gyanendra

[SergeyBiryukov]

Please keep the ticket open until a fix is committed to WordPress core. Thanks!

[gyanendrasingh]

Thanks @SergeyBiryukov .i will keep this for future reference as this is my first post as in this community.

[audrasjb]

As per today's bug scrub and since 6.3.1 is going to be released in the next few days, let's move this ticket to milestone 6.3.2.

[wedstories1]

I upgraded WordPress. My website is not running and I am not able to login to the dashboard. Is this because of 6.3 update ???

[gyanendrasingh]

Replying to wedstories1:

I upgraded WordPress. My website is not running and I am not able to login to the dashboard. Is this because of 6.3 update ???

Mostly yes , based on input i got it from this thread, i have created one article ​https://cognicsys.com/blog/backend-fatal-error-php-fatal-error-cannot-declare-class-wp_metadata_lazyloader-because-the-name-is-already-in-use-in/, please take a look it might help for you

[joemcgill]

Replying to SergeyBiryukov:

Please keep the ticket open until a fix is committed to WordPress core. Thanks!

I'm not sure if this is something we can fix with a change to core at this point. If I'm correctly understanding most of the issues that have been reported, we've moved the inclusion of the file that declares the WP_Metadata_Lazyloader class to a different file, /wp-includes/meta.php, which is loaded earlier in the bootstrap process than the previouswp-settings.php file.

However, if the old file doesn't get updated then the only fix I can think of would be to add a check inside the class-wp-metadata-lazyloader.php file that returns early if the class has already been loaded. While this would work, it would essentially make the whole class pluggable, where it could be replaced by any third party code that is loaded earlier, which is less than ideal.

This doesn't seem to actually fix the root cause of the issue most people are experiencing, so I'm closing for now as an invalid approach.

[joemcgill]

Given the lack of a clear fix for this in Core, and given that this seemed to be related to faulty upgrades that could be fixed by reinstalling, I'm marking this as closed. We can reopen if folks have additional info to add.

[keakin]

Replying to joemcgill:

Hi @alexpaterson, welcome to Trac! It sounds to me like something specific to your environment is trying to load this class twice. Could you share any more info about the callstack that is displayed when you see this error?

In case it's helpful, this class used to be loaded in wp-settings.php, but was moved to /wp-includes/meta.php in WP 6.3 so it would be loaded earlier for environments that tried to invoke the class during sunrise.php. See https://core.trac.wordpress.org/ticket/58185#comment:8 (and the resulting discussion).

[keakin]

I am having this same issue. I updated a client's site to WordPress 6.3 and got this critical error:
Fatal error: Cannot declare class WP_Metadata_Lazyloader, because the name is already in use...

[treibstoff]

Replying to keakin:

I am having this same issue. I updated a client's site to WordPress 6.3 and got this critical error:
Fatal error: Cannot declare class WP_Metadata_Lazyloader, because the name is already in use...

You updated it manually or via the WordPress Update?
As I see this Lazyloader Error appears if it's updated manually.

[vinnenroute2019]

Hello, i have a similar issue: /home/cjpulghm795s/public_html/wp-includes/class-wp-metadata-lazyloader.php on line 32

after updating to wp 6.3. Now i cant access wp-admin. I went to my hosting company and they tried to troubleshoot but to no avail. also the live website cant be accessed.

I really need help, thank you.

[ashishseo18]

In My local server it's working but when I upload on main server it's showing same error Fatal error: Cannot declare class WP_Metadata_Lazyloader, because the name is already in use in