Yeah, thatās easy and in line with other settings that accept an array (e.g. cache.ignore).
Iām a total newbie to Kirby, and I find this suggestion easy to understand - much easier than the misleading current state of āinvisibleā pagesā¦ Certainly a +1 from me!
As a quick fix for the visible/invisible confusion, you could change the language file. Perhaps āhiddenā and "visible? That likely wouldnāt cause as much confusion.
'subpages.index.visible' => 'Visible pages',
'subpages.index.visible.help' => 'Drag hidden pages here to sort them/make them visible.',
'subpages.index.invisible' => 'Hidden pages',
'subpages.index.invisible.help' => 'Drag visible pages here to unsort them/make them hidden.',
I totally understand that thereās a lot of place for misunderstandings around the visible/invisible pages solution in Kirby. I actually ran into this quite a couple times myself when I had to name things in the panel.
Itās difficult. Thereās this great sentence by Cabel Sasser who said: āEvery added option is a tiny new failureā 
There are a couple of ways to handle this.
- make it the new default to lock down all hidden pages and switch the entire wording in the panel to published vs. draft
- make an option that does that
- create a plugin that does that.
Having a way to control exceptions or even having auto-exceptions like āhomeā and āerrorā does sound great at first, but Iām not sure if it wouldnāt get confusing again. Maybe then the entire idea of using this distinction between public and private should no longer be used for stuff like menus.
If we add it as an option itās quite a drastic step for Kirby. It means it follow us everywhere we go througout the code. Right now Iām in favor of a plugin and maybe instead open more fine-grained control over certain panel features that would be affected. But Iām super happy to chat more about this. I think itās actually a pretty important decision and getting your feedback and especially feedback from āKirby beginnersā does help a lot.
I want Kirby to evolve and grow and Iām always open for even radical changes if they make Kirby better 
One more thingā¦
Iām so so proud and thankful for how much the community has grown with the new forum and how amazingly helpful and friendly it is. It has such a huge positive effect for Kirby and it makes me so happy.
@anon77445132 I already said that privately a couple weeks ago and I say it here again. Iām not sure if itās sometimes a language-barrier-thing, but your tone of voice often sounds pretty rude and quite obviously people in here get offended by it. I know that you are actively supporting Kirby and I appreciate that a lot, but I can only ask you for your own sake to be nicer with your replies.
Thereās one thing I learned over the last years that has become very important to me and that is to always be open and positive about new ideas and feedback. Thatās the only way to move forward. We have too much dogamtism in the web industry while we work on the most dynamic medium ever.
I just wish that this community will never be haunted by dogmas and stupid fights and that weāll keep it all friendly, inspiring and moving.
Cheers,
Bastian
3 Likes
Yeah, I hadnāt thought about the obvious exceptions like āhomeā and āerrorā. Introducing auto-exceptions would also bring some auto-misunderstanding, because we always miss some bits when we read a doc 
It also would make some things more complex to understand: does this option change what $pages return? That would seem logical, but would not only change how pages display, that would change how some things work under the hood.
In another discussion I said I donāt think invisible pages with a browsable URL are a big deal āunless you have a good reason to hide them of course. As long as you donāt link to them, they wonāt be discovered by search engines and nobody should land there. Itās good enough in most cases.
It is also quite easy to hide the invisible pages of a content type when really needed, by adding something like what @anon77445132 suggested in the template (other than the default one):
<?php if($page->isInvisible()) go('error') ?>
So I guess I changed my mind, I now think this option is not necessary. That said it could be clearer that invisible doesnāt mean private or unreachable on the front end. Itās merely a flag. The above snippet (or any better simple solution) could even be added to the Docs.
At the moment āinvisibleā pages are more like āhiddenā or āunlistedā, but these are no better words. It really depends what you do with your contents.
Not sure we can find words that work in every context: Published/Draft doesnāt work when we use pages as part of others, like for a one-pager. Those pages would then be flagged āDraftā but their content visible.
Sorry to all!
Yes my posts are normally very short (as short as possible) to show the main idea.
May be, this depends on the language. My native language is German and I have to translate everything here to English.
I ask everyone to excuse if my tone of voice sounds pretty rude! Thatās not my intention.
@Malvese:
Thank you very much for your post. I agree to it.
Please take this suggestion:
<?php if ((!$page->isVisible()) && ($page->uri() <> 'home') && ($page->uri() <> 'error') && ($page->uri() <> 'login')) go('error') ?>
It is a further development of my original idea that will work in many more environments.
Thanks, @bastianallgeier for your post and clarifying things up.
As regards renaming the invisible/visible word pair, I donāt think that would make a big difference and probably has a bigger impact than on first glance. The important point here is to understand what that concept means and maybe the docs are the place for that, i.e. adding a little extra section.
On second thought you are probably right with the bigger implications of such an option. After all, everything depends on how you organize your content and how you use visible and invisible pages in your project setup.
Like I said above, I often use invisible pages for stuff that doesnāt belong in the main menu. Of course, if there is only a limited number of such exceptions, I could include them in a configuration setting. On the other hand, I have to manually add pages to that array of exceptions as soon as I add another invisible page I want to be directly accessible.
On the other hand, we create one-pagers with visible pages that we donāt want to be directly accessible. So we have to add routes to the error page in case of direct access again.
<?php if($page->isInvisible()) go('error') ?>
This setting would produce an error if the error page is invisible, as it is by default, though.
Ah yes, my bad. I should have added that it works only if in a template other than the default one. As long as it not the template used by the error page, itās ok.
Alternatively, it could be done in the default template with an additional tests against the templateās name.
Just to add some more complexity to this discussion: I think this would be great as an additional state for the pages as it would allow real drafts.
In my projects I now actively use visible and invisible pages, mostly to hide stuff from menus, featured sections, etc. From time to time I would like to prevent anybody from seeing the content outside of the panel, though. Here, this could be a great addition.
P.S: Now that I think about it, the number of templates I created that contain nothing but <?php go('error') is relatively highā¦ So maybe it would be useful after all.
Edit 2: I really canāt make my mind up about that. I feel like forwarding in the template is cleaner than relying on an array in the configuration. It could create quite some confusion if you co-work on a project or hand over maintaining a site. At least I would look at the template firstā¦
This was my gut reaction to reading this thread too. The difficulty is that any wording presupposes a particular use for the visible / invisible flag. At heart, itās just a way of marking a binary state for the files you make, which is a really useful feature! In a blog context, itās understandable that this is used for the draft vs published distinction. However, for different sites in different contexts, that phrasing could be misleading (maybe visible pages are subpages while invisible ones hold components of the parent page).
I donāt have a problem with it being an optional config setting, but I think a plugin would be the better option. If it were possible to do more to customise the panel then the panelās labels could also be tweaked where needed to match usersā expectations (calling it draft / published on sites where that applies, for example).
Thatās it. You can use visible/invisible state for what ever you like.
I think it would be great if you simply could add (globally?) more fields to that (left) section via the blueprints. In this everybody could add (and name) options just the way he/she wants while keeping the right side clean.
Ha, yes as a way to separate content/data from state/behavior/metadata. Interesting but seems limited to toggles.
Not sure we should mess with that left sidebar though. We could group such fields under a headline field.
Speaking of headline, I would love if it created a wrapper around fields, instead of being just a headline. Or maybe that would be an additional group field? With a wrapper we could easily tweak the layout to, say, have two columns. Or group fields as tabs or collaspible panes without having to rely on fragile DOM trickery.
3 Likes
@Malvese Youāre right. Grouping fields would be better than messing up the left sidebar. Great idea.
Exactly the discussion, I was hoping to get. Thanks everyone! 