Edit Site: New page based navigation. #22368
Conversation
…ing a template for a URL.
epiqueras
added
[Type] Performance
|
Size Change: +655 B (0%) Total Size: 833 kB
ℹ️ View Unchanged
|
epiqueras
requested review from
ajitbohra,
jorgefilipecosta,
Soean and
talldan
as code owners
There was a problem hiding this comment.
Glad to see this coming together! 🚀
Here are some of observations from my recent testing:
The page dropdown button is not visible on initial load.
Although it does get populated with a page title after clicking on that area and selecting one of the pages. The position of dropdown shifts slightly while toggling pages, depending on the size of the title.
There are also some test failures that seem to be related to this PR.
This is because you don't have a static front page, and the PR didn't include the "All Posts" page yet. I just added it.
We need to combine the two dropdowns in another PR.
Fixtures, updated. I also added support for category pages now:
|
| @@ -56,6 +67,33 @@ export default function Header( { openEntitiesSavedStates } ) { | |||
| } ) ), | |||
| [] | |||
| ); | |||
| const setActivePage = useCallback( async ( newPage ) => { | |||
| try { | |||
| const { success, data } = await fetch( | |||
There was a problem hiding this comment.
Just stumbled upon this and it seems a bit hacky. What does this fetch do? Why not core-data? Why not apiFetch?
There was a problem hiding this comment.
Also, it seems to me that all the logic here is better on an async store action. (generator with controls) as otherwise there's a lot of potential for breakage as written (set state on unmounted components).
There was a problem hiding this comment.
I guess the issue is that "settings" is not yet on a store, for me, this is becoming more and more a priority as we add components and share state.
There was a problem hiding this comment.
It's not precisely an API endpoint. It's the only straightforward way of triggering Core's template resolution for a URL because calling parse_request in WP twice is not trivial.
Yes, I agree that at this point, it makes sense to move settings into a store and have this be an action.
There was a problem hiding this comment.
I'm also wondering if we're making things hard for us by trying to act like a full SPA here where we could instead trigger a reload and append something to the URL? (The dirty detection check could help us to avoid leaving the page with unsaved changes).
There was a problem hiding this comment.
We could add deep linking without refreshes too.
I do think that linking to a specific page in the site editor from different places would be nice.
There was a problem hiding this comment.
I'm also wondering if we're making things hard for us by trying to act like a full SPA here where we could instead trigger a reload and append something to the URL?
IMO, it would be nice to avoid hard refreshes. One of the biggest user complaints on WordPress.com is how long the block editor takes to load, which is a combination of loading an iframe and loading the block editor. Destroying the existing JS context and rebuilding it seems to be really inefficient (IMO) when the code can already handle switching pages client side! Since switching pages and templates seems to be a common task, it’d be nice to keep that interaction quick :)
Closes #19257
Description
This PR adds a new way of navigating in the site editor.
It adds a new page switcher dropdown that lets you select from your list of pages and category pages. The list can be expanded to include other pages in the future. The idea is to have one option for every unique URL path that the site exposes, except for post permalinks. A next step here would be to add a Post section that lets you load the single post page with a specific post context using a nested dropdown with the link UI.
Selecting a page switches the current template to the one resolved for that page and sets the correct root block context, so that post and query blocks work as expected. This flow is shown in the GIF below, where switching to the contact page makes the Post Title block render its title. Category pages also work like this, but the query blocks still need some work to read root context so that part is not testable just yet.
The next step would be to modify the template switcher so that it not only switches the current template but also provides a way to assign it to the current page.
This PR also:
auto-draftcreation so that they are only recreated when the underlying block template files have changed.indextemplate to the demo templates to facilitate testing.How has this been tested?
The flow that is shown in the GIF where switching pages in the site editor will update the current template and root block context was tested with a combination of different templates and pages to verify that the correct template is resolved for each page and that the root block context is set correctly.
Screenshots
Types of Changes
New Feature: The site editor now has a page switcher for navigating between pages instead of templates.
Checklist: