Opened 3 years ago
Closed 3 years ago
#54544 closed defect (bug) (worksforme)
fatal error when entering the site editor after updating to 5.9-beta1
Reported by: | pbiron | Owned by: | |
---|---|---|---|
Milestone: | Priority: | normal | |
Severity: | normal | Version: | 5.9 |
Component: | Editor | Keywords: | reporter-feedback |
Focuses: | Cc: |
Description (last modified by )
After updating to 5.9-beta1 via the [xx Beta Tester plugin], when I switch to the 2022 them and try to enter the site editor, I get the following fatal error:
Fatal error: Uncaught Error: Class 'WP_REST_Edit_Site_Export_Controller' not found in /path-to-site/wp-includes/rest-api.php on line 354
I do not have CLI access to the site that is experiencing that problem, so it's hard for me to debug the problem any further.
I also updated a few other sites on my local machine and I'm getting that error on the other sites.
Here's the full error log:
[30-Nov-2021 23:46:30 UTC] PHP Fatal error: Uncaught Error: Class 'WP_REST_Edit_Site_Export_Controller' not found in /path-to-site/wp-includes/rest-api.php:354 Stack trace: #0 /path-to-site/wp-includes/class-wp-hook.php(303): create_initial_rest_routes(Object(WP_REST_Server)) #1 /path-to-site/wp-includes/class-wp-hook.php(327): WP_Hook->apply_filters(NULL, Array) #2 /path-to-site/wp-includes/plugin.php(470): WP_Hook->do_action(Array) #3 /path-to-site/wp-includes/rest-api.php(553): do_action('rest_api_init', Object(WP_REST_Server)) #4 /path-to-site/wp-includes/rest-api.php(511): rest_get_server() #5 /path-to-site/wp-includes/rest-api.php(2860): rest_do_request(Object(WP_REST_Request)) #6 [internal function]: rest_preload_api_request(Array, '/wp/v2/media') #7 /path-to-site/wp-includes/block-editor.php(474): array_reduce(Array, 'rest_preload_ap...', Array) #8 /path-to-site/wp-admin/site-editor.php(108): block_edit in /path-to-site/wp-includes/rest-api.php on line 354
Attachments (1)
Change History (21)
This ticket was mentioned in Slack in #core by costdev. View the logs.
3 years ago
#4
follow-up:
↓ 11
@
3 years ago
- Keywords reporter-feedback added
Hi @pbiron, I can't seem to reproduce this.
Can you provide these environment details?
- WordPress version (before updating):
- OS:
- Localhost:
- PHP:
- Database:
- Browser:
This ticket was mentioned in Slack in #core by hellofromtonya. View the logs.
3 years ago
This ticket was mentioned in Slack in #core by ndiego. View the logs.
3 years ago
#7
@
3 years ago
Noting that I can't reproduce this either and have tried across two different test sites (and multiple different block themes including TT2).
#8
follow-up:
↓ 10
@
3 years ago
I was able to replicate by following the TT2 testing instructions. I downloaded the latest tagged release: https://github.com/WordPress/twentytwentytwo/tags and uploaded it directly to my test environment running 5.9 Beta. In doing so, the theme folder is twentytwentytwo-0.4.0
. If you then try and access the Site Editor, you get the fatal error. Correcting the theme folder back to twentytwentytwo
made the fatal error disappear.
#9
@
3 years ago
Nice find @ndiego!
@pbiron, can you let us know if you had previously installed Twenty Twenty Two from https://github.com/WordPress/twentytwentytwo/tags or if it was only installed with 5.9.0 Beta 1?
#10
in reply to:
↑ 8
@
3 years ago
I have replicated this on three different fresh installs, it appears it might be unique to Twenty Twenty Two. I tested a custom FSE theme by modifying the theme folder name and this issue did not occur.
Replying to ndiego:
I was able to replicate by following the TT2 testing instructions. I downloaded the latest tagged release: https://github.com/WordPress/twentytwentytwo/tags and uploaded it directly to my test environment running 5.9 Beta. In doing so, the theme folder is
twentytwentytwo-0.4.0
. If you then try and access the Site Editor, you get the fatal error. Correcting the theme folder back totwentytwentytwo
made the fatal error disappear.
#11
in reply to:
↑ 4
@
3 years ago
Replying to costdev:
Hi @pbiron, I can't seem to reproduce this.
As mentioned in the ticket description, I can't replicate the problem on any of the local sites I've updated...just on that one remote site (details below).
Can you provide these environment details?
- WordPress version (before updating): 5.8.2
- OS: Linux (shared hosting environment, so probably some flavor of cloudlinux)
- PHP: 7.3.33
- Database: MySQL 5.7.36
- Browser: Firefox 94.0.2 (64-bit)
I've rolled the affected back to to 5.8.2 and then did the update again (via Beta Tester, a few times) with the same results. I'll see if I can put some time aside to do the update on a one or 2 other cPanel-managed sites I have access to (not sure when I'll be able to do that, tho).
@pbiron, can you let us know if you had previously installed Twenty Twenty Two from
https://github.com/WordPress/twentytwentytwo/tags or if it was only installed with 5.9.0 Beta 1?
Installed as part of the beta1 update.
#12
@
3 years ago
Ok, I may have narrowed this down further. Sorry for the multiple comments. If there is a period in the theme folder name, i.e. twentytwentytwo-0.4.0
, this fatal error occurs. It has some to do with this console error:
http://wplatest.local/wp-json/wp/v2/templates/twentytwentytwo-0.4.0//home?context=edit&_locale=user 404 (Not Found)
This ticket was mentioned in Slack in #core by audrasjb. View the logs.
3 years ago
#14
@
3 years ago
Confirmed @ndiego that period in block theme name is an issue.
Steps using WP 5.9-beta1
- Rename classic theme twentytwenty to twenty.twenty
- Confirm site works as expected
- Rename twentytwentytwo to twenty.twentytwo
- Open Site Editor, confirm blank
404 error on this API request:
http://wpbeta.local/wp-json/wp/v2/templates/twenty.twentytwo//home?context=edit&_locale=user
#15
@
3 years ago
Attached diff resolves two issues with the route not being found when a period is in the theme name.
However, I'm still seeing an issue with the Site Editor not loading. The global styles get_item() request gets called twice when loading the Site Editor and one of the calls has an empty post so the check fails.
#16
follow-up:
↓ 17
@
3 years ago
It sounds like there are two separate issues here:
- The original fatal reported by @pbiron when upgrading via the Beta plugin, activating TT2, and visiting the site editor:
Fatal error: Uncaught Error: Class 'WP_REST_Edit_Site_Export_Controller' not found
- An issue caused when the theme is manually uploaded and the theme directory contains periods, reported by @ndiego. I tested @mkaz patch for this, and got the same result with the site editor not loading due to the global styles request.
Am I understanding that right, or are the issues actually related?
#17
in reply to:
↑ 16
@
3 years ago
Replying to jffng:
It sounds like there are two separate issues here:
- The original fatal reported by @pbiron when upgrading via the Beta plugin, activating TT2, and visiting the site editor:
Fatal error: Uncaught Error: Class 'WP_REST_Edit_Site_Export_Controller' not found
- An issue caused when the theme is manually uploaded and the theme directory contains periods, reported by @ndiego. I tested @mkaz patch for this, and got the same result with the site editor not loading due to the global styles request.
Am I understanding that right, or are the issues actually related?
I believe so...because I've tripled-checked and the TT2 theme on the site I updated is that included in the 5.9-beta1 package and does not have any periods in its slug.
This ticket was mentioned in Slack in #core-themes by kjell. View the logs.
3 years ago
#19
@
3 years ago
I was just investigating more to see if I come up with some explanation why I'm getting the fatal error on the that one site there I'm experiencing it on (where the problem caused by the period in the theme slug doesn't apply).
And now the site editor is working just fine when I switch to TT2...no errors.
All of the plugins that were previously active are still active (I was preparing to start deactivating them to try to isolate a plugin conflict as the cause of the problem, but hadn't done that yet).
So, at this point, I'm willing to chock my previous fatal up to gremlins. Unless anyone else can replicate the problem.
#20
@
3 years ago
- Milestone 5.9 deleted
- Resolution set to worksforme
- Status changed from new to closed
As noted in comment 19, I am no longer experiencing the original problem. I also have not experienced it on ~10-15 other sites I've updated to 5.9-beta1.
Therefore, I'm closing this ticket.
However, the problem identified in comment 12 has been confirmed (and is different than the one I originally experienced). An issue has been opened upstream on that.
Moving into 5.9 milestone for investigation.