Time to rethink menus?

[Martin Koistinen]

Hi all,

There's been a lot of movement around the CMS menu system lately and I'd like to point out that IMHO, all of the latest developments around menus have been hacks. I don't in anyway mean to discredit the work done on these by using the work "hacks", some of the work is amazing! However, I say "hacks" because they are all trying to work around shortcomings in the core menu system, which I think stems from the 1:1 association between pages and menu nodes.

I think it may be time to consider a different approach, one that allows the page tree to continue to represent a url path structure for pages and their associated breadcrumb paths but allows operators to create and manage any number of menus in their own, entirely independent trees.

If done correctly, this would provide full, direct support for these and more capabilities:

1. A single pages appearing in multiple menus or in multiple menus;
   
2. Any url as a menu node, not just pages;
3. Different menus for different languages;
   
4. Unlimited menus;
   

Some of these things are already do-able if you consider the relatively recent contribution of Redirect overrides on pages. This has become a very powerful tool to work around some of the shortcomings of the menu system, but, its less than ideal because pages linked in this way are no longer translatable, not to mention that for many use-cases, it is a total abuse of the use of the HTTP302/301 and we are left with utter confusion in the page tree.

As we now have replaced mptt with treebeard, I think we're in a great position to leverage this new foundation to do more. Specifically, disassociate the page tree from menus.

[Noah A]

I recently started my first ever project with Django CMS. I've used many CMSes over the last 15 years and the menu system really shocked me with how limited it was for my purposes. Almost every project I've worked on of any reasonable size has required pages which show up in multiple places, as well as multiple menus. It's also been very common to need to include non-cms URLS in with CMS pages. For example there might be some service and support pages but also need to be a link to a subdomain which runs the support department's ticket system.

[Martin]

This sounds awesome. Big +1 from me!

--
You received this message because you are subscribed to the Google Groups "django-cms-developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-cms-devel...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Iacopo Spalletti]

In data domenica 26 ottobre 2014 13:35:07, Noah A ha scritto:
> I recently started my first ever project with Django CMS. I've used many
> CMSes over the last 15 years and the menu system really shocked me with how
> limited it was for my purposes. Almost every project I've worked on of any
> reasonable size has required pages which show up in multiple places, as
> well as multiple menus. It's also been very common to need to include
> non-cms URLS in with CMS pages. For example there might be some service and
> support pages but also need to be a link to a subdomain which runs the
> support department's ticket system.

Most of this can be handled with the current menu system, actually.
We must bear in mind the target of django CMS: as the "moderator" feature
teached us, more complete and rich implementation may actually hamper the
users that want to use that feature.
I'm +1 on evolving the menu system in a more flexible way, but in my own
experience multi-tree implementation is quite confusing for many most users
and not trivial to handle on the UI side.
I think that a different UI for pages that behaves like pointers to other
nodes in the tree might serve the purpose of a first step of the evolution of
the menu system in a lean and compatible way

>
> On Sunday, October 26, 2014 6:48:40 AM UTC-7, Martin Koistinen wrote:
> > Hi all,
> >
> > There's been a lot of movement around the CMS menu system lately and I'd
> > like to point out that IMHO, all of the latest developments around menus
> > have been hacks. I don't in anyway mean to discredit the work done on
> > these
> > by using the work "hacks", some of the work is amazing! However, I say
> > "hacks" because they are all trying to work around shortcomings in the
> > core
> > menu system, which I think stems from the 1:1 association between pages
> > and
> > menu nodes.
> >
> > I think it may be time to consider a different approach, one that allows
> > the page tree to continue to represent a url path structure for pages and
> > their associated breadcrumb paths but allows operators to create and
> > manage
> > any number of menus in their own, entirely independent trees.
> >
> > If done correctly, this would provide full, direct support for these and
> >
> > more capabilities:

> > 1. A single pages appearing in multiple menus or in multiple menus;
> > 2. Any url as a menu node, not just pages;
> > 3. Different menus for different languages;
> > 4. Unlimited menus;

> >
> > Some of these things are already do-able if you consider the relatively
> > recent contribution of Redirect overrides on pages. This has become a very
> > powerful tool to work around some of the shortcomings of the menu system,
> > but, its less than ideal because pages linked in this way are no longer
> > translatable, not to mention that for many use-cases, it is a total abuse
> > of the use of the HTTP302/301 and we are left with utter confusion in the
> > page tree.
> >
> > As we now have replaced mptt with treebeard, I think we're in a great
> > position to leverage this new foundation to do more. Specifically,
> > disassociate the page tree from menus.

--
Ciao
IS
Iacopo Spalletti

PGP key block: http://www.spalletti.it/pgp

[Jacob Rief]

I'm very favorable to a new menu system. In my opinion, a few shortcomings of the current menu system shall be solved:

• We need an easy way to allow different menu roots. Websites typically have a main menu and possibly some header/satellite and footer menus. While it currently is possible to emulate them with tricky settings, for CMS administrators these settings are all but intuitive.
  
• Each root of such a tree shall allow some extra attributes. One of them should be the maximum depth to create menus for mobile devices which shall not nest too deeply.
• We shall allow different menu nodes to point onto the same page.
• One big application for this feature are single web pages controllable, still navigable through the main menu system. For this one could use the well known URL#section syntax or the new routing possibilities as found in HTML5.
• Such as a menu system would allow us to implement multi-view pages with partial HTML snippets loadable on the fly. This is an upcoming technology with a very strong momentum. For details please refer to Tim Kindberg's excellent talk https://www.youtube.com/watch?v=dqJRoh8MnBo
• It shall be possible to add extra fields to a node, such as icons or additional text. This extra information then shall be available to the rendering templates.

All in all, this means to convert the current menu system from a 1:1 relationship from nodes to pages to an m:n relationship.

[Angelo Dini]

I'd also suggest that a menu can have a hash url instead of a fixed url, for example:

en/#home

instead of

en/home

as this is currently not possible.

[Dries Desmet]

+1 on angelo's proposal. This is a concise issue that could be tracked as a single improvent. Did someone file a github issue for this yet?