Details View → Templates

[andrewserong]

This issue seeks to break out tasks from the item in the Phase 2: Customization overview (#33094), with the label "[Browse] Access to high level settings (posts per page on relevant blog templates; home page static page; and quick template switching)."

Blog Templates (index, home)

When the site has a static home page, we can allow the user to update the Posts Page title from the Home / Index template.

• Site editor sidebar: home template details #51223

Frontpage

Contains the homepage settings (static page or latest posts).

When set to display latest posts the user can specify how many posts to display.

When set to display a static page the user can select the page, and define the Posts Page.

Category

It would be nice to list categories in the panel, and link to detail views for each one:

But in the short term we may need to just have a link to manage categories at the bottom of the panel, similar to the one in the Pages panel:

---

Ellipsis menu (next to Edit button)

• Delete
• Duplicate
• Replace — if there are patterns or to start blank or to copy from another template

---

Existing screens for reference

/wp-admin/options-reading.php	Site editor template panel	Browse sidebar

[jordesign]

Love seeing this conversation being started...

I do like the idea of these showing contextually in the Browse view.
From a user POV I would expect that these are places I'd expect matching controls.

Posts Per Page

This makes sense to be shown when the Index of Home template is being shown or on Site Editor first load when the front page is set to show latest posts.

However, I can imagine this makes less sense if the user's Home/Index template has no Query Loop block at all - and they're not showing posts.

Home Static Page

If the user has a static page selected - it could be cool to have the specific page be able to be changed from first load in the site editor (when we're showing the 'home' page).

Static/Post front page switching

I can imagine this working quite well as an option that is available when the site editor first loads. The context of showing the Front Page is perfect for making a note like your site is currently showing a static page or your site is currently showing your Index template and an option to switch - which reveals the static/latest post option.

[annezazu]

@jameskoster would love to hear your perspective on this as I know you've done some work on this in the past: #43418

[jasmussen]

Wonderful opportunity to clarify some of the divergent thinking that has happened on this issue across many different issues. I'll take a stab at answering your questions in a moment, but want to preface with a note that this is still to a certain extent being figured out and subject to change.

The key aspect is that the site view (dark material background, preview on the right) is meant to be a receded project-wide view of your site, surfacing high level options, whereas the edit view (fullscreen editor) shows the nitty gritty low-level options. Notably tricky to figure out is where to draw the line between high level and low level, and this will likely take a couple of iterations to get right. This is also something both @SaxonF and @jameskoster have thought a lot about, so I'd love their input as well.

Where should high level settings live within the UI, for example:

• Posts per page
• Home page static page
• Quick template switching

I see all of these being primarily interacted with as properties of the pages that make out your site. That is, you drill into Site Editor > Navigation (or "Site Structure" as I've called it in these mockups), you drill into the detail page for each section, and page attributes are surfaced there.

For a page:

• Note the "Page Type". This would surface a dropdown or modal place to set as homepage, or posts page.

For a page set as homepage:

• Similarly, the page type selector would let you set as homepage or posts page, or unset.
• I'm not happy with the design here, it needs to better thread the needle between prominence and usability: it needs to be easy to find where to set the static homepage the first time, but not feel overwhelmingly prominent for every other page on the site, as it's likely to be a set it and forget it thing.

Page type might also be a choice during page creation:

• It's still tricky here to balance the prominence of an action you're likely to take once, set it and forget it, so again, this design is almost certainly likely to change.

Post settings would similarly be surfaced when you choose to edit the posts page:

Are these to be exposed within the Browse interface, or within the Template sidebar?
What is the list of settings to be exposed?

There may be overlap in cases, and this speaks to still figuring out the best heuristic for what we count as high level vs. what we count as low level. In general I would avoid surfacing every page attribute in the dark material sidebar (title, parent, order, template, allow comments, password, private, date, author) — the majority of those feel like nitty gritty. But an argument can be made that things like URL (slug) and visibility (draft, published, pending review, and maybe a new one: "hidden from menu") would be useful high level tools to edit in the receded view.

Do these settings need to be set at the Template level, or at the global/site level? (i.e., is this just exposing the existing controls within /wp-admin/options-reading.php within the site editor / browse mode — or, do we wish to add more granular control at the template level, where some settings or attributes are stored within the template itself?

It's still an open question whether we need an explicit "Site Settings" item in the site view. For what it's worth, I could see one such exist, to have a ergonomic and easily findable place to change site title, site logo, and tagline. This might also be a place to surface the reading settings in a single place, but I would make this be in addition to those options being available as metadata in the drilldown detail pages.

---

On a separate note, I've come to appreciate the terms "Site View" and "Edit View", which I think @richtabor coined. They are a good way to differentiate the high level receced view, and the fullscreen editor view:

They are also less confusing than "Browse mode". Originally we did indeed intend to absorb the browse mode feature in the site view, letting you actually click links in the preview on the right to navigate to all the various aspects of your site. But this is indefinitely shelved, and actual browse mode is likely to land as a ⌘ Click feature, a la i #49582.

[jameskoster]

This comment is a bit outdated since the issue was updated.

Original comment

For what it's worth, I could see one such exist, to have a ergonomic and easily findable place to change site title, site logo, and tagline.

In terms of site settings I think this would be a good start (I'd include Site Icon as well). Essentially mapping the 'Site Identity' panel from the Customizer.

We'll likely encounter some 🐉s with the home page settings due to the interaction with templates etc, so that probably needs a dedicated holistic exploration.

---

Generally speaking I think it would be good to look at designs for all the panel types independently. Off the top of my head, we could break this down into the following:

• Site Identity
• Individual Page
• Special pages (e.g. static home page, posts page, privacy policy).
• Individual Post
• Post Category
• Post Tag
• Archive-type template (to include "posts per page" setting)
• Singular template
• Template Part
  • Header
  • Footer
• More?

If 'create' flows invoke panels then we need to consider those as well.

[jameskoster]

It might be worth considering the Front Page template too. It would include similar settings to the Blog Templates (index, home).

[jameskoster]

Here are some designs for this one:

Front Page

• Icon next to template name communicates that it serves as the site homepage.
• Ellipsis menu details & revisions described in Meta actions on details view #50379 (comment).
• Homepage display setting allows the user to specify whether the template displays latest posts or a static home page.
• Posts per page setting can be edited via modal, when the homepage is set to display latest posts.
• Header / Footer detail is read only. In the future can serve as a shortcut to view their details.

Home template

• Icon next to template name reflects whether it serves as the site homepage or the posts page
• Ellipsis menu details & revisions described in Meta actions on details view #50379 (comment)
• Posts per page setting can be edited via modal.
• Blog title can be edited when the template is used as the posts page.
• Homepage display setting allows the user to specify whether the homepage displays latest posts or a static home page.
• Header / Footer detail is read only. In the future can serve as a shortcut to view their details.

The Index template can potentially have the same contents.

Category

• Ellipsis menu details & revisions described in Meta actions on details view #50379 (comment)
• Similar to Pages panel (Re-Introduce Content Editing in the Site Editor #44461), Manage link goes to wp-admin.
• Header / Footer detail is read only. In the future can serve as a shortcut to view their details.
• Category items can be read only to begin with, and in the future expose details for those categories where you can do things like create a new template.

[jasmussen]

Nice work. I do like in the page details that the whole row is one clickable element that opens the modal, and I appreciate the clear mockup denoting that.

The omission of the site hub confused me for a moment, but I'm assuming that's unintentional.

The "Manage categories" link sits in a bit of an awkward place for me. I think that's one of the things that could conceptually fit in the save hub. I know there was a longer conversation about what goes there, but it still feels like a "Manage" link that should sit at the end, like revisions, or "Manage all templates". What do you think?

[jameskoster]

We could place the manage link above the save/revisions area. But that would be inconsistent with the latest designs for other panels (pages, templates, template parts) where it is positioned in the header.

Another option could be to keep the placement but use an icon button. That would reduce the footprint, but choosing an icon is tricky.

[jasmussen]

Mainly my concern is that including it in the title makes it really tricky for translations, and will wrap very quickly. I'd put it in the list somewhere, since there's room to scroll.

[jameskoster]

I don't mind moving it to the list, if we acknowledge it'll be different to the Pages panel.

[jasmussen]

I'm not sure there should be a manage link in the pages title either, or any titles, to be honest. But perhaps I'm missing some crucial nuance?

[jasmussen]

Grid looks great, colors look great. Two things:

• We should not move the toggles to the right, we intentionally added them left originally and we might as well keep the same component as we use in the post editor.
• I left it as an open question on the other thread around the site hub separator and spacing.

Here's a quick mock of what I mean, but one which isn't polished at all:

[jameskoster]

we intentionally added them left originally and we might as well keep the same component as we use in the post editor

It looks a bit strange in this context to me, but I can live with it.

[jasmussen]

As we just discussed in a chat, we can use checkboxes there. The toggle implies immediate saving, which isn't the case here.

[jameskoster]

Yup, checkboxes can work:

I'd appreciate a once-over in terms of which discussion settings to include here. There are a lot, and the above was just a first pass:

[jasmussen]

This looks good to me. Spacing looks good, colors look good, checkboxes can work. I think this issue is good to update. Nice work Jay!

[SaxonF]

I'd appreciate a once-over in terms of which discussion settings to include here

I think as a first pass I actually wouldn't include any of them. The main reason is I think we need to think a little more about where post type settings should exist. I'm not 100% sure they should exist in the template as that idea starts to break down a little bit when considering other post types like products, events, projects etc. Another option is to link off to these settings within the most relevant post type sections. e.g. in future if we have a blog/posts section.

[SaxonF]

With the first version of page detail branch merged we are now free to build out template and template part detail panels.

I've created a PR that prepares us for these changes by giving templates and template parts their own screens.

[SaxonF]

Started the template detail branch here if someone wants to run with it

[ramonjd]

Started the template detail branch #51150 if someone wants to run with it

Thanks @SaxonF I can take a look.

From the designs it looks like there'll be template-specific requirements. I'll try to get something generic up first and then folks can pick up individual template PRs

[ramonjd]

Hi all!

I have a few questions about how the designs might work in practice.

Header / Footer detail is read only. In the future can serve as a shortcut to view their details.

Could someone help me understand the Areas list? Is it meant to show just the theme's Header and Footer (if they exist)?

Does it have any relationship to the individual template? E.g., what if a template doesn't have a footer?

Posts per page setting can be edited via modal.

Is this still the case? Reading it from this comment.

The designs in a subsequent comment appear to imply inline controls?

Thank you!

[jameskoster]

I'm not 100% sure they should exist in the template as that idea starts to break down a little bit when considering other post types like products, events, projects etc

That's a great point. This placement suggests the settings are blog-specific rather than global. I certainly wouldn't object to omitting these settings for now.

Could someone help me understand the Areas list? Is it meant to show just the theme's Header and Footer (if they exist)?

It lists any template parts within the template that are assigned as header or footer. If there are none (unlikely) we can hide that whole section.

Is this still the case? Reading it from this #49597 (comment).

Hopefully we can put the input(s) in the panel (#49597 (comment)) rather than relying on the modal. I suspect this will come down to how well the text input component works on the dark background. Let's start there and see how we go.

[jameskoster]

I've updated the OP now that a PR has been opened. We can continue to tweak details in the relevant PRs.

[ramonjd]

This huge PR adds a single property — modified — to the template/templates parts API response so the UI can display "Last updated" 😄

• Templates API: return post modified datetime in response #51362

[mtias]

I consider this finished. We can open up follow ups for specific templates as we identify improvements and gaps.