Simplify Menu and Twig Macros

Mediacurrent Team — Wed, 28 Jun 2017 13:05:34 +0000

It is true that many Frontend Developers loathe the chore of creating a site’s menu, but I personally enjoy building them. I always thought of a website’s menu system as the perfect example of “the evolution of code”.

Most menus start with a simple nested list of menu links; at most, all you need is the text and URL for the menu item. But over time, as the complexities of the menu and site evolve, you begin to watch as a complete custom menu system develops by adding parameters and logic. It’s a beautiful thing to observe.

The same holds true with a menu module. Take the Drupal 8 Simplify Menu module as an example.

Implemented as a TwigExtension to gain access to Drupal’s menu system, the array structure returned from `simplify_menu(menu_machine_name)` includes what is needed to have a simple menu.

"menu_tree": [
  {
    "text": "Section Menu text",
    "url": "#",
    "submenu": []
  }
]

Note that within the `"submenu":` array, the structure within the `{}` can repeat infinitely.

Creating a menu macro

With the understanding of the returned array structure, Twig macros can be leveraged to create a recursive menu. Here is an example of a rudimentary menu macro using the structure from the `simplify_menu(menu_machine_name)` function.

{% macro menuMacro(menu) -%}
  <ul>
    {% for menu_item in menu %}
      <li>
        <a href="{{ menu_item.url }}">{{ menu_item.text }}</a>
        {% if menu_item.submenu %}
          {# Since this menu item has a submenu, recall function. #}
          {{ _self.menuMacro(menu_item.submenu) }}
        {% endif %}
      </li>
    {% endfor %}
  </ul>
{%- endmacro %}

An array of menu items, `menu`, is passed into macro containing `text`, `url`, and `submenu` in each row.

Active Trails

Active & active-trail support is not supported in Simplify Menu module at the time of this writing. However, a patch exists on Drupal.org that adds this functionality to the array structure from the Simplify Menu module.

Big shoutout to smurrayatwork for implementing the active trails!

After the successful application of the active trails patch, the array structure returned from `simplify_menu()` includes 2 additional keys per row.

"menu_tree": [
  {
    "text": "Section Menu text",
    "url": "#",
    "active": true|false,
    "active-trail": true|false,
    "submenu": []
  }
]

And with the new keys in the array structure, we can then add some classes to our menu structure.

{% macro menuMacro(menu) -%}
  <ul>
    {% for menu_item in menu %}
      {# Check if this is the active item. #}
      {% set active = (menu_item.active) ? ' is-active' : '' %}

      {# Check if this item is in the active trail. #}
      {% set active = active ~ ((menu_item.active_trail) ? ' is-active-trail' : '') %}

      <li class=”menu__item{{ active }}”>
        <a href="{{ menu_item.url }}"  class=”menu__link{{ active }}”>{{ menu_item.text }}</a>
        {% if menu_item.submenu %}
            {# Since this menu item has a submenu, recall function. #}
          {{ _self.menuMacro(menu_item.submenu) }}
        {% endif %}
      </li>
    {% endfor %}
  </ul>
{%- endmacro %}

Example uses string concatenation to build string of classes. Optionally, an array could be used with `|join()` in Twig.

Menu level classes?

An available class that identifies what level you are in a menu can make many tasks easier. About the easiest way to accomplish this with a Twig macro is to use simple integers. Setting a variable with a default of `1`, the menu would have the ability to know where it is in the loop.

{% macro menuMacro(menu, level) -%}

  {# Set our default level as an integer. #}
  {% set default_level = 1 %}

  <ul class=”menu-level--{{ level|default(default_level) }}”>
    {% for menu_item in menu %}
      {# Check if this is the active item. #}
      {% set active = (menu_item.active) ? ' is-active' : '' %}

      {# Check if this item is in the active trail. #}
      {% set active = active ~ ((menu_item.active_trail) ? ' is-active-trail' : '') %}

      <li class=”menu__item{{ active }}”>
        <a href="{{ menu_item.url }}"  class=”menu__link{{ active }}”>{{ menu_item.text }}</a>
        {% if menu_item.submenu %}
            {# Since this menu item has a submenu, recall function and increment counter. #}
          {{ _self.menuMacro(menu_item.submenu, level|default(default_level) + 1) }}
        {% endif %}
      </li>
    {% endfor %}
  </ul>
{%- endmacro %}

Parameter `level` is now passed into function, in addition to a new variable added for default value. `level` is then added as part of a class, ensuring that the default value is provided. `level` is then incremented when called recursively.

Be careful of over-engineering

While this solution can be used to create a recursive menu, if a recursive menu is not needed, implementing one can be more work than it is worth. If all you are looking in your menu is a few levels at max, it may just be easier to code in the levels in the template, versus creating an intricate recursive structure.

Use the right tool for the job!

Conclusion

At the end of the day, it all comes down to an understanding of recursive functions. A function calling itself recursively will allow an entire array tree to be traversed. Get what you need into that array, or available in another context in the template, and you will be able to act on all levels of the menu structure.

Mediacurrent Team Wed, 06/28/2017 - 09:05

Main Image

twig_0.jpg

More Mobile Menu Options

Mediacurrent Team — Fri, 07 Dec 2012 18:59:45 +0000

More Mobile Menu Options

There are a lot of ways to handle navigation in general, because “best practices” for mobile are still being sorted out. There isn’t a one-size-fits-all solution because everyone has different needs for their site, and their menus are organized differently.

I recently had the opportunity to participate in a DrupalEasy podcast this week about designing and implementing mobile-friendly navigation. We discussed a handful of the options I outlined in my previous mobile menu blog post, but a few other strategies surfaced that I wanted to share.

The DHTML module. Be sure that if you are using this module that you’ve really thought through the options on what to do with parent links. You can find the options at /admin/config/user-interface/dhtml_menu which cover a variety of ways to handle those links. As far as UX goes, the "None"option is probably best. Meaning that pages that contain child links are not actually pages, rather they are just "containers" for the child links, or a means to organize and sort your menu tree of options. This is not ideal for everyone, but if you find yourself struggling to fill those parent pages with content and you wind up just describing the child pages -- this can be a great option.
If the parent pages on your site do hold real content, you could create a hybrid version of the accordion menu that allows users to both hit parent pages and reveal child links. This method is outlined nicely here - however I encourage lots of testing with this method since it appears that the JS loading the expand link was a bit slow on my phone.
Print the menu twice, create a anchor link at the top that jumps users to the bottom where the menu is. With this method, you can use menu blocks set to show children menu items when a user is on the parent page. This can mean less scrolling past dozens of children menu options, but it also means that users have to click on a parent page to see the other child links for that page.
Transform a list of links into a select menu for small screens. This avoids the problems the top nav approach presents and is a clever way to save real estate. There is a Drupal module called tinynav.js that does this. Note that if you have a huge menu tree, this can create an overwhelming sea of links for users. This method also makes it harder to see the hierarchy of the links.

Above all else, remember not to treat your mobile users like they are less deserving of your content than the desktop users. Don't hide content or make menus difficult to use, and be sure to test any solution on a myriad of actual mobile devices.

Additional Resources

Responsive Design: Mobile Menu Options

[video] 7 Deadly Myths of Mobile

Free Drupal Whitepaper | The Mobile Web and Drupal

Mediacurrent Team Fri, 12/07/2012 - 13:59

Responsive Design: Mobile Menu Options

Mediacurrent Team — Wed, 03 Oct 2012 15:47:11 +0000

Responsive Design: Mobile Menu Options

At various Omega presentations I've given at Drupalcamps and in blog posts I've written, people have asked me about responsive menu options. Brad Frost has outlined some great options for responsive menus, and I'd encourage you to do your research since it's a always a good idea to review what your options are before deciding on a particular path. I will say that using browscap to hide/show your menu(s) is not recommended or necessary since browser sniffing is not very reliable, hence the whole movement toward responsive design.

Since I'm now theming primarily with Omega, I typically style the menu links to be finger-friendly for mobile, and then I'll add styles to that same menu to put it back into a normal menu bar shape for desktop. Then I'll add a "menu link" block that displays only for mobile users (the default.css Omega stylesheet has this block set to display:none;). This link uses a bit of jQuery to hide and show the menu items (to save on space).

Check out this year's Drupalcamp Atlanta site to see the jquery mobile menu in action.

Since I've used this method 2 or 3 times now for different sites, my co-worker Kevin turned it into a module, and the sandbox version is on Drupal.org. So check out the Mobile Menu Toggle module, maybe it will save you a bit of time. Please provide feedback (or report issues if there are any)!

If you are using OM Maximenu, those can be a bit unruly so you could use a separate menu for mobile. Or you can use Menu Blocks to help you build both the mobile menu and the MaxiMenu off of the same menu tree like Primary Links, which would be ideal. Thanks to Danté for that tip!

Just create your Primary Menu structure first, and then create separate menu blocks for use in the maximenu structure. You can import the primary menu links using the import tab on the MaxiMenu admin page. Then save yourself time by adding all the children via menu blocks. You'd likely set these menu blocks to only begin displaying at the secondary menu level and show all the children. Then create another menu block just for mobile users, which only displays the children menu items when you are on their parent page, like this. Note, that example just uses anchors to jump to the menu at the bottom instead of hiding it.

Hope some of this has been helpful, and thanks to Brad Frost for his thorough coverage on all the different options out there! It's really a case-by-case issue, where you must determine which solution works best for your website needs.

Additional Resources

Going Mobile with Drupal | Mediacurrent Blog Post

Responsive Design + Drupal | Mediacurrent Blog Post

Mediacurrent Team Wed, 10/03/2012 - 11:47