Site Editor and Admin Redesign: Build a solid routing foundation.

[youknowriad]

The site editor has a built-in routing approach that is a bit fragile and hard to scale to the next steps of the Admin Redesign project. It is time to look at it and refactor it to both address its immediate shortcomings (bugs and maintainability) and provide a solid base for the next steps (extensibility, new pages)...

The solution needs to address the following requirements:

• Creating and maintaining routes today is not easy at all. You have to include code in very different places (sidebar routing, multiple sync hooks, and router.js file), we should have a coherent way to define routes.
• There's a lot of bugs when navigating in the site editor due to lingering arguments in the url... Having a consistent API for routing and links will help us address these bugs holistically
• Ultimately, we'd like to split the "routing/shell" of the site editor from its content (the different routes) in order to be able to build multiple site editor like experiences.
• We'd like a simple routing API that we can open later for third-parties (probably starting as a private API as we work through things)

[youknowriad]

I believed #60466 by @jsnajdr solved most of the big issues we had in terms of maintainability, it's also a path forward towards decoupling the layout from the pages. I believe we can probably start experimenting (and using) with a private API to register routes (replace the router.js file with it).

[jsnajdr]

One thing that's currently odd about the site-editor.php router is that the routes are not really routes, but just query params. Sometimes there is a path param, but it's not mandatory. For example, the post edit page has just postType and postId and no path.

In a mainstream router, this would all be just one site-editor.php route with various query parameters.

[youknowriad]

@jsnajdr do you think we should explore pretty permalinks to improve that? I guess it still needs to land on site-editor.php anyway

[jsnajdr]

One prior art that comes to mind is the WordPress REST API. You can use the raw, not-pretty URL where you refer to a PHP file and pass all information in query params:

/index.php?rest_route=/wp/v2/categories&per_page=100&order=asc

But the preferred choice is to have a pretty URL where the rest_route is really a part of the path:

/wp-json/wp/v2/categories?per_page=100&order=asc

I guess that eventually we want to have also wp-admin pretty URLs like this? For example, instead of

/wp-admin/site-editor.php?path=/page&postId=1

there would be this in the URL bar:

/wp-admin/site-editor/page/1

I think that's feasible and worth exploring. One additional question: do we already have other wp-admin use cases, other than Site Editor, where we should explore routing? Like, for example, a DataView enabled Posts page?

My current plan for routing is:

• wrap up the Navigator refactoring by putting backPath links everywhere and abandoning the getBackPath/goToParent methods. It's a heuristic that works in one particular case, but is not universally applicable. It's not always true that the proper back path for /foo/bar/baz is /foo/bar, i.e., removing the last / suffix.
• remove the Navigator/useSyncPathWithURL logic also from Woo's Customize Store UI. Turns out they have a copy&paste of the Site Editor code 🤦
• start these pretty-path explorations, and make further steps towards a respectable @wordpress/router package.

[youknowriad]

Like, for example, a DataView enabled Posts page?

Actually, I think this is one of the next steps that I want to explore. I didn't track this yet but I do want to see whether we can build a "site editor" like experience for posts/categories to replace the "edit.php" we have right now. Should be an experiment first but I was kind of waiting for the routing work to advance a bit to start on that part.

My current plan for routing is:

Sounds good to me.

[jsnajdr]

This code in useInitEditedEntityFromURL is also very suboptimal:

https://github.com/WordPress/gutenberg/blob/77f03d3374603f1fe5e3bbe3a8455ad8330c1ac6/packages/edit-site/src/components/sync-state-with-url/use-init-edited-entity-from-url.js#L204-L246

From the URL, it determines what should be displayed in the content area. We should move this code to the router's useLayoutAreas hook, just like we moved the sidebars. useLayoutAreas currently declares a constant, non-specific preview: <Editor> for all routes.

[youknowriad]

@jsnajdr I agree, I think the ideal would be to have postType, postId and context as props to the Editor component. The problem though is that we still need to keep the state in the edit-site store for backward compatibility. So we'll have to update the state (maybe as an effect in the Editor component or something).

[dannyreaktiv]

Hi, y'all, will it be possible to hook into the single post route to provide a custom React-based editing experience rather than the Block Editor? (And is this the right place for this question?)

[jsnajdr]

@dannyreaktiv That means that you want to completely disable Gutenberg and replace the post editor with your own custom app? In that case you don't want to hook into anything in the Gutenberg codebase, but do it directly at the WordPress level. The Classic Editor plugin could be an inspiration for this.

[dannyreaktiv]

@jsnajdr Thanks for replying.

If the post tables are being replaced with DataViews, it would be nice to hook into edit post action to launch a custom view (such as a modal) rather than redirect to the editor.