Right now the submenu widget options for expanding the menu are all-or-nothing. You can't expand only the top level, or only a subsection. For sites with big menus, this means the submenu widget is either overwhelming (when expanded) or too sparse (when collapsed).

We could add an option to control how deep to do the expanding which is only shown after clicking the "Expand all children" option. We should reword that option to make sense when it's not "all" children.

Comments

dsnopek created an issue. See original summary.

dsnopek’s picture

Status: Active » Needs review
StatusFileSize
new3.83 KB

Here's a patch that implements this!

cboyden’s picture

Status: Needs review » Needs work

The patch does what you expect when you save the widget, but if you reload the page, the full depth of the menu is displayed.

To reproduce:

  1. Do a clean install of the latest dev of Panopoly, including demo content.
  2. Apply the patch to panopoly_widgets.
  3. Create a landing page titled "Landing page" and add it to the main menu at the top level.
  4. Create a content page titled "Page 1" and add it to the main menu as a sub item of the landing page.
  5. Create a content page titled "Sub page 2" and add it to the main menu as a sub item of Page 1.
  6. On the landing page, add a submenu widget.
  7. Configure the widget
    • Starting level: 1st level
    • Fixed parent item: Landing page
    • Expand children of this tree: Checked
    • Maximum expanded depth: Only 2 levels
  8. Save the widget.
  9. Note the submenu displays only the "Page 1" link.
  10. Save the IPE.
  11. Note the submenu still displays only the "Page 1" link.
  12. Reload the page.
  13. Note the "Sub page 2" now displays.

Also, when I added this patch to an already-installed Panopoly site, I saw this notice on a page with an existing submenu widget: Notice: Undefined index: expanded_max_depth in panopoly_widgets_menu_block_tree_alter() (line 499 of /panopoly/modules/panopoly/panopoly_widgets/panopoly_widgets.module).

dsnopek’s picture

Did you clear caches after applying the patch? This depends on alterations to the CTools content type, which won't actually happen until a cache clear. This would also be the source of the notice -- that can only happen if the content type info hasn't been altered.

cboyden’s picture

Yes, caches are cleared. If you clear caches, then repeat steps 7 through 12, you should see the same results.

dsnopek’s picture

Status: Needs work » Needs review
StatusFileSize
new6.44 KB
new1.22 KB

Ok, thanks! I've finally gotten around to actually trying this, and you're right!

I'm really not sure how the PHP notice is possible - since the CTools content type has a default for that config value, it should always be set... But whatever, it's easier to just fix rather than go spelunking in CTools to see what's going wrong.

The actual bug, though, was a logic problem with handling the active trail. If a link was part of the active trail, it wouldn't descend to it's children, where it should just not removed the link itself, but still descended to its children.

Here's an updated patch!

cboyden’s picture

Status: Needs review » Reviewed & tested by the community

Thanks @dsnopek, the updated patch is working as expected.

  • dsnopek committed efbfdcb on 7.x-1.x
    Update Panopoly Widgets for Issue #2860930 by dsnopek, cboyden: Add...
dsnopek’s picture

Status: Reviewed & tested by the community » Fixed

Awesome, thanks! Committed :-)

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.