Fatal Error during upgrade (upgrade.php) caused by theme unavailability

[thomasfw]

Some Context

We have a number of mu-plugins that handle core functionality in our client's website. Within one of these mu-plugins, we're using a class that's defined in the active theme in order to load a template part. I'm aware that this wouldn't be advised for either a distributed plugin or theme, but our project utilises Bedrock, Composer etc. to lock everything down, so the active theme and (mu-)plugins cannot be changed.

The mu-plugin in question registers a shortcode with add_shortcode(), and we're using the theme's helper class in the callback to output some pagination within the shortcode.

The Issue

After upgrading WP, the dashboard redirect to "mywebsite.test/wp-admin/upgrade.php" results in a blank screen, and i'm not able to upgrade the database or view the dashboard.

Because upgrade.php is seemingly not loading the theme (whilst all mu-plugins are loaded), a fatal error occurs because the class dependency inside our mu-plugin can't be found.

In an attempt to resolve this I tried registering the shortcode only after the theme was initialised, by hooking on the after_setup_theme action, instead of on init.

The after_setup_theme action as described in the WP docs - "This is the first action hook available to themes, triggered immediately after the active theme's functions.php file is loaded.".

So one would assume that this action would only be fired when the theme was available, making it a suitable candidate, but the fatal error still occurs. Why does this action still fire when it appears that the theme is not loaded during the upgrade process?

What does fix this for me is using an even later hook (template_redirect) to register the shortcode. In this case, the upgrade.php page loads without a fatal error and I am able to upgrade the site, but i'm unsure of any potential side effects of registering a shortcode so late on, and i'm hoping there's a potential fix available in the core to prevent this issue reoccurring.

[costdev]

Hi @thomasfw, thanks for opening this ticket.

While I appreciate that you have a setup that locks things down, I would recommend keeping all mu-plugin dependencies within the mu-plugins folder, and load them with the mu-plugin.

However, taking your setup and issue into account, I note that you didn't mention the priority with which you hooked after_setup_theme. As a later hook worked, it may be possible that add_action( 'after_setup_theme', 'add_my_shortcode', 999 ); may have resolved the issue. Ultimately, it depends on when the theme first defines the class.

For now, I think this could be explored in ​the "Developing with WordPress" support forums.

I'll close this ticket as invalid, but not because your issue is invalid. It's just the keyword we use when this hasn't definitively identified an issue in WordPress Core, and the conversation should occur elsewhere to explore some possibilities.