Way to control the panel sidebar pages

I just got an idea of how to control the panel sidebar pages.

In the blueprint this can be the default:

title: Home
sidebar: children

The sidebar lists children. This is how it works today, even if there is not a blueprint option for it.

For more control it could be set up like this:

title: Home
sidebar: custom

When set custom it will look for:

sidebars/my_template_name.php

Yes, it will introduce yet another folder called sidebars.

Return $pages from anonymous function

Inside there is an anonymous function that return a custom $pages object with the pages that should be presented, or an array if external urls chould be added.

It’s very important that the anonymous function has access to $page object and the template.

Have you thought of this feature already? I think this solution is really Kirby-ish and awesome, what do you think?

I like the idea to modify the list of pages in the sidebar. Several people asked me if this is possible by using my subpagelist plugin … of course it’s not. But it shows that there are people asking for this.

But I think the filter settings should be located at the subpages settings, because it modifies the list of subpages and not the whole sidebar.

Maybe the subpagelist filter settings are a way to go/start from.

PS: Sorry for referencing myself, but I think it’s worth mentioning here :stuck_out_tongue_winking_eye:

First of all, I like you plugin! Good reference, I think.

Maybe you have right about the subpages settings. But is’nt it limiting?

Would for example this be possible?

  • Exclude pages from the default children.
  • Include pages, maybe even external urls to other sites (if thinking outside the box).
  • A more advanced query like a list with flipped children from another parent, where two items are excluded, but only if a specific site setting is true and the language sv is enabled.

What I want to make sure is that this list is not limiting. If it’s limiting it would be more questions in the forum with the answer “You can’t do that in this version, maybe in the future”.

Using sidebar snippets like I described will make it free to do whatever needed. Is that possible with your suggested solution?

I like the idea of the flexibility, yet it would be harder to write a function every time you want to do some basic filtering instead of having a yaml key-value pair for this one. And, thinking about this just a couple of minutes, I would be really interested in a use case where this is handy for the panel – because we would somehow leave the easy structure (folders and textfiles, which is always represented in the panel the way it actually is on the server) and add an unknown complexity to it, if one makes use of this kind of functions. So I’m really interested in what you have in mind where to use this functionality :slight_smile:

I’ll add some cases here now and then I update this post as I come up with more use cases.

Hide a page by template:

I list the pages and their template filenames. Details and products is a placeholder, not an archive and the products are accessed directly from the root page, routed. They have no archive page.

In this case, don’t list anything that has the template placeholder.php.

Details - placeholder.php
Products - placeholder.php
About - default.php
Contact - default.php

After

About - default.php
Contact - default.php

Shortcuts to pages:

When using the “Hide page by template” above then it can be relevant to have the children inside the sidebar.

Below include the children of Details and the children of Products.

It’s like shortcuts if you will.

About - default.php
Contact - default.php

After

Detail1 - item.php
Detail2 - item.php
Product1 - item.php
Product2 - item.php
About - default.php
Contact - default.php

Conclusion

The use case in a summery that comes to my mind.

  • When routes change the page structure presentation.
  • When need to hide one or more pages.
  • When need to have shortcuts to pages.

Update

Removed external urls for the use cases as I did not come up with a good example of it. Tools and other stuff should not be linked as subpages.

Okay, I see. Yet I think there should be better options through re-arranging the whole sidebar, not only the subpages part. Especially the thing with the external links (out of the panel) like patterns and/or splitview would be great, but as you already mentioned, not as part of the subpages. So I would prefer a way of re-arranging the sidebar in total than to query certain subpages, but I see your use-cases now, thanks!

I think here you really start mixing content with other stuff, which IMO does not make sense and might be very confusing, indeed.

@jakobploens Do you have an idea to share for it? You want to keep it in the blueprint somehow?

@texnixe Yes, then we agree on that. I removed it completely from the post to not risk of confusing anyone. I really like it but not in the place of subpages.

In the blueprint would be great, but I think this would be to complex. No, I think more of a solution similar to dashboard widgets, as for the same reason you have for the query-thing: flexibility. If you’d then have different modules (Settings, Pages, Files at the moment), you could either overwrite the default modules, or just add/remove own modules. These could also be shared, just like widgets or panel fields!

And, to make the thing ultra flexible, you would have different types here: sidebars, which contain modules. And in the blueprint, you could then define the sidebar which should be used by sidebar: my-custom-sidebar, which finds site/sidebars/my-custom-sidebar/my-custom-sidebar.php, which just registers/adds modules from site/sidebars/modules. Maybe we could even find a way of combining widgets and sidebar-modules into one single “thing”, so that you could access piwik stats for example either in the sidebar or directly at the dashboard without having to code it twice.

Many things just came to mind when typing, but this would be another killer feature (I have said that often before, I know) – this would really make the panel customizable, in (almost) every way!

Sounds similar to my idea. Seems like the scope is different. I thought only about the subpages and you thought about the whole side.

With your version it could be easy and more relevant to add Splitview and Patterns as another group/module apart from the subpages.

1 Like