Open mtias opened 2 years ago
As you noted, the original intent of Twenty Twenty-Two was to use that large header on the homepage, but it was a lot to scroll past on subsequent pages. We added the shorter homepage header as a compromise, but I do think the initial impact of the theme is dampened considerably by it. I'm interested to hear if other themes are running into this issue, and how they're dealing with it.
Falling back to archive for page 2 of the home feels too drastic given established conventions. A possible solution could be to introduce a new template file, child of home, called home-paged or home-archive that theme builders could use if they wanted to.
I'd be interested in trying this approach. My main concern is that the templating hierarchy is already pretty complicated, and this has the potential to make it worse. Theme authors can grasp this pretty easily, but I'm not sure users will get it.
cc @jameskoster since I know you and I have chatted about this topic in the past.
A new template file like home-paged
makes sense to me. I also hear @kjellr's concern that users might not get it.
Falling back to archive for page 2 of the home feels too drastic given established conventions.
Could we introduce a setting in the site editor that allowed users to select a different template for home page pagination? This is probably more complicated than it's worth.
Falling back to archive for page 2 of the home feels too drastic given established conventions. A possible solution could be to introduce a new template file, child of home, called home-paged or home-archive that theme builders could use if they wanted to.
IMO falling back to the archive feels fairly intuitive although I can see that it's a change to the existing convention. I prefer home-archive
to home-paged
.
@jffng Users already have the option of setting a static page as well. But there's still a gap on the blog home.
On balance I think a new template could work well, even if it does add more complexity to the template hierarchy đŸ™ˆ
We should acknowledge the precedent it sets though, and consider the consequences. Theoretically any archive template could make use of this affordance.
For example I can totally imagine a WooCommerce merchant wanting an elaborate look for a product category landing page, and a more streamlined appearance as visitors browse past the landing page. Or a simpler example: you might want to feature a large bio on the Author template, but reduce the prominence of that bio as you browse subsequent pages of the author archive.
Theoretically any archive template could make use of this affordance.
Not even just archive templates, but singular ones as well. There is a Page Break block that can be used to break up post/page content, although block themes still lack a way to provide a pagination button for this. (see #33357)
The template hierarchy previously did have a paged
template, but it was removed in version 4.7 due to low usage. I think the main problem with that template was it applied to the whole site, so it didn't allow for any flexibility between different queries.
If this template were to be re-introduced with greater flexibility, there'd be debate about how much flexibility. It seems very short-sighted to introduce home-paged
as soon as the default theme happens to need it, because it would open the floodgates to requests for category-uncategorized-paged
or year-2021-paged
etc. In theory, you could duplicate the entire template hierarchy short of a few non-paginable ones such as 404
.
An alternative suggestion is to add a block attribute to the template part block i.e. {"isPaged":true}
or {"isPaged":false}
that would conditionally display the template part based on whether the query is paged.
I am leaning more towards carlomanfs suggestion. What the HTML templates lack compared to PHP templates are the conditionals.
All block themes uses the body_class for the HTML templates (It's added for these templates automatically) But not all query paginations adds the paged or page-numer CSS class to the body, https://github.com/WordPress/gutenberg/issues/34898 and there may be more than one query, and more than one query pagination, which makes using the CSS class a difficult option.
An alternative suggestion is to add a block attribute to the template part block i.e. {"isPaged":true} or {"isPaged":false} that would conditionally display the template part based on whether the query is paged.
In general, this makes some sense — @jameskoster is right that in theory many templates might want to use this sort of thing, and this is flexible.
But I voiced concern above that users might not understand a home-paged
template solution, and I worry that this one would be even less discoverable to users.
Falling back to archive for page 2 of the home feels too drastic given established conventions.
If it helps: I expect that in the case of Twenty Twenty-Two, a home-paged
template would just be a duplicate of the archive.html
or index.html
template.
An alternative suggestion is to add a block attribute to the template part block i.e. {"isPaged":true} or {"isPaged":false} that would conditionally display the template part based on whether the query is paged.
Would this mean that to solve the case in the OP, your Home template would need to include two header template parts, one with {"isPaged":true} and one with {"isPaged":false}?
Or is it a case of allowing a single template part to entertain both conditions, then having a way in the Editor UI to switch between those states (something like https://github.com/WordPress/gutenberg/issues/36609)?
Overall I'm more drawn to the idea of each template part being a discrete entity, but I'm not sure that the template should be required to include both.
I wonder if we could do something like suggested in the OP, but restrict it to template parts? So if you visit home -> page 2, and the Home template included a header template part named "Home Header", the hierarchy would first look for home-header-paged
, and if that isn't found then fall back to home-header
as defined in the template. Kind of similar to how we used to do things like get_template_part( 'content', get_post_format() );
.
Perhaps that what you're suggesting and I am just bad at interpreting :D
Actually, I inferred that it was a case of wanting the header on page 1 but hiding it on subsequent pages, so only one template part would be needed. I'm not too familiar with the theme so I may have misread the intent. If it's a case of different content on each, then it could be done with two template parts.
Would this mean that to solve the case in the OP, your Home template would need to include two header template parts, one with {"isPaged":true} and one with {"isPaged":false}?
Good question. This technique would work nicely for hiding elements on subsequent pages, but it gets more complicated if you're adding elements (and breaks that front-end/editor appearance parity). Having a separate template might be a better, more flexible move.
Would this mean that to solve the case in the OP, your Home template would need to include two header template parts, one with {"isPaged":true} and one with {"isPaged":false}?
Good question. This technique would work nicely for hiding elements on subsequent pages, but it gets more complicated if you're adding elements (and breaks that front-end/editor appearance parity). Having a separate template might be a better, more flexible move.
The issue of breaking the appearance parity was touched on in the latest WP Tavern article at https://wptavern.com/fse-outreach-13-building-an-author-template-from-the-wordpress-site-editor
It was also odd to visually edit a feature that is conditionally displayed. There should be an indicator that its contents may or may not be shown on the front end. I am not aware of any precedent for such a block in core WordPress, but we should look at other projects and how they handle this.
Would this mean that to solve the case in the OP, your Home template would need to include two header template parts, one with {"isPaged":true} and one with {"isPaged":false}?
Good question. This technique would work nicely for hiding elements on subsequent pages, but it gets more complicated if you're adding elements (and breaks that front-end/editor appearance parity). Having a separate template might be a better, more flexible move.
Another related discussion about the appearance parity concern: #38108
Good point. This could be solved with the same mechanism.
cc: @SantosGuillamot
There's a limitation right now in the way the
home
template handles pagination. Themes that want to have more expressive homes for the blog portion of a site cannot easily discriminate between thehome
andpage 2
, since page 2 is still served usinghome
and notarchive
. Twenty Twenty Two was designed with this big header, which is used for the theme screenshot.While there are ways to make tweaks (filter the home_template in PHP, or use the
paged
CSS class if the theme usesbody_class
) they feel inadequate. At the same time, I think it's a bug that a user choosing this theme gets a fairly different "feel" from what the theme screenshot conveys.Falling back to
archive
for page 2 of the home feels too drastic given established conventions. A possible solution could be to introduce a new template file, child ofhome
, calledhome-paged
orhome-archive
that theme builders could use if they wanted to.Curious what thoughts people might have. cc @kjellr @jffng @carolinan @aristath @richtabor