Gutenberg: Edit Site: Loading a specific context on a dynamic template

[mtias]

Related to #19256.

There should be a way to load a specific context for a template (a "post" for single , a "category" for category, a series of posts for archive, etc) in preview mode. This could also be tied to the “browsing” mode as navigating by clicking would also effectively load a specific context (a page, post, category, etc) automatically.

In more sophisticated templates, like a complex magazine layout on the home, with multiple article queries, this should be both intuitive and flexible.

One consideration could be to always load some content by default (like latest post) and ensuring the display clearly indicates it's for preview purposes.

[dingo-d]

I have one question:

How will this be handled in the templates? Say I have a dynamic block that loads the latest custom post type posts.

How will this be possible with templates?

Because this content is dynamic, and it's changing, and when you save a block the content is saved in the DB, right? So you need a way to change these posts automatically when a new one is added. Is there going to be some handler that will enable this? Or some way to say to the editor render this block, but this block fetches the latest custom post type posts somehow.

The old way would be just writing a WP_Query and that's it. But the old ways are changing 😄

[shaunandrews]

One quick thought I had was how to set context specifically for a Page Content area/block defined in a template:

But it occurs to me that setting the context might need to be done on the document level — not on a block within the document. My mockup assumes the template's other parts (header, footer) aren't affected by the selected context. Maybe that's a true assumption, but I'm unsure and would love more input there.

[jasmussen]

But it occurs to me that setting the context might need to be done on the document level — not on a block within the document. My mockup assumes the template's other parts (header, footer) aren't affected by the selected context. Maybe that's a true assumption, but I'm unsure and would love more input there.

Great thought! But thank you for showing the idea regardless — your mockup helps explore one path and suggest others! 👏

And yes, it does seem like it's worth being able to set/change context in a more global sense. In this case you tackled the most difficult context — a homepage is just a Page, until it is set to be a Homepage _elsewhere in the interface_.

It would be simpler if you opened up an "Archives" page in the template editor (CC: @epiqueras), in this case we could perhaps presume that the context would be for that of an archive page, and blocks in the editor made aware of that?

[epiqueras]

It would be more intuitive if the page had an archive Query block somewhere. Just like archive PHP templates can choose where to render the archive loop, you should be able to move the archive loop in block templates while using other parts of the template for static content or fixed posts/pages.

[mtias]

I think the context of loading a post / page / category to the vanilla templates has to be broader in scope. I'd imagine it could sit in the header itself:

That would let you browse different posts / pages / categories / etc depending on what template you are editing.

[shaunandrews]

I tried a few different ideas for the Context menu; The first is trying to mimic the Template dropdown, using flyout submenus:

The, I tried adapting the Link UI:

One concern I have it how this would work on smaller screens. At some point, there won't be enough horizontal space for the Context menu. The first solution that came to mind was to add the second toolbar, like we do currently for block toolbars on mobile screens:

[mtias]

Reusing the URL Link interface would make sense for me, it'd just filter down to the things that can actually be shown for the given template (pages for page, posts for single, etc, following the theme cascade).

In terms of spacing, I think we'll eventually coalesce into something like this for Template / Content:

The regular editor (not the site editor) could also just keep the Content part which would allow us to relocate the permalink control from the title once and for all.

[mtias]

Of course, for that we need to handle the top-toolbar better.

[jasmussen]

As a strawman principle, the top toolbar could be permanently stacked on all breakpoints for this to happen. By "strawman" I mean this idea can serve as a baseline unless better ideas come around.

With regards to the mobile experience, I would recommend taking a look at how Google Docs mobile works. When you open a document, you see the title and sharing options, and an edit button. It's essentially in a "view only" state. When you click the edit button, the title/toolbar disappears and makes room for edit controls.

[ockham]

I find the top toolbar quite intuitive, but I wonder if it can indeed capture more complex cases such as described by @mtias:

In more sophisticated templates, like a complex magazine layout on the home, with multiple article queries, this should be both intuitive and flexible.

Using the top toolbar would probably come with the tradeoff of not allowing to create such layouts easily, wouldn't it?

I tend to agree with @epiqueras (https://github.com/WordPress/gutenberg/issues/19257#issuecomment-578754440) that a block-based approach (i.e. query blocks for archives, categories, etc) would mimic better what theme authors can currently do in PHP.

Since we might end up adding such query blocks for increased flexibility anyway, I think the top toolbar would become a bit arbitrary, connecting _one_ designated area of the page to that query (while still allowing other query blocks in order to build more complex layouts). That raises the question why we would want to emphasize one area (and query) at all. Do we think it would help people build a better mental model? (But again, wouldn't it come at the tradeoff that more complex layouts are less easily feasible/conceivable?)

If we want to limit a given template (e.g. limit a category template to only categories, a single template to only posts/pages etc), we could do so by contextually limiting the available choice of query blocks in the block picker.

[epiqueras]

Reusing the URL Link interface would make sense for me, it'd just filter down to the things that can actually be shown for the given template (pages for page, posts for single, etc, following the theme cascade).

In terms of spacing, I think we'll eventually coalesce into something like this for Template / Content:

image

The regular editor (not the site editor) could also just keep the Content part which would allow us to relocate the permalink control from the title once and for all.

I think this works great.

I find the top toolbar quite intuitive, but I wonder if it can indeed capture more complex cases...

The Query block will allow you to craft a WP_Query for its loop through its attributes. The renderer builds a WP_Query from the visited URL. So, while the Query block will be useful for complex layouts with multiple custom queries, we still need a sort of implicit Query block wrapping the whole template with its attributes dynamically computed from the URL the template is rendering on. The interface discussed here is for testing how your template renders under different URLs/queries.

[ockham]

Maybe it would make sense to start implementing content loading _without_ the UI (as long as that's not final)? We could use routes or query args to point to the context we want to load (also see #22238).

[epiqueras]

Yeah, that's a good idea.

[mtias]

It might make sense to pause this one for a little bit while the main navigation work gets established — there's a world in which loading a specific context is just navigating to that "edit page" route.

[epiqueras]

The infrastructure/block level work will be the same. We still need a way to load and render "that page".

[mtias]

I mean there's already a way to load "that page": post.php?post={ page_id OR template_id }&action=edit

[epiqueras]

Yeah, but we also need to support queries, not just specific posts.

[ockham]

@mtias We were hoping to prioritize work on this issue (without the UI) since we think it's one of the more crucial parts for an MVP that will allow users to edit at least their front page in a WYSIWYG-y way :smile:

[mtias]

@ockham I am confused :) I think what we need is to load the FSE version of the editor when you edit a wp_template part and that should handle things?

[epiqueras]

I think he's thinking about how we change the global block context within the site editor.

I mean there's already a way to load "that page": post.php?post={ page_id OR template_id }&action=edit

E.g., that should load postId and postType into the root context.

Similarly, queries should be loaded so that placeholder Query blocks can use the queries.

[ockham]

I think he's thinking about how we change the global block context within the site editor.

Yeah, exactly. (Sorry for not having been clear.)

I mean there's already a way to load "that page": post.php?post={ page_id OR template_id }&action=edit

E.g., that should load postId and postType into the root context.

Similarly, queries should be loaded so that placeholder Query blocks can use the queries.

:+1: