Make WordPress Core

Opened 3 months ago

Closed 2 months ago

Last modified 2 months ago

#61188 closed defect (bug) (worksforme)

switch_to_blog() causes Fatal error on classic themes

Reported by: digberlin's profile digberlin Owned by:
Milestone: Priority: normal
Severity: normal Version: 6.5.3
Component: General Keywords:
Focuses: multisite Cc:

Description

switch_to_blog() causes a fatal error "Allowed memory size of XXX bytes exhausted" on class-wpdb.php.
Does not happen when users are logged into the WordPress backend.
Tested on classic themes including Twenty Twenty-One. Twenty Twenty-Four seems to not be affected.
Tested on WP versions 6.5.2 and 6.5.3. WP version 6.4.x not affected.

Change History (8)

#1 follow-up: @swissspidy
3 months ago

  • Keywords reporter-feedback added

Hi there and welcome to WordPress Trac!

Can you please share some code to reproduce this issue and where exactly you are using this code?

It sounds like your code is inadvertently creating some infinite loop or so, hence the memory issue.

#2 in reply to: ↑ 1 @digberlin
3 months ago

Replying to swissspidy:

Hi there and welcome to WordPress Trac!

Can you please share some code to reproduce this issue and where exactly you are using this code?

It sounds like your code is inadvertently creating some infinite loop or so, hence the memory issue.

Thank you swissspidy for looking into this.

In my themes, I switch to the main site on a multisite installation and get customs posts.

But this error occurs even when just calling switch_to_blog() and nothing else.

For testing, I added this

switch_to_blog(1);
restore_current_blog();

to functions.php on a clean Twenty Twenty-One Theme running on WP 5.6.3 with no plug-ins active. Also tested on both, local dev and live production installations.

Also tested on multiple other themes with same result:

Fatal error: Allowed memory size of 536870912 bytes exhausted (tried to allocate 8388608 bytes) in [redacted]/wordpress/wp-includes/class-wpdb.php on line 2320

When switching to any other site, like

switch_to_blog(7);
restore_current_blog();

adds an additional error

Fatal error: Allowed memory size of 536870912 bytes exhausted (tried to allocate 20480 bytes) in [redacted]/wordpress/wp-includes/class-wpdb.php on line 2320

Fatal error: Allowed memory size of 536870912 bytes exhausted (tried to allocate 20480 bytes) in [redacted]/wordpress/wp-includes/class-wp-fatal-error-handler.php on line 76

Twenty Twenty-Four is unaffected.
WP 6.4 is unaffected.

#3 follow-up: @swissspidy
3 months ago

I still can't reproduce this with such a setup on 6.5. With multiple sites using Twenty Twenty-One, I added some code to functions.php and switching to a different site and getting some posts from there works just fine.

Maybe someone else has more luck; otherwise it sounds more like an issue with your specific setup.

#4 in reply to: ↑ 3 @digberlin
3 months ago

Replying to swissspidy:

I still can't reproduce this with such a setup on 6.5. With multiple sites using Twenty Twenty-One, I added some code to functions.php and switching to a different site and getting some posts from there works just fine.

Maybe someone else has more luck; otherwise it sounds more like an issue with your specific setup.

Where you logged into the WordPress backend while testing? The error does not occur when being logged in.

#5 @swissspidy
3 months ago

No errors on my setup, regardless if logged in or out.

#6 @digberlin
2 months ago

Found the culprit: object-cache.php installed by the Performance Lab plugin (Version 3.0.0; https://make.wordpress.org/performance/) which reamins in the wp-content folder even after uninstalling the plugin.

#7 @swissspidy
2 months ago

  • Component changed from Themes to General
  • Keywords reporter-feedback removed
  • Milestone Awaiting Review deleted
  • Resolution set to worksforme
  • Status changed from new to closed

That's interesting. I filed an issue on the Performance Lab repository for the team to investigate. At the very least it should clean up after itself.

Closing this since it's not a core issue.

#8 @swissspidy
2 months ago

@digberlin Just a quick follow-up FYI: Performance Lab does remove the object cache drop-in upon plugin deactivation.

Note: See TracTickets for help on using tickets.