Ask Questions and Find Answers
Important:
Ask is now read-only. You can review any existing questions and answers, but not add anything new.
But - don't panic! While ask is no more, we've replaced it with discuss - the new Liferay Discussion Forum! Read more here here or just visit the site here:
discuss.liferay.com
Simple Solution To Restoring Tree Menu
Forgive the roughness of this example, I went to the Clay site and live edited in inspector the "left navigation" menu. Because this issue is so important and a solution needs finding faster than ASAP and a year has passed with no solutions ... let's build something very simple and work on it in the fixpacks.
We don't need a tree, we don't need a search box, we just need a navigation menu.
Clay provides this, it's there.
https://lexicondesign.io/docs/patterns/Navigation/verticalNav.html
The idea here is that Public Pages ... is a top level item like "Content" or "Control Panel" each page under that is then a page in the heiracy (and only pages, no complex Link to Pages, no drag and drop, nothing that isn't a navigation menu for navigating a website). The only nice touch visually would be to have an icon to let the user know if the page was a content or widget page but even that complication isn't needed and can come as enhancements.
We don't even need to call it a navigation menu, we can call it a page switcher but they must be hyperlinks in a menu format because it's a menu system. If needed let's have the "Expand Area" link that opens the modal that has the same HTML in it with more horixontal space. Clay provides it and it's a series of styled ul li tags without any complex plus or minus icons. This can be done for 7.2 release, we must succeed, we can!
There's even a great album full of mind clearing tunes to code to, this problem can be solved. Then we can get the product menu back to some form of funcctionality for site admins as time goes on, but site admins can't be left navigating pages in the build section.
We don't need a tree, we don't need a search box, we just need a navigation menu.
Clay provides this, it's there.
https://lexicondesign.io/docs/patterns/Navigation/verticalNav.html
The idea here is that Public Pages ... is a top level item like "Content" or "Control Panel" each page under that is then a page in the heiracy (and only pages, no complex Link to Pages, no drag and drop, nothing that isn't a navigation menu for navigating a website). The only nice touch visually would be to have an icon to let the user know if the page was a content or widget page but even that complication isn't needed and can come as enhancements.
We don't even need to call it a navigation menu, we can call it a page switcher but they must be hyperlinks in a menu format because it's a menu system. If needed let's have the "Expand Area" link that opens the modal that has the same HTML in it with more horixontal space. Clay provides it and it's a series of styled ul li tags without any complex plus or minus icons. This can be done for 7.2 release, we must succeed, we can!
There's even a great album full of mind clearing tunes to code to, this problem can be solved. Then we can get the product menu back to some form of funcctionality for site admins as time goes on, but site admins can't be left navigating pages in the build section.
Attachments:
I wish it was that simple . This doesn't work because there are Liferay installations with sites that have thousands of pages. Some times even within one specific level. To support this type of scalability we need a tree that can load on demand, for each node and then also be able to do progressive loading if there are many pages within that level. We are looking into solutions that support this.
Couldn't nav be smarter? I.e. if less than 1k pages, use the tree. When 1k or more (threshold defined in portal-ext.properties or something), switch to the miller columns?
I mean, if our whole issue is that tree only works for small counts but miller is needed for large, why not let the number of pages define the tipping point?
That way each group can get what they want/need...
I mean, if our whole issue is that tree only works for small counts but miller is needed for large, why not let the number of pages define the tipping point?
That way each group can get what they want/need...
David H NebingerCouldn't nav be smarter? I.e. if less than 1k pages, use the tree. When 1k or more (threshold defined in portal-ext.properties or something), switch to the miller columns?
The problem for Liferay here would be a huge U turn. We've been told for a year that only miller collumns can work that trees cannot so my solution isn't even a tree!! BUT even the users with thousands of pages, will have issues trying to drag and drop pages into different parent sections because miller removes the ability to do this easily (if at all). So those users if needing to make those changes would need to use the tree method (even the table method couldn't do this).
Alll users need both methods, because miller columns was designed basically for a pool of pages it can't do what the tree can do. My suggestion was to just put a navigation menu in the product menu without any management features and continue crippled with with the miller columns until we can figure out how to restore what was in 7.0.
We need something for site admin page navigation that resembles 7.0 ... fast.
For me the question is:
Where is the majority? I mean, the largest tree I have here has about 600 pages. No customer complaints and when have to work with it, well, it works.
My best guess is that sites with huge trees are quite the minority. Of course, they should have a nice experience too and maybe MC is the best solution for them. But it is a mediocre solution for most of us.
(Note: My biggest beef is not with MC itself, it is MEH, but I could live with it)
Long story short: I second what David said: Make it smarter. Or optional. Let me, as an admin, choose which implementation to use.
Btw.:
The current concept actually does not "fix" *my* issues with the old tree. All pages are still in one tree, the default tree and MC. So, there is still one huge tree, even if I could have created multiple small trees. One for top nav, main nav, quicklinks, footer nav, ...
AND the current implementation has lots of side effects, e.g.:
Create a page p1. Create parallel pages, p2, p3, p4.
Create a navigation nav1. Add p1 as "root" node and p2, p3, p4 as children.
Now delete p1.
Effect: nav1 is empty, since you have deleted the root node.
So, I would need to see all navigations, where the current page and all children of the current page are used.
Where is the majority? I mean, the largest tree I have here has about 600 pages. No customer complaints and when have to work with it, well, it works.
My best guess is that sites with huge trees are quite the minority. Of course, they should have a nice experience too and maybe MC is the best solution for them. But it is a mediocre solution for most of us.
(Note: My biggest beef is not with MC itself, it is MEH, but I could live with it)
Long story short: I second what David said: Make it smarter. Or optional. Let me, as an admin, choose which implementation to use.
Btw.:
The current concept actually does not "fix" *my* issues with the old tree. All pages are still in one tree, the default tree and MC. So, there is still one huge tree, even if I could have created multiple small trees. One for top nav, main nav, quicklinks, footer nav, ...
AND the current implementation has lots of side effects, e.g.:
Create a page p1. Create parallel pages, p2, p3, p4.
Create a navigation nav1. Add p1 as "root" node and p2, p3, p4 as children.
Now delete p1.
Effect: nav1 is empty, since you have deleted the root node.
So, I would need to see all navigations, where the current page and all children of the current page are used.
Christoph RabelFor me the question is:I've heard several reasons why the tree didn't work and most of those reasons could have been addressed if the users in question had clicked the "Expand Area" link and that expand area section could have easily housed the miller columns but what's done is doen we move on.
Where is the majority? I mean, the largest tree I have here has about 600 pages. No customer complaints and when have to work with it, well, it works.
I can see "Load More" being a PITA for large sites, but load more did solve the issue of having to load an entire menu. It could have been that when clicking the top level item it then reloaded the menu so that only that site section was in scope, limiting the length of the menu (a back icon could then have naviigated backwards up the tree). Site admins could have been given a bookmarks feature to work around large menus to get to deep pages fast by way of bookmarking them.
At the end of the day one use case has overulled several hundred
Jorge FerrerTo support this type of scalability we need a tree that can load on demand, for each node and then also be able to do progressive loading if there are many pages within that level. We are looking into solutions that support this.Load More?
In any case if a site admin is structuring their site with one parent section that then has thouasands of pages under it ... they need a lesson in Information Architecture and Taxonomy and Liferay should be working with these users to better design their IA ... rather than enabling bad practice. Sure the BBC could remove all of their topics and taxonomy and have thousands of pages under one "News section" ... but they'd be riddiculed for it.
We only need a menu system restoring ... the users that have 1,000's of pages have their needs met. Please meet the the needs of the 99%.
What david said 1,000x. For the sites that do have thousands of pages ... have a setting to turn the thing off. Let the installations that have no problems continue to have navigation.
Miller collumns ... take a step back. It's not a navigation menu and is much better suited to Documents and Media (but please don't make it the default). Please listen to sense, people don't navigate the world wide web by using miller columns. They use search engines to find sites, once on a site they navigate sites using a series of hyperlinks structured into a menu, either nested or drop down. Liferay's scalaibility issue is not our problem to solve and while solving that issue for a minority of users it shouldn't take away functionality for the majority while trying to solve that issue. Miller columns actually present worse scalability issues, you can't open several nested sections at the same time.
If what is being said about thousands of pages under one parent item is true ... No wonder miller collumns is so hard to use for users who have structured their sites repsonsibly using child pages and no wonder Liferay still refuse to understand the issue of grandchild pages (child > child pages). If this whole thing is built around the notion that you have a pool of pages that are then arranged into taxonomies using navigation menus ... Liferay have made a huge misstep in understanding how responsible site admins have built their IA based on page heiracy. The ADT's still only show child pages, they don't show child child pages so site admins can't use navigation menus. They could use a site map as a workaround but that is a terrible downgrade in UX.
"Navigation" has been confused. The site map is navigation for site admins, the navigation menus are for site members / visitors. The site navigation has been removed from site admins and needs putting back.
Miller collumns ... take a step back. It's not a navigation menu and is much better suited to Documents and Media (but please don't make it the default). Please listen to sense, people don't navigate the world wide web by using miller columns. They use search engines to find sites, once on a site they navigate sites using a series of hyperlinks structured into a menu, either nested or drop down. Liferay's scalaibility issue is not our problem to solve and while solving that issue for a minority of users it shouldn't take away functionality for the majority while trying to solve that issue. Miller columns actually present worse scalability issues, you can't open several nested sections at the same time.
If what is being said about thousands of pages under one parent item is true ... No wonder miller collumns is so hard to use for users who have structured their sites repsonsibly using child pages and no wonder Liferay still refuse to understand the issue of grandchild pages (child > child pages). If this whole thing is built around the notion that you have a pool of pages that are then arranged into taxonomies using navigation menus ... Liferay have made a huge misstep in understanding how responsible site admins have built their IA based on page heiracy. The ADT's still only show child pages, they don't show child child pages so site admins can't use navigation menus. They could use a site map as a workaround but that is a terrible downgrade in UX.
"Navigation" has been confused. The site map is navigation for site admins, the navigation menus are for site members / visitors. The site navigation has been removed from site admins and needs putting back.
Hi Lee, Christoph,
As always, I want to thank you for the feedback. I want to emphasize that Liferay is listening and that I am listening to your concerns and needs. Not only that, we are actively looking for solutions that solve the needs without going back to the problems we had in the past.
I understand you wish we could find the solution sooner (I do too!) and will work to get it ready as soon as possible. I hope some improvements in 7.2 will already be an step in the right direction and I hope a final solution for all the needs brought up in this thread will be available for 7.3.
Meanwhile, it can be solved but requires some coding to get back the tree into the product menu.
As always, I want to thank you for the feedback. I want to emphasize that Liferay is listening and that I am listening to your concerns and needs. Not only that, we are actively looking for solutions that solve the needs without going back to the problems we had in the past.
I understand you wish we could find the solution sooner (I do too!) and will work to get it ready as soon as possible. I hope some improvements in 7.2 will already be an step in the right direction and I hope a final solution for all the needs brought up in this thread will be available for 7.3.
Meanwhile, it can be solved but requires some coding to get back the tree into the product menu.
Appricate the work, while I echo the concerns that we just don't understand why a site has thousands of pages ... it clearly is an issue for Liferay that you guys are struggling with. While I can;t personally understand how miller columns is a better solution for those users I respect that you guys have an issue that is hard to solve. We also have thousands of pages, millions of page views per year and probably hundreds of thousands of web content articles ... but our portal is organised into roughly 500 sites so each site would never run over or even come close to that number of widget pages and we've never run into the issues being described.
For 7.2 there has to be a solution to this impasse and I think David hit the nail on the head.
Configure the portal to allow or disallow a tree menu in the product menu based on what the installation needs (and it's ok to keep the miller columns, we just need page navigation on the left not page management). When we upgrade then we can maintain continuity for our users while at the same time Liferay can offer the users that do have thousands of pages a working product.
Making it work for them and removing features from us is why we're so outspoken.
For 7.2 there has to be a solution to this impasse and I think David hit the nail on the head.
Configure the portal to allow or disallow a tree menu in the product menu based on what the installation needs (and it's ok to keep the miller columns, we just need page navigation on the left not page management). When we upgrade then we can maintain continuity for our users while at the same time Liferay can offer the users that do have thousands of pages a working product.
Making it work for them and removing features from us is why we're so outspoken.
Copyright © 2025 Liferay, Inc
• Privacy Policy
Powered by Liferay™