Site Editor: Use path based routing instead of query args and site-editor.php routes #67199
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
Size Change: +3.2 kB (+0.18%) Total Size: 1.83 MB
ℹ️ View Unchanged
|
youknowriad
force-pushed
the
try/permalinks-in-site-editor
branch
from
d1052a3 to
b0c11e8
Compare
youknowriad
changed the title
youknowriad
force-pushed
the
try/permalinks-in-site-editor
branch
from
bc7da78 to
eca0126
Compare
|
The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message. To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook. |
youknowriad
added
[Type] Code Quality
youknowriad
force-pushed
the
try/permalinks-in-site-editor
branch
from
eca0126 to
f84d4ac
Compare
youknowriad
requested review from
oandregal,
jsnajdr,
tyxla and
jorgefilipecosta
jsnajdr
reviewed
Nov 25, 2024
| addQueryArgs( path, { | ||
| layout: newView.type, | ||
| } ) | ||
| ); |
There was a problem hiding this comment.
It would be nice to keep the getLocationWithParams pattern. The idea is that the click handler can read the current path at the time when it's called, non-reactively. The component doesn't need to be rerendered on every path change and the callback doesn't need to be recomputed.
There was a problem hiding this comment.
The problem is that we need to know the registered routes, it's not just about reading the arguments from the url, so IMO, it's better to remove it entirely.
There was a problem hiding this comment.
Then we can expose a method on the history = useHistory() object that does the job of useMatch. You can call it imperatively/synchronously at any time, and subscribe to updates. Then the actual useLocation will merely a React binding (with useSyncExternalStore) for this.
jsnajdr
reviewed
Nov 25, 2024
youknowriad
force-pushed
the
try/permalinks-in-site-editor
branch
from
3754c93 to
d03a835
Compare
tyxla
reviewed
Nov 25, 2024
tyxla
reviewed
Nov 25, 2024
packages/edit-site/src/components/block-editor/use-navigate-to-entity-record.js
Show resolved
Hide resolved
tyxla
reviewed
Nov 25, 2024
jsnajdr
reviewed
Nov 25, 2024
jsnajdr
reviewed
Nov 25, 2024
|
So now that most of the code details are addressed and the PR is ready. I would like to ask your global opinion on this PR. Is it going in the right direction? Are we ok we these small urls changes for the moment?... |
jsnajdr
reviewed
Nov 27, 2024
| p: `/${ postType }/${ record.id }`, | ||
| canvas: 'edit', | ||
| } | ||
| ); |
There was a problem hiding this comment.
One of the follow-up steps will be to somehow abstract away and remove this conditional navigation. When the rewrite rules are enabled, the target URL should be
document.location = `/wp-admin/design/${ postType }/${ record.id }?canvas=edit`;The history.navigate call
history.navigate( `/${ postType }/${ record.id }?canvas-edit` );is almost identical except the /wp-admin/design base path. If the "base paths" match, it's an SPA navigation, and a full navigation otherwise.
jsnajdr
reviewed
Nov 27, 2024
| } | ||
| return $default_handler; | ||
| } | ||
| add_filter( 'wp_die_handler', 'gutenberg_styles_wp_die_handler' ); |
There was a problem hiding this comment.
I think this fix deserves some detailed explanation in a comment. It looks completely magical to me, I don't know what it does, I don't even know what a "hybrid theme" is.
There was a problem hiding this comment.
haha, you're right. Basically, site-editor.php's access is forbidden for hybrid/classic themes and only allowed with some very special query args (some very special pages like template parts...). This is done in Core and the only way to disable it if we change urls in Gutenberg is to override the wp_die_handler. (We did this in the past when we introduced the patterns page in classic themes too).
I think in the backport PR of this PR, I'm going to try to remove that blocking condition entirely from Core cause I believe it doesn't really make much sense anymore.
But I'll add a comment.
There was a problem hiding this comment.
I see, so we're trying to undo the effect of this code?
What would explain it to me would be:
- mentioning/linking this code explicitly in a comment
- saying how exactly are we going to modify/delete this code when backporting this compat patch to Core
Such information will be also super useful for the person who will actually do the 6.8 backporting.
There was a problem hiding this comment.
Is the last comment good enough or you think I should modify it? I'm doing the backporting btw since now it's mandatory to open a PR before being able to merge this PR into Gutenberg :)
There was a problem hiding this comment.
Now when I know what's going on I'm personally satisfied 🙂 And it's written down in GitHub comments, a motivated researcher can track it down.
I love this PR 🙂 It's in principle very simple, and yet it brings us only one |
|
Thanks for the great work on this one, @youknowriad. It's exciting to see! I'd like to take a broader look, but I may be unable to take another look before tomorrow. Anyway, don't feel blocked by my review. |
Why can't it all be top-level? The REST API also has them top-level, so it seems fine? It would be cool to mirror the paths from that |
Yes, REST API is the first thing that comes to my mind, too. It has all the custom post type paths already solved. Every CPT has a
The UI frontend router should exactly mirror these paths. |
|
I don't think the frontend should mirror the REST API at all. The client's API rely on "postType" slug and not RestPath as an identifier. In the REST API, the REST path is unique across all entities but the "postType" might be shared with taxonomy slug for instance. You can have a post type with name "x" and a taxonomy with name "x" and there's no way to disambiguate between both. We can only do it if we use the REST path in the router and have an endpoint to fetch the actual post type or the actual entity based on the REST path. This is really not worth the complexity. I think we should have the following routes instead: |
This was referenced Nov 28, 2024
|
Spending some time testing this, and filing some PRs where I found something: |
Yes, you convinced me this makes sense 🙂
|
|
Another follow-up fix for template author filter nav here: #67382 |
|
I ran into some issues in |
|
Please let's call it something other than |
| * @return callable The default handler or a custom handler. | ||
| */ | ||
| function gutenberg_styles_wp_die_handler( $default_handler ) { | ||
| if ( ! wp_is_block_theme() && str_contains( $_SERVER['REQUEST_URI'], 'site-editor.php' ) && isset( $_GET['p'] ) ) { |
There was a problem hiding this comment.
Why do we need && isset( $_GET['p'] )? This means it's not possible to access the site editor root, which I need for #66851
There was a problem hiding this comment.
I'm not entirely sure that it's necessary tbh, it was just defensive coding because p is almost always defined now due to the redirects in place.
6 tasks
michalczaplinski
pushed a commit
that referenced
this pull request
Dec 5, 2024
…itor.php routes (#67199) Co-authored-by: youknowriad <[email protected]> Co-authored-by: jsnajdr <[email protected]> Co-authored-by: tyxla <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Related #60584
This PR makes our routing framework a bit more solid and getting us closer to opening the registration API publicly.
The main changes in the PR include:
matchfunction in route definition with apathoption. I initially considered using pretty permalinks in the browser url (examplewp-admin/design/stylesto access the styles page in the site editor) but because URL rewrites might not be supported in all WP instances, I left this part out of the PR.pathin routes definitions means we have to change the urls of the site editor a little bit. I'm using a specialpargument for the path in the query string (because I can't use url rewrites). I've included redirects for backwards compatibility of old urls.areasandwidthconfigs of the routes can now be functions that receive the current location (query and params) as arguments. This was done to avoid separating the routes for quick edit, list view... I think this makes our routes way more clear and prevents us from having "convenient" routes, instead we can think about "1 Path" = "1 route"Todo