Pages index - A link to view sub pages rather than listing everything on the index page

[sgirard84]

For slighty bigger page collection (blog, photography portfolio, small shop), it would be nice if we could configure the front end to not display child pages on the index page, but having a link to see the collection.

Proof of concept

new parameter under Children in the page scheme like this

new route similar to index but with parent page

new controller function (or modify Index function but with optional route parameters)

Few minor tweaks on tree.php

We could have something like this at the end

index:

then sub pages

[giuscris]

Thank you for the proposal.
It makes sense and would be a nice addition.

I'm just not sure of the naming.
I'd rename the action from index to list and then add a list boolean property.
Then we can use the same action for both with an optional parameter.

I'll soon make a pull request.

[giuscris]

I like the image preview. What about moving it below the page route?
I'd use $file->square(300, 'contain') as we already use this size for file thumbnails (see panel/views/partials/files/file/item.php). Then we don't need to cache another image.
Would you like to contribute with this as pull request?

Speaking about the listing on separate pages, I'm working on it right now.

I've added breadcrumbs instead of the Pages title:

Then you can easily traverse:

I'm not sure of adding "View children" under the page route.
I'm going instead to uniform the "Actions" buttons by adding a dropdown (like we do on the files view) with a specific button to view children.
Then, I think it would be useful to have a page tree field, so you can display children in the page editor. This makes sense for blogs, galleries or other cases where the children pages act as a section or module of the page itself.

[giuscris]

Finally, I also tested pagination on this new "children view". It was also easy to implement.

But adding pagination means that the current Search doesn't work well, since the search is only local, from the loaded content.

For pagination are you concerned with performance issues?
I've always thought of avoiding pagination to begin with, as we can just display everything.

With pagination search would be more a filter than a global search, by now it was never a problem because we always listed everything.

[sgirard84]

These are all good changes.

And yep I can do a pull request later for the image preview and do it like the new Files admin page.

I'm wondering if this following idea would be easy:

Let's say you are on the blog entries page (children). Then you click on "Add new page". Would it be possible to default the new page modal with blog as parent, and post as page scheme. For clients (non technical user), it would make the workflow more easy.

[sgirard84]

Finally, I also tested pagination on this new "children view". It was also easy to implement.
But adding pagination means that the current Search doesn't work well, since the search is only local, from the loaded content.

For pagination are you concerned with performance issues? I've always thought of avoiding pagination to begin with, as we can just display everything.

With pagination search would be more a filter than a global search, by now it was never a problem because we always listed everything.

I was seeing pagination helpful for bigger website, like a blog with 300 entries. But this would be definitely a bigger change, and I don't know about performance between loading a page of 300 items vs 10 server calls of 30 items. It's more of a browser experience rather than performance I think.

For sure, this is not important for now :)

[giuscris]

Let's say you are on the blog entries page (children). Then you click on "Add new page". Would it be possible to default the new page modal with blog as parent, and post as page scheme. For clients (non technical user), it would make the workflow more easy.

Yes, I'm just working on it as I already encountered the issue. This will also improve the experience when we use the list as a field inside the page editor.
We just need to set the model instance to the modal field collection and then set the default with a dynamic field value (default@) in the newPage modal scheme.
Since we have either a page and a site model, I'm adding the possibility to use the variable model when you don't know which model you have in the dynamic field value.

[giuscris]

@sgirard84, I've drafted #763.
Still I'm not sure on the option naming. I think options.children.list is too generic, maybe it has to be something like options.panel.visibleOnSiteTree but more concise.
I've also improved the experience handling the Expand all / Collapse all buttons status (they are disabled when not applicabile) and added the dropdown.

[sgirard84]

Nice work!

For the naming, maybe something like options.children.splitTree ?

This option being optinal, if it's not there, it would be false.

And what do you think about having a quick action icon to see children, since it would accessed frequently?

[giuscris]

Thank you for sharing your ideas further. I've added some other commits to #763.
It makes sense to have an option false by default. I've thought options.children.subtree is a good compromise.
I've also added the quick action as you suggested.
I think I'll only need to update translations.

[giuscris]

@sgirard84 Released with Formwork 2.1.0!

[sgirard84]

Thank you!