Maybe slightly off topic, but we have a use case where we want the
navigation root to be set for certain content types only, but want the
breadcrumbs and portal tabs to show the real site-root anyways. I
created IPortalTabsRoot and IBreadcrumbsRoot for that and modified the
templates/views accordingly (making both the breadcrumbs and portal tabs
use the implementing object's title instead of the hard-coded "Home" as
I have read of other people needing that use case as well and it
somewhat fits to your use case, so I'd be happy to contribute code if
this de-coupling of navgation/breadcrumbs/portaltabs is needed.
Martin Aspeli schrieb:
> Hi all,
> I'm about to write some code (to be open sourced if all goes well) that will
> support "microsites" inside a single Plone site.
> Largely, we have this already. A folder that is marked as an INavigationRoot
> will "root" most navigation and UI. However, there is still bleed where
> things like search results or catalog-driven portlets collect data from
> other sites.
> Rather than look for all the leaks and try to fix them, I was thinking to do
> this in the same way we do the allowedRolesAndUsers index in portal_catalog
> and have an implicit 'path' parameter that contrains the search results to
> the navigation root if no 'path' query is given to begin with.
> Basically, I would add something like this to
> if 'path' not in query:
> query[path] = get_navigation_root()
> Obviously, this is a bit heavy handed, but I can't think of any situations
> where it would really be a problem. If you make a folder a navigation root,
> then it doesn't make a lot of sense to have portlets or listings (e.g. a
> collection) point to content items outside the navigation root. For one
> thing, the navigation root is quite likely to be vhosted on a particular
> domain. For another, the UI just wouldn't make a lot of sense.
> I'm probably going to do this with a monkey patch for now, but if people
> think it's a good idea, I could PLIP it for 3.2.