WordPress.org

Make WordPress Core

Opened 18 months ago

Closed 17 months ago

Last modified 17 months ago

#45157 closed defect (bug) (invalid)

Upgrading from 4.9.9 to 5.0-alpha-43815 with Gutenberg plugin installed gets whitescreen of death

Reported by: timhibberd Owned by:
Milestone: Priority: normal
Severity: major Version: 5.0
Component: General Keywords:
Focuses: Cc:

Description

I was testing version 4.9.9 with Gutenberg plugin installed. When I upgraded to 5.0-alpha-43815 it killed my WordPress installation. To clear the issue I went in at the server level and removed the Gutenberg plug-in. Site came up ok after that.

So...suggest that upgrade to 5.0 checks for presence of Gutenberg plug-in and prompts the user to remove it before upgrading.

Change History (24)

#1 @pento
18 months ago

  • Milestone changed from Awaiting Review to 5.0

Thank you for the bug report, @timhibberd!

Can you tell us more about how you upgraded from 4.9.9 to 5.0? The upgrade routine is supposed to disable the Gutenberg plugin, but it sounds like it didn't run in your case.

#2 @timhibberd
18 months ago

I am running the WordPress Beta Testing plugin set to bleeding edge. I upgraded using the standard WordPress upgrade mechanism. Press the button and go :-)

#3 @pento
18 months ago

Well, that's a problem. πŸ™‚

@mcsf: Can you check this out?

#4 @timhibberd
18 months ago

Apologies...I just realised I did not have logging enabled. That would have been helpful...oops :-O

#5 @mcsf
18 months ago

That’s odd and unfortunate. I’ll have a look.

Meanwhile, can you confirm you did not have the GUTENBERG_USE_PLUGIN constant defined manually or by a plugin? This constant prevents plugin deactivation upon upgrading.

#6 @timhibberd
18 months ago

Context: I have all the 3rd-party Gutenberg block plugins from the WordPress.org directory installed to test them all out.

In answer to your question...

I just ran a recursive GREP on the WordPress folder grep -R "GUTENBERG_USE_PLUGIN" * and the only file GUTENBERG_USE_PLUGIN shows up in is wp-admin/includes/upgrade.php in the code line as follows: if ( defined( 'GUTENBERG_USE_PLUGIN' ) && GUTENBERG_USE_PLUGIN )

#7 @timhibberd
18 months ago

Update...I am running WordPress in a Docker container so it is quick for me to spin one up. I just spun one up and just installed the WP Log Viewer, WordPress Beta Tester and Gutenberg plugins and did an upgrade to 5.0-alpha-43815 and the upgrade went fine.

I will spin up another WordPress container and install all the plugins I had installed when I encountered the upgrade WOD but this time I will enable logging. I'll let you know in 10 minutes if I can reproduce the WOD and identify the culprit from the log. Stay tuned...

#8 follow-up: @timhibberd
18 months ago

I have reproduced the problem. Reproduce the following way...

WordPress with default theme and the following plug-ins installed:

Advanced Gutenberg, Advanced Gutenberg Blocks, Akismet Anti-Spam, Atomic Blocks - Gutenberg Blocks Collection, Block Options, Bokez β€” Awesome Gutenberg Blocks, Caxton, CoBlocks, Editor Blocks for Gutenberg, FooBox Image Lightbox, Gutenberg, Gutenberg Block Unit Test, Gutenberg Boilerplate, Gutenberg Custom Fields, Gutenberg Manager, Kadence Blocks - Gutenberg Page Builder Toolkit, Maps Block for Gutenberg, Stackable - Ultimate Gutenberg Blocks, WordPress Beta Tester, WP Log Viewer

Using the WordPress Beta Tester set to Point release nightlies update WordPress to 4.9.9. Then switch the WordPress Beta Tester to Bleeding edge nightlies and update to 5.0-alpha-43818.

This triggers a WOD. To clear the fatal error login into the server and delete the Gutenberg plugin.

The fatal error triggered is as follows:

Cannot redeclare class WP_REST_Blocks_Controller

File: /var/www/wordpress/wp-content/plugins/gutenberg/lib/class-wp-rest-blocks-controller.php on line 0

#9 @timhibberd
18 months ago

I did a follow-up grep -R "WP_REST_Blocks_Controller" * on the WordPress directory and the fatal error that occurred in the Gutenberg plug-in wp-content/plugins/gutenberg/lib/class-wp-rest-blocks-controller.php on line 0 might have been caused through collision with one of the following:

1) wp-includes/rest-api/endpoints/class-wp-rest-blocks-controller.php: * Reusable blocks REST API: WP_REST_Blocks_Controller class

2) wp-includes/rest-api/endpoints/class-wp-rest-blocks-controller.php:class WP_REST_Blocks_Controller extends WP_REST_Posts_Controller {

3) wp-includes/post.php: 'rest_controller_class' => 'WP_REST_Blocks_Controller',

#10 @mcsf
18 months ago

@timhibberd, all this debugging is incredibly helpful, thanks. Once I'm able to switch tasks I'll see what we can fix there.

#11 @TimothyBlynJacobs
18 months ago

I also get a fatal when coming from bleeding edge nightlies ( 5.1-something or other ) and the Gutenberg plugin is active.

[24-Oct-2018 14:40:31 UTC] PHP Fatal error:  Cannot declare class WP_REST_Blocks_Controller, because the name is already in use in /app/public/wp-content/plugins/gutenberg/lib/class-wp-rest-blocks-controller.php on line 123
[24-Oct-2018 14:40:31 UTC] PHP Stack trace:
[24-Oct-2018 14:40:31 UTC] PHP   1. {main}() /app/public/wp-admin/about.php:0
[24-Oct-2018 14:40:31 UTC] PHP   2. require_once() /app/public/wp-admin/about.php:10
[24-Oct-2018 14:40:31 UTC] PHP   3. require_once() /app/public/wp-admin/admin.php:31
[24-Oct-2018 14:40:31 UTC] PHP   4. require_once() /app/public/wp-load.php:37
[24-Oct-2018 14:40:31 UTC] PHP   5. require_once() /app/public/wp-config.php:104
[24-Oct-2018 14:40:31 UTC] PHP   6. include_once() /app/public/wp-settings.php:322
[24-Oct-2018 14:40:31 UTC] PHP   7. gutenberg_pre_init() /app/public/wp-content/plugins/gutenberg/gutenberg.php:17
[24-Oct-2018 14:40:31 UTC] PHP   8. require_once() /app/public/wp-content/plugins/gutenberg/gutenberg.php:164

#12 in reply to: ↑ 8 @mcsf
18 months ago

Replying to timhibberd:

I have reproduced the problem. Reproduce the following way...

WordPress with default theme and the following plug-ins installed:

Advanced Gutenberg, Advanced Gutenberg Blocks, Akismet Anti-Spam, Atomic Blocks - Gutenberg Blocks Collection, Block Options, Bokez β€” Awesome Gutenberg Blocks, Caxton, CoBlocks, Editor Blocks for Gutenberg, FooBox Image Lightbox, Gutenberg, Gutenberg Block Unit Test, Gutenberg Boilerplate, Gutenberg Custom Fields, Gutenberg Manager, Kadence Blocks - Gutenberg Page Builder Toolkit, Maps Block for Gutenberg, Stackable - Ultimate Gutenberg Blocks, WordPress Beta Tester, WP Log Viewer

Using the WordPress Beta Tester set to Point release nightlies update WordPress to 4.9.9. Then switch the WordPress Beta Tester to Bleeding edge nightlies and update to 5.0-alpha-43818.

Hm, I followed your steps β€” the whole plugin list, plus the two-step upgrade to 4.9.9 then 5.0-alpha-43818, but recorded no failure or items logged. It's certainly an odd issue β€”Β again, thanks for the work here, @timhibberd.

#13 @mcsf
18 months ago

I also get a fatal when coming from bleeding edge nightlies ( 5.1-something or other ) and the Gutenberg plugin is active.

@TimothyBlynJacobs, this is less surprising, though. I assume you were running a nightly after r43765? Which exact version of the plugin were you running? If you weren't running a nightly later than 43765 then I have no clue what would've caused the plugin not to deactivate.

In any case, the failure seems to be the same for both reports.

Cannot redeclare class WP_REST_Blocks_Controller

File: /var/www/wordpress/wp-content/plugins/gutenberg/lib/class-wp-rest-blocks-controller.php on line 0

The issue here is related to ​gb10822, in which the plugin's declaration is hit before the one in core, so any class_exists check in the plugin is useless.

I think the only way forward now, if we want to be safe, is to finally switch the plugin to requiring 5.0.0 as the minimum WP version and removing all the declarations that core already provides.

#14 @TimothyBlynJacobs
18 months ago

I don't think so. It was 5.1, so I think it was never running the 5.0 branch.

$wp_version = '5.1-alpha-43678';
$wp_db_version = 42836;

#15 @mcsf
18 months ago

I think the only way forward now, if we want to be safe, is to finally switch the plugin to requiring 5.0.0 as the minimum WP version and removing all the declarations that core already provides.

I hate this, though, because the plugin should keep working for whoever can't upgrade immediately. Which makes me think of something I'd considered in some other issue or ticket:

Instead of letting the plugin rely on class_exists/function_exists, which are prone to failure, let it more aggressively skip loading of files depending on $wp_version (in short, if it starts with '5.', then skip loading of these entities). Meanwhile, they could even be moved to a lib/4.9-compat directory for added clarity.

#16 @danielbachhuber
18 months ago

Worth noting that WordPress defines the Block classes much earlier than the Gutenberg plugin is loaded.. The class_exists() checks are correct in GB.

However, GB compatibility with WP 5.0 only exists for GB 4.1 (which isn't yet formally released). If you're running GB 4.0 or earlier you can expect WordPress 5.0 to fatal.

Last edited 18 months ago by danielbachhuber (previous) (diff)

#17 @mcsf
18 months ago

See my brief exploration in ​gh11019. In short, I don't think there's much we can do in core's editor-related files or in the plugin.

@timhibberd, were you running Gutenberg 4.0? Since you didn't mention a version, I assume you have the latest found in the directory, which is 4.0. 4.0 is missing some compatibility measures added in 4.1 (which has been in RC stage and is to be released in the next hour). This would partly explain the problem. I see Daniel has already raised this point.

I think the remaining problem may concern the upgrade process itself. Is there anything we can change around update-core.php to make it more robust in case of, say, a plugin behaving poorly?

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


18 months ago

#19 in reply to: ↑ 18 @timhibberd
18 months ago

Replying to slackbot:

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

I was using the public release of the Gutenberg plug-in as of the time I reported the bug which, correct me if I am wrong, would have been 4.0.

Last edited 18 months ago by timhibberd (previous) (diff)

#20 @pento
17 months ago

  • Keywords needs-patch removed
  • Milestone 5.0 deleted
  • Resolution set to invalid
  • Status changed from new to closed

It seems like this was just a temporary issue, for folks who were using Gutenberg 4.0 when they upgraded.

#21 @timhibberd
17 months ago

Agreed with the assessment that this issue occurs with pre-4.1 GB plug-in installed...but if WordPress does not want the bad press associated with a lot of WSODs from the field should we not add a WP5.x upgrade check to verify that installed GB plugin is >=4.1?

#23 @mcsf
17 months ago

​Patches tagged: 4.0.1, 3.9.1, 3.8.1, 3.7.1, 3.6.3.

@pento has proceeded with pushing auto-updates for these. @pento, please confirm and feel free to close this ticket when you're around.

#24 @pento
17 months ago

Yup, auto-updates have rolled out, as can be seen in yesterday's ​ludicrous spike in downloads.

Note: See TracTickets for help on using tickets.