You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
An agency (Victoria Legal Aid) performed automated migration of content and menus from Drupal 7 into two of their SDP sites. The Sites main menus contained over a hundred (100+) menu items in a hierarchy greater than five (5) levels deep.
Side note: Menu content in the Drupal CMS does not scale well to accommodate hundreds of menu items. This is a known Drupal issue, spanning many years, with specific feature additions to enable effective editing and publishing of large, deep menus.
Rendering of a Ripple website with a deep, very large menu hierarchy behaved in unexpected ways.
The first load of the homepage took minutes to return a result, which ended in an error response
Subsequent page loads did complete with the header menu (main menu) sometimes rendered in an unexpected way
Opening the menu hierarchy beyond the first 3 or 4 levels, extends the deeper branches beyond the visible areas of the page
Steps to reproduce
Create a main menu in the CMS with over 100 items in a hierarchy that is 5+ levels deep.
Assign this menu to the Sites taxonomy as the main site menu
Clear the caches in the CMS and at the edge
Open the homepage for the Site
This should show unexpected rendering results, similar to the ones described above. It may show an HTTP error response on first page load.
Proposed solution
Caveat: I do not know for sure where the rendering time is being spent, but I suspect Ripple is not expecting the very large, very deep, menu content response from the CMS.
One idea, to perhaps mitigate against rendering issues, for overly deep, overly large CMS menus, would be to limit the JSON:API response when requesting the main menu content from Tide. If Ripple knows that it should only render a menu at 3 or 4 levels deep, then perhaps any request for the menu content should be limited to that depth.
This is not really a Ripple bug, as these very deep, very large menus may not be supported by the design system specifically. The intent would be to more gracefully render the site when a menu was authored that exceeded the limits for Ripple's design.
The text was updated successfully, but these errors were encountered:
Motivation
An agency (Victoria Legal Aid) performed automated migration of content and menus from Drupal 7 into two of their SDP sites. The Sites main menus contained over a hundred (100+) menu items in a hierarchy greater than five (5) levels deep.
Side note: Menu content in the Drupal CMS does not scale well to accommodate hundreds of menu items. This is a known Drupal issue, spanning many years, with specific feature additions to enable effective editing and publishing of large, deep menus.
Rendering of a Ripple website with a deep, very large menu hierarchy behaved in unexpected ways.
Steps to reproduce
This should show unexpected rendering results, similar to the ones described above. It may show an HTTP error response on first page load.
Proposed solution
Caveat: I do not know for sure where the rendering time is being spent, but I suspect Ripple is not expecting the very large, very deep, menu content response from the CMS.
One idea, to perhaps mitigate against rendering issues, for overly deep, overly large CMS menus, would be to limit the JSON:API response when requesting the main menu content from Tide. If Ripple knows that it should only render a menu at 3 or 4 levels deep, then perhaps any request for the menu content should be limited to that depth.
This is not really a Ripple bug, as these very deep, very large menus may not be supported by the design system specifically. The intent would be to more gracefully render the site when a menu was authored that exceeded the limits for Ripple's design.
The text was updated successfully, but these errors were encountered: