Menu Customizer Now in Development for WordPress 4.2


WordPress 4.1 was released just yesterday, but core contributors are already planning and working towards 4.2. The Menu Customizer feature plugin is back in development and contributors are hoping to have it ready for inclusion in 4.2. Nick Halsey, who originally started the Menu Customizer work as part of his Google Summer of Code project, will be leading the effort to get the feature prepared for the upcoming release.

During the last release cycle, Halsey was focused on improving the Customizer API in core to add dynamic and contextual controls, sections, and panels. The Menu Customizer plugin has now been updated to be compatible with WordPress 4.1 and is ready to pick up development where it left off. As it’s no longer a GSoC project, Halsey is now actively looking for contributors.

Currently, the menu customizer is usable and offers the ability to assign menus to locations, edit existing menus/menu items, and add new menus.


Halsey outlined a roadmap for preparing the Menu Customizer for merge, which includes a number of PHP and Javascript development tasks, including, but not limited to, the following:

  • Build-out the core API for adding Customizer sections and controls entirely with JavaScript, #30741 and its related tickets (PHP, JS)
  • Drag and Drop menu item reordering needs to do sub-menus (code imported from nav-menus.php is commented out in menu-customizer.js currently) (JS)
  • Fix problems with previewing updates to menu items, and with previewing newly-added menus once items are added (JS)
  • Redo the add-menu-items “panel” to lazy-load its contents & utilize Backbone sub-views (PHP, JS)

He also hopes to improve the experience of using the customizer on mobile, followed by getting the menu customizer plugin to work on mobile. Halsey is also looking for contributors to assist on the design, code review, a backwards-compatibility audit, and inline documentation.

If you’re curious about how the Menu Customizer works, anyone is welcome to try the plugin and offer feedback. For the time being, it is compatible with WordPress 4.1 but may require 4.2-alpha down the road as it progresses.

Contributor interest is critical for the Menu Customizer to have a shot at inclusion in WordPress 4.2. If you can help in any way, jump in on the Make/WordPress Core post to volunteer.


7 responses to “Menu Customizer Now in Development for WordPress 4.2”

  1. Why? is this really needed?
    It seems like they’re trying to put everything into the customizer. At this rate everything WILL be in the customizer, and they can get rid of the admin all together. Then WordPress will just be a Drupal clone. One of the thing I like best about WordPress is it’s great admin section, so why are they trying to get rid of it?

    There’s just so much more they could be spending their time on.

    • The goal is to move all of the “appearance” things to the Customizer, and to encourage plugins to put any options that change the front-end in the Customizer. The Customizer, simply put, offers a much better and more streamlined user experience than the admin, primarily because of the live previewing functionality.

      The other advantage to the Customizer is that it’s easier for themes and plugins to integrate their options there than in the admin, in a way to provides a seamless experience for users.

      If you’ve ever looked into the menus code, you’ll know that it is a complete disaster. Menus in particular need a complete rewrite anyway, which is why the Menu Customizer project is important.

  2. The new customizer should be completely optional or a filter to enable older full width version without preview should be supplied.

    Just add some 20+ images as random header image with the new customizer. Or 6+ menus with 50 entries each for different site areas, or 10+ widgets in 20+ sidebars.

    Impossible to handle with the new customizer for people without deep WordPress knowledge and understanding. But in real life these are the people who should be able to add content to a WordPress site.

    If you use WordPress as CMS instead of a “look-at-my-latest-video” Blog, the new customizer is a perfect example of very very bad UX.

    Things like the new customiozer kill the simple and straight-forward usability which WordPress is/was famous for.

    • The Customizer is not new, it’s two and a half years old. And it’s arguably much simpler and easier to use than equivalent features in the admin. If you try the Menu Customizer plugin, I think you’ll find that it’s actually much easier to manage menus in the Customizer than the admin, especially with many, large menus. That’s not simply because there’s less space for UI but because the UI is more efficient. And, you can see what impact your changes have on your site as you make them.

      When used properly, the Customizer can actually be much more useful for CMS-style sites than simple blogs.

      • > When used properly..

        And exactly here is the problem. In real life people like a secretary etc. want/have to edit their CMS in a productive way, they just want to add, edit or remove content.

        They do not want to scroll through screens-high tiny sidebars with barely understandable shortened button texts, no additional information and a useless preview which takes most of the screen.

        Just try my random header images example. Or my widget/sidebars example. The customizer is completely useless for these setups.


Subscribe Via Email

Enter your email address to subscribe to this blog and receive notifications of new posts by email.

%d bloggers like this: