Full Site Editing: Update default templates #26941
Conversation
|
Size Change: -793 B (0%) Total Size: 1.2 MB
ℹ️ View Unchanged
|
jameskoster
added
the
[Type] Discussion
|
Another consideration – if we decide to enable the addition of a The pros/cons of the latter are the same as the former – clarity around template purpose vs the trade-off of falling back to TLDR: Should
become
|
|
In general I do think your suggestions here make sense. I like the simplified options — they'll make a lot more sense to most users.
I do have a little hesitation around removing a "Homepage" from these options — mostly because it's incredibly common for users to want a standalone homepage template. They'll still be able to create one with your updates here, but it's much less obvious. Also, (I haven't been following along super-closely, so forgive me if this is covered elsewhere, but) will there be a sort of "advanced" option available for folks who do want to create the more obscure template types? |
|
I like the simplified list. I'm waffling around removing the home page template also. I like the idea of having it in the default list of templates if we could guarantee it would be used for the home page, but as you say it requires the site reading settings to be configured accordingly. |
|
I agree with @kjellr here. And if we went with removing the homepage from thelist, maybe a link or a hint to where the advanced templates will live would be interesting to have |
I would love to unpack this a bit. A unique home page I understand, but I'd be curious to hear more about the sort of things folks generally add to their home page templates though, and establish if it is actually a template we need. My suspicion is that the affordances provided by the block editor itself (when editing content) will be adequate for the vast majority of use cases, and
Absolutely, but this is still TBD. Perhaps having the |
|
I agree that having a home page template seem redundant; because there is now so much power in the block editor user's shouldn't need a separate template for the home page most of the time. |
Yeah, I see that. I'm probably not reacting to the proposal here so much as I am to the idea of how wonderful it is to see something clear called a "Homepage" listed in the full-site editor. WordPress has historically been fairly obtuse about how you create and edit a homepage so the idea that clicking "Homepage" would result in a pre-configured, ready-to-edit homepage seems great. But that's not exactly what's being proposed here. |
Here's an idea: we might offer a single "Homepage" option in the add template menu, but create different templates based on the situation at hand. If the site has a static front page we create either If the site is displaying "latest posts" on the homepage we create the The problem with this is that if the user ever changes the homepage display setting, their homepage template no longer behaves as expected. |
Yeah, that gets to the root of the problem. Would we mark it as "Home (Unused)" or something? And display a notice when they edit it? I do worry this is just a bandaid over the whole weird homepage setup. 😄 |
Exactly. It's similar in many ways to the I've been round this circle many times and always come back to the idea of placing them slightly out of reach, and putting the more intuitive templates at peoples fingertips. |
|
|
|
D'oh, you're absolutely right @carlomanf. This simplifies the template somewhat, probably to the point that it is safe to include it in this menu.
The other templates highlighted in the OP are still worth discussing, as is the language in the descriptions. |
Yes, go right ahead with that, I was just referring to all the angst about front-page. :D |
jameskoster
requested review from
spacedmonkey and
TimothyBJacobs
as code owners
Copons
requested review from
Copons,
vindl,
Addison-Stavlo,
david-szabo97 and
jeyip
|
No objections code-wise! ✨ I have a couple of questions regarding the whole flow, though:
|
|
I don't have much objection to changing what we choose to show in the 'add template' dropdown, but would definitely change how we are doing so.
💯 - I don't see any reason to remove definitions from the dictionary when we can choose to only show a subset of them for any place they end up being used on the front-end. Instead of removing items here, we should just add a filter on the js side that limits what is shown in the 'add templates' dropdown. That way when we want to update this to add/remove other items in the future it will be super easy and we won't have to touch the underlying definitions. Keeping this list full enables developers to use it in many different ways, as well as allow us to more easily create something like @kjellr mentioned:
|
|
@Copons @Addison-Stavlo Thanks for the clarification. I agree with you both. Should this be done in a separate issue / PR? The filtering part for the add template menu is beyond me :D |
Yes, let's do that separately! The next steps could be:
|
|
New issue for the new-template-menu opened here: #27227 I'll update the copy here :) |
This reverts commit 4551f8b.
|
Copy updated. If you can re-review I'd appreciate that @Copons :) I removed the "Default" prefixes as they lose clarity as you add more templates. I think this specificity is better communicated the other way around. IE
Seems more intuitive than
|
There was a problem hiding this comment.
LGTM!
I don't have any strong opinions on the copy for this.
I'm not sure "resolves" is the most user-friendly word (it sounds technical to me), but I don't have any great alternatives ("applied"?).
It's not a blocker though!
@jameskoster I've also took the liberty of updating the PR to fix some tabs turned into spaces.
|
Thank you, sir! Yeah the wording is hard. For now I have pushed an update that uses the same language as https://codex.wordpress.org/Theme_Development#Template_Files. It's still not perfect, but we can refine it over time. Need to make that popover a bit wider to accomodate the slightly longer descriptions how :D |
Added that to this PR. If it's not appropriate I can revert. Let me know @Copons :) |
Also minor formatting fixes
|
@jameskoster looking good! |
Let's talk about the "default" templates list. Amongst other things, this list of templates will appear as options for users to add in the template navigation panel, in scenarios where they do not already exist. Here's how that looks:
Note: Singular would be included as well, except for my theme already including that particular template.
Below are my thoughts on these templates:
Front page –
front-pageHome page –
homeBoth the front-page and home templates are decidedly advanced as they are mutually exclusive, and rely on interaction with the given sites reading settings.Considering the flexibility site owners now have in the block editor, I think we should encourage them to assemble their homepages as regular pages, and use a$customtemplate if they need unique properties for the homepage specifically. This would essentially make the process for creating a home page template the same as creating a unique template for any other page on site.The Home template is more advanced as it relies on interaction with the given sites reading settings.
Verdict:
Remove bothRemove the Home template.Singular –
singularSingle post –
singleI would deem both of these templates as advanced too due to their ambiguity, how they interact with each other, and with custom post types. Succinctly describing the situations in which either of these templates will resolve – particularly when both a present – is difficult to say the least.
Verdict: Remove both, but add a "Post" option which will add a
single-posttemplate.Single page –
pageArchive –
archiveSearch results –
search404 (not found) –
404I think these are all fine, though I would like to explore updating some of their names / descriptions slightly.
Here's what an updated list might look like, as per this PR:
One drawback with this approach is that the Index template will always resolve to display single entries from CPTs. The lack of support for
$customtemplates is also quite limiting. Still, I personally believe these trade-offs are worth it for now and lay a more robust foundation from which to add these features in the future.