#54507 closed defect (bug) (reported-upstream)
Site Editor does not load when using "almost pretty" permalinks
Reported by: | noisysocks | Owned by: | |
---|---|---|---|
Milestone: | Priority: | normal | |
Severity: | normal | Version: | |
Component: | REST API | Keywords: | |
Focuses: | Cc: |
Description
The Site Editor does not load if the site's permalink structure is set to the "almost pretty" structure. This is the default permalink structure when WordPress is installed on a server that does not support URL rewriting.
Steps to reproduce:
- Go to WP Admin → Settings → Permalinks.
- Select Custom Structure and enter
/index.php/%year%/%monthnum%/%day%/%postname%/
into the text field. - Go to WP Admin → Appearance → Editor.
- You'll see a WSOD.
The WSOD occurs because the Site Editor tries to access a property on a null template object.
The template object is null because the request made to /wp/v2/templates/twentytwentytwo//home
results in a 404 error.
You can confirm this locally:
$ http -a admin:password GET http://wp-git-build.test/index.php/wp-json/wp/v2/templates/twentytwentytwo//home context==edit HTTP/1.1 404 Not Found { "code": "rest_template_not_found", "data": { "status": 404 }, "message": "No templates exist with that id." }
The request results in a 404 error because the REST API endpoint is looking for a template named twentytwentytwo/home
, not twentytwentytwo//home
. (Note the number of slashes.)
This is because, when the "almost pretty" permalink structure, WordPress will use $_SERVER['PATH_INFO']
as the route. PATH_INFO
will collapse double slashes.
You can confirm this by adding a var_dump()
to wp-settings.php
:
var_dump( $_SERVER['PATH_INFO'] ); // string(45) "/wp-json/wp/v2/templates/twentytwentytwo/home"
Change History (23)
#4
follow-up:
↓ 8
@
3 years ago
That's unfortunate.
Yeah the issue with giving these routes URLs based on their resources is that a theme identifier can have a slash when a subdirectory theme is in use, for instance theme-experiments/tt1-blocks
, but the template part can also have an arbitrary series of slashes.
This is the problem we were running into originally: https://github.com/WordPress/gutenberg/pull/27910/commits/b637fe353b4f2c4763ee59a0ebeb8312baa6172a#r553288550
Does the "correct" route appear anywhere in $_SERVER
?
We may need to figure out a way to percent encode slashes in the theme identifier or template parts instead and then transform that back when passing the ID to the internal API functions.
This ticket was mentioned in Slack in #core-restapi by zieladam. View the logs.
3 years ago
This ticket was mentioned in Slack in #core-restapi by antonvlasenko. View the logs.
3 years ago
#7
@
3 years ago
I proposed a fix (fallback resolution mechanism) in the Gutenberg repo: https://github.com/WordPress/gutenberg/pull/36881
#8
in reply to:
↑ 4
@
3 years ago
Replying to TimothyBlynJacobs:
Does the "correct" route appear anywhere in
$_SERVER
?
In a local setup, these are the two properties in $_SERVER
that I found matching //
:
[REQUEST_URI] => /test-path.php/a/b//c [PHP_SELF] => /test-path.php/a/b//c
Looking at the documentation for PHP_SELF
, I would say that REQUEST_URI
is a better bet.
#9
@
3 years ago
@mcsf it's complicated :( You'll get different data in different setups. I'm playing with preparePathInfo() that Symfony uses – it tries to lean on REQUEST_URI when possible:
#10
@
3 years ago
A workaround was merged in https://github.com/WordPress/gutenberg/pull/36881, although it still needs to be backported to core. cc @noisysocks
This ticket was mentioned in Slack in #core by audrasjb. View the logs.
3 years ago
#12
@
3 years ago
- Milestone 5.9 deleted
- Resolution set to reported-upstream
- Status changed from new to closed
Closing this ticket as it was fixed upstream and backported.
This ticket was mentioned in Slack in #core by sergey. View the logs.
3 years ago
#14
@
3 years ago
- Resolution reported-upstream deleted
- Status changed from closed to reopened
I'm seeing this same issue with 5.9-beta1
Steps to reproduce
- Install 5.9-beta1
- Set permalinks to Numeric (but no .htaccess file)
- Use TwentyTwentyTwo Theme
- Open site editor
Fail for JSON request: http://localhost:8003/wp-json/wp/v2/templates/twentytwentytwo//home?context=edit&_locale=user
If I add an .htaccess file it works correctly, or if I disable permalinks.
So to some degree my site is misconfigured and the JSON API requests fail. This causes the site editor to be completely blank, the post editor has errors for areas that require fetching JSON data such as authors, categories, tags, etc..
This ticket was mentioned in Slack in #core by hellofromtonya. View the logs.
3 years ago
#17
@
3 years ago
At the very minimum we should handle the potential failure of the request to /wp/v2/templates
more gracefully. There's a missing null check somewhere which causes the WSOD. It would be better to display an error toast.
This ticket was mentioned in Slack in #core by audrasjb. View the logs.
3 years ago
#19
@
3 years ago
@TimothyBlynJacobs @noisysocks What should happen here in response to the error @mkaz encountered?
#20
follow-up:
↓ 22
@
3 years ago
As @mkaz says, it's a misconfigured site, so I think we just need to fail more gracefully. From memory there's an object destruct somewhere in the edit-site
initialisation which needs a null check. I don't think it's a blocker for 5.9. Since the fix is on the Gutenberg end of things we should move this ticket over to GitHub.
#21
@
3 years ago
I looked at it briefly and there might be a couple of ways to solve.
The is-fullscreen-mode
class is added to the body which hides the sidebar, if that class is added after the page loads than if it fails to load, the user will still have the standard /wp-admin/ sidebar. The drawback is the UI flashes during the load.
I think another option would be to remove this class on a failure and the sidebar would show, at least giving the user a way to navigate elsewhere.
Here's what that would look like:
#22
in reply to:
↑ 20
@
3 years ago
- Milestone 5.9 deleted
- Resolution set to reported-upstream
- Status changed from reopened to closed
Quoting noisysocks:
As @mkaz says, it's a misconfigured site, so I think we just need to fail more gracefully. From memory there's an object destruct somewhere in the edit-site initialisation which needs a null check. I don't think it's a blocker for 5.9. Since the fix is on the Gutenberg end of things we should move this ticket over to GitHub.
I agree. @mkaz can you open an issue in Gutenberg and then share the issue link in this ticket?
As this is moving upstream, I'll re-close this ticket.
#23
@
3 years ago
Agreed, not a blocker for WP 5.9
Ticket: https://github.com/WordPress/gutenberg/issues/37236
@youknowriad @bernhard-reiter @TimothyBlynJacobs: Any ideas on how to fix this? I think it's somewhat major since this type of permalink structure is often the default.