WordPress.org

Make WordPress Core

Opened 2 months ago

Closed 6 weeks ago

Last modified 6 weeks ago

#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:

  1. Go to WP Admin → Settings → Permalinks.
  2. Select Custom Structure and enter /index.php/%year%/%monthnum%/%day%/%postname%/ into the text field.
  3. Go to WP Admin → Appearance → Editor.
  4. 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)

#1 @noisysocks
2 months ago

  • Milestone changed from Awaiting Review to 5.9

#2 @noisysocks
2 months ago

@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.

#3 @swissspidy
2 months ago

So the editor requires double slashes? 🤔 That‘s a bit odd/unexpected.

#4 follow-up: @TimothyBlynJacobs
2 months 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.


2 months ago

This ticket was mentioned in Slack in #core-restapi by antonvlasenko. View the logs.


2 months ago

#7 @zieladam
2 months ago

I proposed a fix (fallback resolution mechanism) in the Gutenberg repo: https://github.com/WordPress/gutenberg/pull/36881

Last edited 2 months ago by zieladam (previous) (diff)

#8 in reply to: ↑ 4 @mcsf
2 months 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 @zieladam
2 months 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:

https://github.com/WordPress/wordpress-develop/pull/1956

Last edited 2 months ago by zieladam (previous) (diff)

#10 @zieladam
2 months 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.


8 weeks ago

#12 @audrasjb
8 weeks 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.


8 weeks ago

#14 @mkaz
8 weeks ago

  • Resolution reported-upstream deleted
  • Status changed from closed to reopened

I'm seeing this same issue with 5.9-beta1

Steps to reproduce

  1. Install 5.9-beta1
  2. Set permalinks to Numeric (but no .htaccess file)
  3. Use TwentyTwentyTwo Theme
  4. 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..

Last edited 8 weeks ago by mkaz (previous) (diff)

#15 @SergeyBiryukov
8 weeks ago

  • Milestone set to 5.9

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


8 weeks ago

#17 @noisysocks
8 weeks 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.


7 weeks ago

#19 @hellofromTonya
7 weeks ago

@TimothyBlynJacobs @noisysocks What should happen here in response to the error @mkaz encountered?

#20 follow-up: @noisysocks
7 weeks 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 @mkaz
7 weeks 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:

https://cldup.com/NrfpEfTg2l.png

#22 in reply to: ↑ 20 @hellofromTonya
6 weeks 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 @mkaz
6 weeks ago

Agreed, not a blocker for WP 5.9

Ticket: https://github.com/WordPress/gutenberg/issues/37236

Note: See TracTickets for help on using tickets.