How to confuse the hell out of the plone navtree and yourself in six easy steps

Posted on November 7, 2006 by Rick Hurst

Six simple steps to make the plone 2.5 navigation portlet get it’s knickers in a twist:-

create a folder in the root of a plone site
in folder contents in the root, move your folder to the top so that it is the first item (after “home” if you have that enabled) in the navigation tree
in the new folder create a new page and set that page as the default view
in the ZMI enable “Folder” as a type that can be used for a default page (see this is where I should have known something bad was going to happen)
go to the root of the site and set your new folder as the default view of the portal (i.e so that the homepage of the portal is in fact the default page in your new folder one level deep – believe it or not I had a reason to do this)
Hey presto your new folder falls to the bottom of the navtree – no amount of reordering will persuade it otherwise! You can try swearing too if you like, that won’t work either 😉

archived comments

Yep, I realise this is a bizarre use case – one which came from a client where I had migrated their site from another CMS, which had the home page of the site being the same page as the default page of an “about” section. They didn’t want to change this set-up. I won’t file it as a bug and I promise I won’t do it again 😉

In the end I solved my problem by not doing the “folder as default page” hack, but adding “about” as the first option for default_page under site_properties – a hack which works here as long as there are no other objects of the same name. I’ll publish the url of the site when it goes live so you can see my use case.

Rick 2006-11-08 08:42:42

I’m not even going to try to think about why you’d want to do this. File a bug if you wish. It’ll probably be assigned to me and I’ll probably ignore it on account of silly use case. 🙂

If you see this happening with other types than Folder (i.e. where there is a real use case) then it’s a more serious bug. I think RichDocument and other non-structural folder (marked with INonStructuralFolder) are the ones that would be bad if they don’t work.

If I were to guess, I’d say that:

– When the Folder is the default-page of the portal, it ought to be hidden
– However, you have showAllParents on
– The folder itself actually has a default page, or something else is causing the showAllParents logic to be invoked (this may be a bug)
– showAllParents will always place at the bottom (limi says we may move this to the top instead)

To be clear, showAllParents (a flag, which when true implies this behaviour – ) works on things that are ordinarily not in the tree (typically marked with “hide in navigation” or of a non-listed type). If the current item or one of its direct ancestors is not visible and showAllParents is true, it will still show those items. It may not know where to show them, though, in which case it’ll end up at the bottom. It depends. Navtree code is complex.

Martin

Martin Aspeli 2006-11-07 23:16:32

There’s a reason folders are not enabled as being default views of a folder, you know. If you change that, you’re on your own. 😉

Alexander Limi 2006-11-08 00:23:58