1.3.4 Commons in a Box OpenLab upgrade errors- Call to undefined function cbox_is_main_site()

[beckej13820]

The 1.3.4 upgrade created critical errors on my Commons in a Box OpenLab site and had to be aborted.

The error occurred immediately after upgrading the Commons in a Box plugin, but before upgrading any of the other plugin dependencies. "Call to undefined function box_is_main_site"

Navigating away from the upgrade screen, both the front end of the website and dashboard were unavailable, with only the error message.

Here's from the error logs:

[13-Nov-2022 04:44:59 UTC] PHP Fatal error: Uncaught Error: Call to undefined function cbox_is_main_site() in /home/sunycreate/oneonta.sunycreate.cloud/wp-content/plugins/cbox-openlab-core/includes/group-sites.php:2186
Stack trace:
#0 /home/sunycreate/oneonta.sunycreate.cloud/wp-includes/class-wp-hook.php(307): cboxol_maybe_hide_admin_bar_for_anonymous_users('')
#1 /home/sunycreate/oneonta.sunycreate.cloud/wp-includes/class-wp-hook.php(331): WP_Hook->apply_filters(NULL, Array)
#2 /home/sunycreate/oneonta.sunycreate.cloud/wp-includes/plugin.php(476): WP_Hook->do_action(Array)
#3 /home/sunycreate/oneonta.sunycreate.cloud/wp-settings.php(598): do_action('init')
#4 /home/sunycreate/oneonta.sunycreate.cloud/wp-config.php(126): require_once('/home/sunycreat...')
#5 /home/sunycreate/oneonta.sunycreate.cloud/wp-load.php(50): require_once('/home/sunycreat...')
#6 /home/sunycreate/oneonta.sunycreate.cloud/wp-blog-header.php(13): require_once('/home/sunycreat...')
#7 /home/sunycreate/oneonta.sunycreate.cloud/index.php(17): require('/home/sunycreat...')
#8 {main}
in /home/sunycreate/oneonta.sunycreate.cloud/wp-content/plugins/cbox-openlab-core/includes/group-sites.php on line 2186

[bree-z]

Hi Ed - thanks for the report.

I'm not sure if this is helpful in troubleshooting, but I did the update on a test site I have hosted at Reclaim, and didn't experience any issues. I went through the usual process for updating the plugin.

[beckej13820]

Have you upgraded a site that uses subdomains?

[boonebgorges]

Thanks for the report and for the stack trace, @beckej13820

I'm not able to reproduce this issue via several different updates routes:

• The wp plugin update CLI command
• Clicking the 'Update now' link in the 'There is a new version...' yellow notice on /wp-admin/network/plugins.php, which performs the upgrade via AJAX
• At /wp-admin/network/update-core.php, checking the box next to 'Commons In A Box' and clicking 'Update plugins'

However, none of these routes matched your screenshot. So I went digging through the codebase and found that I was able to trick WP into performing an update at the following URL: /wp-admin/update.php?action=upgrade-plugin&plugin=commons-in-a-box%2Floader.php. I'm unsure how to get to this point through the course of normal WP administration, but clearly it is a route that you use :-D In any case, I was able to reproduce the error in this case.

You're seeing the error because the commons-in-a-box plugin is being deactivated as part of the update process. When this happens, various parts of openlab-theme, cbox-openlab-core, openlab-portfolio, and perhaps other tools, can trigger fatal errors. I haven't researched enough to understand why this happens only on this specific upgrade screen. I'm guessing it has something to do with the sandboxing that other plugin upgrade paths use, which apparently doesn't take place on wp-admin/update.php; it seems like on update.php, WP actually temporarily disables commons-in-a-box; when WP then detects a fatal error, it decides that something's wrong with the update, and decides to keep commons-in-a-box deactivated, which is why you see fatal errors on the front end as well.

I will push some changes to the relevant repos that will force those secondary tools to abort their loading process when commons-in-a-box is not present. This should do two things. First, it should prevent WordPress from detecting any fatal errors during its update.php sandboxing, which should in turn prevent WP from deactivating commons-in-a-box during upgrade. Second, it will ensure that if you were to accidentally disable/delete commons-in-a-box by some other means, you won't get fatal errors everywhere - you'll see a blank screen on the front end, but still be able to access wp-admin and manipulate your installation via the Dashboard.

For the record, we've never attempted to build a better system for explaining plugin dependencies to users, because commons-in-a-box was designed to handle all this stuff behind the scenes. CBOX should ensure internal consistency between its tools. But this only works if CBOX itself is active, which is a condition that can obviously be thwarted in some sets of circumstances.

[beckej13820]

Thanks Boone,

Always happy to break my server in new and creative ways in order to make it easier for the next open source adopter...

On my server, when I am on the plugins screen and I hit the update now button, it leads to the url that you described /wp-admin/update.php?action=upgrade-plugins&plugin=commons-in-a-box....

[boonebgorges]

Thanks, Ed. On my test installations, clicking this button results in an AJAX request. Maybe there's some broken JS on your page that's preventing this from happening, which causes the fallback behavior of visiting update.php. (If I disable JS in my browser, I can reproduce what you're seeing.)

[boonebgorges]

See the above commits. This should no longer be an issue after the next commons-in-a-box release. Ed, in the meantime, you might consider performing a manual upgrade of commons-in-a-box (download the zip from wordpress.org, then use the plugin zip uploader; or use SFTP/SSH to overwrite the existing wp-content/plugins/commons-in-a-box directory)