#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: |
|
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)
#2
@
6 years 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 :-)
#4
@
6 years ago
Apologies...I just realised I did not have logging enabled. That would have been helpful...oops :-O
#5
@
6 years 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
@
6 years 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
@
6 years 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:
βΒ 12
@
6 years 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
@
6 years 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
@
6 years 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
@
6 years 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
@
6 years 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
@
6 years 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
@
6 years 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
@
6 years 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
@
6 years 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.
#17
@
6 years 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.
6 years ago
#19
in reply to:
βΒ 18
@
6 years 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.
#20
@
6 years 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
@
6 years 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?
#22
@
6 years ago
Addressing this in the plugin: βhttps://github.com/WordPress/gutenberg/pull/11375
#23
@
6 years 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
@
6 years ago
Yup, auto-updates have rolled out, as can be seen in yesterday's βludicrous spike in downloads.
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.