WordPress / gutenberg

The Block Editor project for WordPress and beyond. Plugin is available from the official repository.
https://wordpress.org/gutenberg/
Other
10.39k stars 4.15k forks source link

Details View → Templates #49597

Closed andrewserong closed 1 year ago

andrewserong commented 1 year ago

This issue seeks to break out tasks from the item in the Phase 2: Customization overview (https://github.com/WordPress/gutenberg/issues/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)

Home template

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

Frontpage

Front Page

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:

Category template long term

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:

Category template short term

Ellipsis menu (next to Edit button)


Existing screens for reference

/wp-admin/options-reading.php Site editor template panel Browse sidebar
image image image
jordesign commented 1 year ago

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 commented 1 year ago

@jameskoster would love to hear your perspective on this as I know you've done some work on this in the past: https://github.com/WordPress/gutenberg/issues/43418

jasmussen commented 1 year ago

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:

Site Structure, Page

For a page set as homepage:

Site Structure, Homepage

Page type might also be a choice during page creation:

Adding pages flow, set as homepage

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

Edit single template

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:

Legend

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 commented 1 year ago

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 commented 1 year ago

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

jameskoster commented 1 year ago

Here are some designs for this one:

Front Page

Front Page template displaying latest posts Front Page template displaying static page

Home template

Home template as homepage Home template as posts page

The Index template can potentially have the same contents.

Category

Category template
jasmussen commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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

Screenshot 2023-05-18 at 13 13 28
jasmussen commented 1 year ago

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?

jameskoster commented 1 year ago

We have manage actions for other list panels (templates, parts, likely patterns & menus in the future) which take you to the table view via toggle:

toggle

This design is a response to suggestions about avoiding the drilldown we have on trunk for this. And feedback has been that the header placement feels better than the footer. I do think the icons need some more thought though.

I don't think Pages should be any different in that sense? The nuance is that we don't have a table view for pages in the site editor yet, so linking to the wp-admin table is the next best thing. Alternatively we just don't like to wp-admin at all and have no manage link for things like Pages.

jasmussen commented 1 year ago

The toggle seems to fare better than the label button.

I'm still not too sure about the label button, for the translation notes I mentioned also on #44461. However I don't think that needs to necessarily be blocking us from moving forward. So if it isn't too weighty to try the outlined approach, knowing that we might want to move that button elsewhere (dev correct me if this is a big lift), I think we can go with this for now. 👍 👍

jameskoster commented 1 year ago

Here are some updated designs for this one. One holistic change was to left-align values in settings. This based on a 6 columns grid layout with 16px gutters and 32px margins:

Screenshot 2023-05-23 at 16 02 17

Templates list

Templates

Front Page template

Front Page

Home Template

Home template

Category template

Category template
jasmussen commented 1 year ago

Grid looks great, colors look great. Two things:

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

quick mock
jameskoster commented 1 year ago

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

Screenshot 2023-05-25 at 11 07 46

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

jasmussen commented 1 year ago

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

jameskoster commented 1 year ago

Yup, checkboxes can work:

Home template

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:

Screenshot 2023-05-25 at 14 59 36
jasmussen commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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

ramonjd commented 1 year ago

Started the template detail branch https://github.com/WordPress/gutenberg/pull/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 commented 1 year ago

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 commented 1 year ago

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 https://github.com/WordPress/gutenberg/issues/49597#issuecomment-1551505336.

Hopefully we can put the input(s) in the panel (https://github.com/WordPress/gutenberg/issues/49597#issuecomment-1562969365) 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 commented 1 year ago

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

ramonjd commented 1 year ago

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

mtias commented 1 year ago

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