Should we get rid of every "pages" page being an index?

[epage]

Before #395, we gave every page in the "pages" collection a "collections.posts" so people could generate an index.

We now have an opt-in solution with #395, so it seems like an expensive "give it to everyone" option can/should be removed.

[epage]

If we make this breaking change

• We'd need to have a clearly documented way to get the same behavior in an alternative form
• Consider if/how we can help people migrate with tools
• Consider what a transition period might look like

[Geobert]

Great that you opened this ticket. Before sleeping, I had this conclusion as well: the pagination/indexation feature is quite separated from collections which force a migration.

So we either provide means to migrate, or find a way to integrate paginator and collections.

But they seems to be conflictual by nature.

[epage]

But they seems to be conflictual by nature.

Which parts are conflicting? Just that different names are provided?

• For "pages", we could enable the pagintor by default
• We could do something like "if the paginator is enabled, provide an alias in collections.
  • Maybe provide an opt-out for testing

This might conslidate the code paths for now and give people a transition route (disable the settings). We can then eventually flip the switch on the defaults. Later, we remove the collections alias.

[Geobert]

Not conflictual, I'm still a bit confused by collections as I don't use them ^^'

But still separated. If we create a collection, we cannot paginate it.

[epage]

I'm not referring to the custom Collections feature but that you could create an index page, without pagination, using collections.posts.

We can make collections.posts an alias for the paginated index as part of the transition

[Geobert]

I agree.

What other default collections to we have? collection.pages?

[epage]

We don't offer a collection.pages variable even though that is the only other collection.

[Geobert]

Ok, I'll do a PR to add the alias. Shall I add a warning of some kind?

[epage]

I considered a warning but I don't want to unconditionally warn and we can't detect the usage of collections.posts.

If we make compatibility configurable, we can warn on someone having it enabled.

[Geobert]

And if compatibility is configurable and disabled, we don't alias?

[epage]

Correct, we don't automatically enable the pagination and alias it.

[Geobert]

Do you think the aliasing flag should be global or per index only?

[epage]

I can go either way on that though if it is in the front matter, then it can be globally configured via the defaults.

[Geobert]

for the warning, I'm not sure on what to say. atm:

warn!("`collections.posts` is an alias to `paginator` object for compatibility. Consider migrating to `paginator`");

[epage]

So we are deprecating two things

• Implicit paginator
• The implicit paginator exposing data via collections.posts

Do you plan to put both of these behind the same flag?

As for an example of just collections.posts, I'd do something like

warn!("`collections.posts` is deprecated. Please transition to `paginator` and then disable support for `collections.posts` by setting <something> to <something>");

[epage]

Also, note that any deprecation warning should be hidden behind the feature flag.

[Geobert]

What do you call "Implicit paginator"?

The 2nd thing is the aliasing to paginator, isn't it?

[epage]

What do you call "Implicit paginator"?

Earlier, I said

Which parts are conflicting? Just that different names are provided?

• For "pages", we could enable the pagintor by default
• We could do something like "if the paginator is enabled, provide an alias in collections.
  • Maybe provide an opt-out for testing

This might conslidate the code paths for now and give people a transition route (disable the settings). We can then eventually flip the switch on the defaults. Later, we remove the collections alias.

To make collections.posts work as an alias without breaking people, we'd need to enable the paginator for people.

The 2nd thing is the aliasing to paginator, isn't it?

Yes

[Geobert]

I misunderstood then: what I've done so far is if pagination is activated, I'm… I've created the PR to show you what I've done so far ^^

[Geobert]

So for the moment, I'm relying on user activation for pagination to run and aliasing to be done.

What you're saying is that we should auto activate the paginator + alias?

[epage]

What you're saying is that we should auto activate the paginator + alias?

What we are trying to accomplish is transitioning to pagination without breaking people. This includes enabling it and setting up the alias.

[Geobert]

Ok, I understand better now, let me rephrase it to be sure:

We are going to enable the feature by default in the compilation + activate it by default (on include: All to index all the posts) + aliasing collections.posts to paginator in order to only keep paginator in a few versions.

[epage]

Yes

Though I realized a problem with this plan. We also enable collections.posts within posts ... I think. I believe the use case is showing other posts in a side bar

So we need to decide whether to

• Break support for this
• Implement a generic system for this

[Geobert]

For the moment, only pages create a paginator object (in generate_pages). generate_posts does not call generate_paginators.

But we do have a collections object containing a field context.posts.slug which contains a field pages

I don't even know what's inside.

[Geobert]

I've reached a point where generate_collections_var is only used by generate_posts.

So we can, in generate_collections_var, generate a paginator which is an alias to collections.posts so we can still do the transition?

[epage]

Hmm, trying to decide where we want to land with all of this. I have a theory that people haven't really used collections.posts much from within posts. So what if we made support for that go away when disabling support for collections?

[Geobert]

What kind of support? A warning? What if some are using it? :-/ (I don't, I only use next/previous)

[epage]

Hmm, but next/previous are related.

I see the value of Hugo having a known indexed/paginated page (_index.md) for the collection/section.

• Previous/next can be inserted based on how the index is configured
• Breadcrumbs / menu (e.g. support creating a sidebar that lists other posts from the current month plus a link to the month page)

Hmm, trying to decide where we want to land with all of this. I have a theory that people haven't really used collections.posts much from within posts. So what if we made support for that go away when disabling support for collections?

What kind of support? A warning?

If the legacy flag is not set to true, then no page, including posts, will have a collections

What if some are using it? :-/ (I don't, I only use next/previous)

I don't think we can get rid of collections / next / previous until we have something like Hugo's section template, so it'll be sticking around for a while.

[Geobert]

Uh? next/previous is in the page object, not collections.