Setting to route all invisible pages to error page

:+1: 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.',

Panel English Language

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” :slight_smile:
There are a couple of ways to handle this.

  1. make it the new default to lock down all hidden pages and switch the entire wording in the panel to published vs. draft
  2. make an option that does that
  3. 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 :smile:

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 :confused:
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.

@Malvese:

<?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! :blush: