WordPress / gutenberg

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

Feedback: home template and pagination #38376

Open mtias opened 2 years ago

mtias commented 2 years ago

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 the home and page 2, since page 2 is still served using home and not archive. Twenty Twenty Two was designed with this big header, which is used for the theme screenshot.

image

While there are ways to make tweaks (filter the home_template in PHP, or use the paged CSS class if the theme uses body_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 of home, called home-paged or home-archive that theme builders could use if they wanted to.

Curious what thoughts people might have. cc @kjellr @jffng @carolinan @aristath @richtabor

kjellr commented 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.

jffng commented 2 years ago

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.

scruffian commented 2 years ago

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.

mtias commented 2 years ago

@jffng Users already have the option of setting a static page as well. But there's still a gap on the blog home.

jameskoster commented 2 years ago

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.

carlomanf commented 2 years ago

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.

carolinan commented 2 years ago

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.

kjellr commented 2 years ago

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.

jameskoster commented 2 years ago

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

carlomanf commented 2 years ago

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.

kjellr commented 2 years ago

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.

carlomanf commented 2 years ago

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.

carlomanf commented 2 years ago

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

luisherranz commented 2 years ago

Good point. This could be solved with the same mechanism.

cc: @SantosGuillamot