How hidden pages work [13.03.2009]

In the latest Blueprint trunk, the behaviour of hidden pages has been subtly but significantly changed.

How they used to work

It used to be that if a page was hidden, then all of its descendents were hidden too. There was no way to view the default action (typically index) on these pages. They did not show up in site navigation.

You could still view any other action on a hidden page by explicitly specifying an action in the URL. This was useful for search pages primarily, where the search page was hidden, but you could still view results, tag results and tag clouds.

In general however, hidden pages were designed for ingredients -- you could specify the page slug of a hidden page in the ingredient call and get to one of its actions by that means.

How they work now

Pages now have a 'visibility' setting, which is one of:

  • inherited
  • visible
  • hidden

The default is 'inherited'. When a page has a visibility of 'inherited', it takes the visibility of its parent page. Top-level pages with 'inherited' visibility are regarded as 'visible'. So the default behaviour is unchanged -- if you set a page to be hidden, by default all of its children will be hidden too.

But now you can explicitly set a child (or grandchild, etc) of a hidden page to be 'visible'. All of its actions (including its default action) are accessible via its URL.

Because of the way the render_in_hierarchy template helper works, these children of hidden pages will not show up in the navigation elements that use this helper. But you can iterate over and link to visible children of hidden pages. And if you start the render_in_hierarchy helper with those children, it'll work just fine too.

This should be a much more intuitive method of working with hidden pages, and makes things like footers and selective navigation much easier.

But note that you will no longer be able to access any actions of a hidden page, even by putting them in the URL, unless the page is defined to permit that action. At present, only the Search blueprint allows this, and only on the results, tag and tag_cloud actions. I'm pretty sure no-one's using this removed feature for any other purpose, but sing out if you are.

Only the comment field is required. Omitting the ID fields increases your risk of being mistaken for spam.

Preview or