Make WordPress Core

Opened 10 months ago

Closed 5 months ago

#59057 closed defect (bug) (wontfix)

Critical error after update to 6.3 due to WP_Metadata_Lazyloader

Reported by: alexpaterson's profile alexpaterson Owned by: joemcgill's profile joemcgill
Milestone: Priority: normal
Severity: critical Version: 6.3
Component: General Keywords: 2nd-opinion close
Focuses: Cc:

Description

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

Change History (44)

#1 follow-ups: @joemcgill
10 months ago

  • Keywords reporter-feedback added

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).

#2 @joemcgill
10 months ago

#59059 was marked as a duplicate.

#3 in reply to: ↑ 1 ; follow-up: @alexpaterson
10 months ago

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

#4 @joemcgill
10 months ago

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.

#5 @alexpaterson
10 months ago

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

#6 @joemcgill
10 months ago

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');

#7 @swissspidy
10 months ago

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 ticket was mentioned in PR #4992 on WordPress/wordpress-develop by joemcgill.


10 months ago
#8

  • Keywords has-patch added

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

#9 @alexpaterson
10 months ago

  • Keywords has-patch removed

Hi @joemcgill,

That hasn't worked unfortunately.

#10 @joemcgill
10 months ago

  • Keywords has-patch added

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?

#11 @alexpaterson
10 months ago

That hasn't worked either I'm afraid

#12 @joemcgill
10 months ago

  • Keywords reporter-feedback removed
  • Milestone changed from Awaiting Review to 6.3.1
  • Owner set to joemcgill
  • Status changed from new to assigned

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.

#13 @alexpaterson
10 months ago

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

#14 @joemcgill
10 months ago

@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.

#15 @alexpaterson
10 months ago

Will try that now, thanks!

#16 in reply to: ↑ 3 @SergeyBiryukov
10 months ago

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?

#17 follow-up: @alexpaterson
10 months ago

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

#18 @Jeffinho2016
10 months ago

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

Last edited 10 months ago by Jeffinho2016 (previous) (diff)

#19 in reply to: ↑ 17 @SergeyBiryukov
10 months ago

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.

#20 @dominickferone
10 months ago

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.

#21 follow-up: @Jeffinho2016
10 months ago

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.

#22 @joemcgill
10 months ago

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).

#23 @dominickferone
10 months ago

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.

#24 in reply to: ↑ 21 @Jeffinho2016
10 months ago

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.

#25 @treibstoff
9 months ago

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.

Last edited 9 months ago by treibstoff (previous) (diff)

#26 @spacedmonkey
9 months ago

@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;
}

#27 @mukesh27
9 months ago

#59163 was marked as a duplicate.

#28 @gyanendrasingh
9 months ago

  • Resolution set to worksforme
  • Status changed from assigned to closed

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

#29 follow-up: @SergeyBiryukov
9 months ago

  • Resolution worksforme deleted
  • Status changed from closed to reopened

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

#30 @gyanendrasingh
9 months ago

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

#31 @audrasjb
9 months ago

  • Milestone changed from 6.3.1 to 6.3.2

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.

#32 follow-up: @wedstories1
9 months ago

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 ???

#33 in reply to: ↑ 32 @gyanendrasingh
9 months ago

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

Last edited 9 months ago by gyanendrasingh (previous) (diff)

#34 in reply to: ↑ 29 @joemcgill
9 months ago

  • Keywords 2nd-opinion added; has-patch removed

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.

joemcgill commented on PR #4992:


9 months ago
#35

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.

This ticket was mentioned in Slack in #core by joemcgill. View the logs.


8 months ago

#37 @joemcgill
8 months ago

  • Keywords close added
  • Milestone 6.3.2 deleted
  • Resolution set to wontfix
  • Status changed from reopened to closed

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.

#38 in reply to: ↑ 1 @keakin
8 months ago

  • Resolution wontfix deleted
  • Status changed from closed to reopened

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).

#39 follow-up: @keakin
8 months ago

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...

#40 in reply to: ↑ 39 @treibstoff
8 months ago

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.

#41 @vinnenroute2019
8 months ago

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.

#42 @ashishseo18
8 months ago

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

#43 @dealazer
5 months ago

Solution for this is to downgrade to 6.2.2 then update the wordpress to latest.
You downgrade by deleting both wp-admin and wp-includes. And use the archive files of 6.2.2 and drop them into the root of website. Then upgrade through normal upgrade procedure while logged in on site.

I used PHP 7.4 and didn't try with php 8.0. I believe different errors occur by both versions. The upgrade fixes some database errors or linking problems.

#44 @joemcgill
5 months ago

  • Resolution set to wontfix
  • Status changed from reopened to closed

For anyone still running into this issue, if you can't do a full downgrade and running the upgrade again doesn't resolve the problem—or if you are uploading the updated files manually, ensure the wp-settings.php file in your WP install is up to date with the latest version of WordPress that you are running. If somehow you have an old version of that file (pre 6.3), you will run into this error.

Note: See TracTickets for help on using tickets.