Allow to customize pagination parameter

[dmolineus]

Description

At the moment each module which supports pagination creates a unique url parameter. This is a good generic solution to avoid conflicts between modules. However customers want to create pretty looking urls like news/example-category/page/2.

It would be nice to have

• an option to override the default pagination parameter in the module settings
• a configuration to add the pagination parameter as part of the url. I wouldn't care if it's a global configuration / configuration per root page or also part of the module settings

Wdyt?

[Toflar]

The idea here is that we want to have a different page type concept. Everything in the core that wants to modify the URL path (not the query, the path!) should be a page type. E.g. the news reader should actually become a page type. That way, it knows what placeholders it can possibly take and it can even allow the users to place the placeholders wherever they want to in the path.

So what we need here is to replace the current $GLOBALS['TL_PTY'] by a proper registry (I don't think we should take the fragment one. A page type is the root and not a fragment) where you can tag your own controllers and provide some way to say that page type A supports e.g. category and news-alias (somehow we should re-use routing here, so that I can e.g. specify that category must match a regex or must not contain a / etc.). In the back end, a user should then be able to enter news/{category}/foobar/{news-alias} in the alias field.

That's something we were talking about at the dev meetings but there's no POC or anything yet. Just this rough concept. Do you like it? Care to work on it? That would be absolutely awesome because it's the last thing that's not a proper controller in Contao (except for insert tags for which there's a PR of mine). 😄

BTW: /page/2 to me is a very good example of something that does not belong to the URL path but to the query instead.

[dmolineus]

Thanks for hijacking my post to promote the idea of the page registry. :smiley:

E.g. the news reader should actually become a page type.

As far as I understand the page type would work like a regular page (keeping structure with content elements, articles and ces) but also determine the news model, enhances the current request attributes. Then additional modules like the news reader and or a news related module could get the news model from the request and render it?

That's something we were talking about at the dev meetings but there's no POC or anything yet. Just this rough concept. Do you like it? Care to work on it?

Yes, I'm willing to work on the implementation of the concept.

[Toflar]

As far as I understand the page type would work like a regular page (keeping structure with content elements, articles and ces) but also determine the news model, enhances the current request attributes. Then additional modules like the news reader and or a news related module could get the news model from the request and render it?

Not exactly. I mean, it's one of those things we have to figure out how it works best but this is how I imagine it: In my opinion, yes it should just work the same as every other page and yes you can place whatever content element/articles you want to on that page. However, I'm not sure if we still need a front end module for the readers because they should not have any settings anymore. All the settings should go to the page type and then all you need to do is tell the page layout where to display that "page type content". But then again, maybe you want to show data of a news in both, the main column and the right column just with different templates (e.g. the text of a news in the main column and meta data in the right). In that case, it would still be good to have the template configuration related to the column rather than the page itself. But it would also mean you end up having a lot of front end modules just for the template selection and these modules actually don't differ at all. Maybe we could extend the module wizard to include the page type template. Something like this:

Not sure at all but I don't want to add yet another 30 front end modules just for the template choice.

Yes, I'm willing to work on the implementation of the concept.

😍

[dmolineus]

In my opinion, yes it should just work the same as every other page and yes you can place whatever content element/articles you want to on that page. However, I'm not sure if we still need a front end module for the readers because they should not have any settings anymore. All the settings should go to the page type and then all you need to do is tell the page layout where to display that "page type content".

I thought about that solution before. Imho it would limit the flexibility too much, that's why I prefer the approach as I mentioned above. It would have following advantages for me:

• You are able to position the page content between any content elements
• You don't have to create dozens of page layout type
• You are able to place different modules which depends on the page content. Following the news reader example: You could have the reader itself, a news related module, a tag cloud module, the comments module which all depend on the news model.

Creating multiple modules like before is a price I would happily pay to get these advantages :)

[Toflar]

I see. My main concern really is that I would like to Contao to restrict developers to certain possiblities. If you just set the model on the page type you allow developers to build front end modules that do whatever fancy thing. Flexibility is good in a way but then I just care about the users. I would like to prevent the situation where e.g. for the news-bundle you have to configure the reader like so, the calendar-bundle does it completely different and bundle-x has no reader module at all because it does some fancy other thing etc. Contao's main advantage is that things are always the same.

But I agree that $request->pageModel (tl_page) and $request->domainModel (page content) is an interesting idea.

Is there any use case for having more than one "domain model" in the request? Like is there any use case for a list page type where you want to give the users the possibility to adjust the URL path? Not really, is there? I guess lists are never a problem, it's just really about our current readers 🤔

[ausi]

Is there any use case for having more than one "domain model" in the request? Like is there any use case for a list page type where you want to give the users the possibility to adjust the URL path? Not really, is there? I guess lists are never a problem, it's just really about our current readers 🤔

My first thought would be a list filtered by a category with a different URL for every category. But that would probably be just a “reader page” for the category with the category being the domain model?

But the reader page for such a list might need both domain models for the URL, like /news/{category.alias}/{news.alias}.html?

[dmolineus]

My first thought would be a list filtered by a category with a different URL for every category. But that would probably be just a “reader page” for the category with the category being the domain model?

It would work if only the category is set. But maybe I also want to filter with tags? When I would have two different models or a collection of news. /news/{category.alias}/{tag.alias}.html

Is there any use case for having more than one "domain model" in the request? Like is there any use case for a list page type where you want to give the users the possibility to adjust the URL path? Not really, is there? I guess lists are never a problem, it's just really about our current readers thinking

I'm not sure if we the page type should limit to only one domain model. What about a regular page? There is no domain model needed at all. I'd prefer that different page types could define which data they provide.

it completely different and bundle-x has no reader module at all because it does some fancy other thing etc.

If you want to avoid fancy solutions in third party bundles, Contao needs a solid base defining best practices, interfaces for the api where possible and has to be open to extend so that there is no need for any fancy solutions.

[Toflar]

I'd prefer that different page types could define which data they provide.

Agreed.

If you want to avoid fancy solutions in third party bundles, Contao needs a solid base defining best practices, interfaces for the api where possible and has to be open to extend so that there is no need for any fancy solutions.

I agree, which is why I don't like an arbitrary attribute on the request :)