Menu Customizer Tentatively Approved for WordPress 4.3

WordPress 4.3 release lead Konstantin Obenland posted notes from this week’s core development chat, confirming that the Menu Customizer plugin has been conditionally approved to merge. The approval is pending a few conditions that will be required before officially merging it:

  • Complete a11y audit.
  • Address possible blockers.
  • Merge php tests.
  • Add JS tests.

One of the most controversial aspects of the proposal submitted by project leader Nick Halsey was the timeline he outlined for removing all core links to the old Menus admin screen in future releases. Commenters on the proposal reacted strongly to this approach as well as this particular use of the customizer.

Discussion continued following the meeting, as Halsey wanted to address the critical issue of the timeline for removing removing the menus screen from the admin. He attributes the resistance to the customizer to a lack of education on the feature and strongly advocates “focusing on the new UI as the primary (and in terms of development, only) menus admin interface.”

For Menu Customizer, this idea has been part of the project from the very beginning. My GSoC proposal (3/20/14) states ‘If the Menu Customizer provides all of the features of the existing menu management screen, while clearly demonstrating that it is a better solution than the existing screen in user tests, it could potentially replace the existing screen entirely for users that can access the Customizer,’ and there has never been indication that this isn’t the direction we should move in, other than the general and ongoing resistance to the Customizer as a whole that we’ve seen from many community members (which I think is more of an educational issue).

Discussion continues on the matter and work will move forward on the plugin to ensure that it meets the conditions outlined for its merge into WordPress 4.3.

63 Comments


  1. It’s extremely frustrating to have such a large and vocal opposition to this change be completely written off as “more of an educational issue” from someone on the core team.

    Report


    1. Nick is the plugin author. I would be interested in knowing what you define as “the core team”.

      Report


      1. Anyone (individual or team) that can approve a major change such as this being merged in to the core.

        Report


      2. Okay. That would not include the author of the statement in question. I understand the frustration that is going around, and am tracking it, but let’s be a little more mindful about the invocation of “the core team”.

        Report


      3. I suppose that would lead me to ask for clarification – do you, as a leader/someone on the core team, view this as “more of an educational issue”?

        Report


      4. So I take it that the core team repudiates Nick Halsey’s comments. Glad to hear it.

        In which case, what’s your justification for going ahead with this?

        Report


      5. I have no idea what is meant by “educational issue”, so I suppose it’s not possible for me personally to share the same view (I’m presuming “it” means resistance to the customizer as cited in the quotation, please let me know if I’m wrong).

        Report


      6. When we say educational issue, we’re generally referring to people not being aware of things like the purpose of the Customizer (as the people actively developing it see it) – being much broader than just themes and theme options, its extensibility in themes and plugins (which the new documentation should help), its incredibly powerful and well-thought-out API, etc. We generally define the Customizer as “A framework for live-previewing any change to WordPress.” Customizer-related development has generally centered around that idea for some time now, making adjustments to allow the UI to better scale to our anticipated future needs as we work on adding features like this. The thing with menus is that theme locations could already be changed in the Customizer, so with that moving into the new menus panel, we aren’t actually adding any new top-level UI to the Customizer with this change.

        There’s also the broader issue of people not understanding how core development works, or how decisions are made. There was a comment on Chris Lema’s post claiming that “This should have been developed as a plugin, like MP6” (paraphrasing), which sums this issue up pretty well I think (in case anyone missed it, the plugin has been in development for the past year and the post on make/core was a feature plugin merge proposal).

        Many of the commenters on the make/core proposal very clearly didn’t read that post. I’m guessing they came from here, or eventually might have just followed a link from twitter and built off of the concerns that some the initial commenters expressed with the proposal to remove the admin screen. As of now all that’s been decided for the admin page is that it’ll continue to be developed as it has been for a while now (with a few improvements here and there, but likely nothing major), at least for now. That being said, those working on the Customizer would like to get there eventually and I could see us doing it on the timeline in the post even if the broader core development community isn’t willing to commit to that just yet.

        I’m generally not a fan of the phrase “core team,” because it could be taken to mean a lot of different things and generally implies a closed group. Sure, I could be considered part of the “core team” in that I contribute pretty significantly to core, focusing on the Customizer in particular, but technically speaking I would be considered a “core contributor” or “contributing developer”. I’m also officially a “component maintainer” for the Customize component, meaning that I have developed a deep understanding of it and work to manage the tickets pertaining to the Customizer. But by nature of the process, those proposing a feature-plugin for merge don’t really get a say in whether it’s approved. Their work is generally going to be considered in regards to their other core contributions, though; if a lead dev proposed merging a plugin, it’ll almost certainly be approved by other contributors because they’ve built up a reputation for doing good work in core. It’s important to remember that WordPress is a meritocracy, not a democracy. More info (partially outdated, but mostly accurate) here: https://make.wordpress.org/core/handbook/project-organization/.

        Report


  2. are they even listening what the WordPress community thinks? I don’t think so

    Report


  3. How can I have access to the slack links ?

    Report


  4. Props to the core team for sticking to its guns here. The customizer is just a better experience for end users. The devs will come around. Change is always going to have its critics.

    Report


    1. Well said.. don’t listen to the community and people making a living or dedicating a huge parts of their lives on software that they care about. I’m sure they’re just raising concerns because they fear change or don’t understand what their users REALLY need. Silly developers!

      Report


    2. Props to the team that quickly approved the merger despite the overwhelming negative feedback? I’m all for sticking to your guns. But in this case the negative feedback was overwhelming in nature. It seems odd to me that it was approved so quickly given the uproar.

      I agree that the Customizer COULD be a better experience. But right now it is not.

      Fragmenting even more of the admin between the traditional Dashboard and the Customizer UI is flat out poor user interface design. It’s inconsistent and makes WordPress look like a frankenstein of a solution.

      A Customizer style UI, and I say customizer style because the “Customizer” is slowly becoming not just the customizer but the admin, can most certainly work. But not as it behaves right now. It has it’s own issues.

      WordPress needs to decide if the way the Customizer does things is the future of the WordPress admin as a whole, or not. If it is NOT then the Customizer needs to stick to just addressing theme style customizations. If it IS then a major overhaul needs to take place that rolls out the customizer style UI as the defacto admin for WordPress as a whole… and roll it out all at once. NOT piecemeal with a little piece of functionality as a whole, splitting things up between the old Dashboard and the new Customizer.

      The issue isn’t the style UI used by the Customizer. Squarespace has proven that this approach to admin UI can most definitely work. But Squarespace’s implementation is FAR more elegant and well done than the customizer UI in WordPress right now.

      I do think that WordPress should move towards that style UI for the entire admin. But I do NOT think it should be done a little piece at a time which just makes WordPress admin look like a mess and will do nothing but confuse users… the vast majority of whom are EXTREMELY non-technical and have difficulty doing even the most basic of tasks.

      I think it needs to go all in, work on overhauling the entire admin into a customizer UI style interface the way Squarespace has and then roll it out as a major feature release after working with the development community, as well as a major campaign to prepare users for such a change.

      WordPress needs to shit or get off the pot when it comes to the customizer UI.

      Report


  5. Last time Windows messed with the Start Menu citing “user research results”… Fast forward, they apologize to users and putting it back… who knows how many millions they lost in sales…

    Report


  6. It’s quite interesting that the approval was even though a lot of people objected to it. Doesn’t the community have a say in the matter?

    I don’t think anybody objected to the integration because the main reason was education. Yes, there is a major need for education and everyone has been making an effort to do so. But, the biggest proposal out there is to get rid of the existing Menu creation system, which makes absolutely no sense because you’re taking a well working system, stuffing it into an already crowded box and saying that it’s the best thing that happened!

    It’s already irritating that Admin navbar links for Themes points to the Customizer when you already have a link to the Customizer via Customize so adding new themes or switching themes from the earlier interface is more clicks.

    What’s the next step? Moving General options there as well?

    Report


  7. Wow, things are looking pretty bleak in WordPress land. If WordPress was a government, it would be tightening up national security in fear of a Civil War.

    Or to put it another way. There may be a WordPress fork coming soon if the decision makers at The WordPress Foundation don’t start addressing the developers concerns in a sincere and honest way.

    I really hope things don’t come to that, but it’s starting to look that way.

    Report


  8. This WP.org behavior can have positive effect – people will be so unsatisfied, they will create new joint project on Github (perhaps backed with Kickstarter campaign) to replace the current admin interface or parts of it.

    This way WP Admin will be just another fronted for the WP Core engine, it also opens opportunities for strong commercial products.

    Report


    1. Maybe Movable Type will make a comeback (which I honestly preferred over WP long ago). But, it’s interesting to see what goes around comes around. Back then Movable Type messed up with their licensing fiasco which turned people to WordPress. Now it could end up being WordPress’s turn.

      Report


    2. We have to remember, there is no such thing as “TOO BIG TO FAIL”…

      Report


    3. This WP.org behavior can have positive effect – people will be so unsatisfied, they will create new joint project on Github (perhaps backed with Kickstarter campaign) to replace the current admin interface or parts of it.

      This way WP Admin will be just another fronted for the WP Core engine, it also opens opportunities for strong commercial products.

      Core getting matured to be there actually. Once the WP-REST-API delivered the baseline properly, anyone can build their ‘Admin Panels’ as they see fit.

      Looking into 2016, guess there will be many awesome custom-made Admin panels, if not sooner! :)

      Report


  9. I just published my thoughts on this.

    My issues have nothing to do with disliking a Customizer style approach to the admin. It also has nothing to do with disliking change. WordPress HAS to change.

    My thoughts are too long to fit in a comment and Jeff always says WPTavern comments are like my blog… so I decided to actually publish a blog post that outlines what the WordPress team is doing wrong with this change.

    WordPress is making the same mistakes Microsoft did with Windows 8. More here:

    http://carlhancock.com/wordpress-is-making-the-same-mistakes-microsoft-did-with-windows-8/

    Report


  10. As I mentioned in a related post….

    I am extremely disappointed where WordPress is taking the customizer because it appears they are moving everything from the admin dashboard and squeezing it into the customizer. It should strictly be used for “theme options” only, and it was my assumption that it was to replace third party theme option panels. Right now, we have the Title and Tagline, Background, Header, Nav, and Widgets mixed in with theme options, and it’s just getting bogged down and more complicated that will frustrate users.

    Report


  11. Why are WordPress taking all my tools away and making me use a Leatherman for every job?

    Report


  12. The more you need to be educated in how to interact with a certain UI, the more it means that said UI is unintuitive.

    I am all in for WordPress moving forward, of course, and live editing in the frontend is clearly the way to go. But the Customizer, as it is today, is not the solution. Why do we need to cram everything into a sidebar that does not change size whether I use a small laptop or a big monitor? And why use the sidebar at all; interacting directly with the content, in this case the navigation, would be far more intuitive.
    I hope that is the future for the Customizer, but in that case, its current state seems like a unnecessary step, almost like an obstacle.

    Also, more generally, when you introduce a new feature that is criticized by the majority, it is a really bad idea to force them to use it (by removing another feature), just for the sake to be able to say: “see, everyone uses it!”. Like really, really bad idea.

    Report


  13. So I take it that the core team repudiates Nick Halsey’s comments. Glad to hear it.

    In which case, what’s your justification for going ahead with this?

    Report


    1. Please do not assign further meaning to my comment. I simply asked for clarification on what was meant by “the core team”, as I think we can each understand that people do not enjoy having comments or intention misattributed to them.

      Report


      1. You asked for us to “be mindful.” I’m happy to oblige if you and “the core team” take your own advice. Unfortunately, I haven’t seen much evidence of that lately — and certainly not on this issue.

        Report


  14. Interesting situation. When we had previous issue with the customizer (options frameworks, etc.), community was told that it was not active enough in expressing its opinions in the beginning. Now me have very active community, but it looks that community leaders completely disregard community voice.

    What conclusions should we make from it? What is the point to express opinions? Just to vent out?

    Interesting how it is done in Drupal or other communities?

    Report


    1. Found this on internet: “Mambo was the world’s most popular CMS. At one time it was estimated that over 40% of the world’s internet sites were powered by Mambo. Strange but true.”

      History gives good lessons.

      Report


      1. at which point some of the core developers emerged from Mambo to create Joomla (which is what I use) due to indifference of decisions being made. Mambo eventually collapsed. Movable Type had the license fiasco (as one put it) from SixApart’s crazy decisions at which point WordPress was starting and took over when MT lost so many dedicated users and then eventually also ended its reign as blogging king.

        Report


    2. As I already asked at the beginning of this “discussion”:

      If WordPress is all about “democratize publishing through Open Source”, then why does it feel that the core dev team is more and more a totalitarian regime?

      Report


      1. Because they seem to equate world (web) domination with democratization. So having millions of blogs designed on a phone will be fine with them, even if it means giving up on the idea that WordPress could be a real CMS.

        Report


  15. I think the consensus is clear that what the customizer makes possible is a huge leap forward. It’s hard to mold out a new UI without encountering difficulties.

    Some of the strengths of the dedicated areas in the Admin are not showing up in the customizer, like the ability to add a lot of help text to explain settings for example.

    Right now depending on the theme you use, the customizer panel will have different sections, so there’s not a lot of consistency on a site to site basis. Everytime it will be a mix of the default sections WordPress adds in and the ones being added in by plugins and themes.

    I think bundling more and more settings into the customizer maybe is pointing out something that would even more sense…

    Instead of making the customizer a destination, make it a mode that can uniquely enhance every admin settings page.

    Being able to bring up the customizer from anywhere in the admin UI, with only contextual controls showing up instead of the whole kitchen sink. The widget customizer screen already does a great job of this.

    So if you’re composing a post, you could go in customizer mode and interact with a real live preview.

    If you’re in the menu screen, you could get a real live preview of the menu as you modify things.

    If you’re adding widgets, you can jump into the customizer mode straight from the widgets page, instead of navigating to the customizer.

    If you’re changing layouts for your theme, you’d go there from a theme settings area.

    But each time, the controls that show up are purely related to the task at hand.

    Right now I use the customizer all the time for setting theme layout/colors/font and adding widgets. Other settings areas like setting the Site title and tagline are set and forget. There’s no reason I’d need to see in the menu on every visit.

    Report


    1. I think this is an awesome idea.

      Report


    2. This is super kickass.

      Report


  16. Just one more sign of the “beginning of the end” when the developer team of a widely used piece of software discounts the misgivings of the end users (people like us) by saying we just don’t understand things…blaming a lack of education or whatever…in other words they know everything and we just don’t get it. WordPress guys…you’re heading for a crash.

    Report


  17. Not sure I think it’s a good idea. Have been working with WordPress for more than 10 years, building a hundred sites or so. Know my way around WordPress. But this Customizer thing is one of the weirdest UIs/UX I’ve ever seen/experienced. It just doesn’t fit the rest of the wp admin, it feels so wrong to switch to a completely different UI.

    Report


  18. I have my worries about this change. This isn’t the first time that a drastic change has been proposed in WordPress and won’t be the last. One thing I do know is that I often speak up too soon before a feature is really finished. Sometimes, I absolutely hate a change at first but come to love it after using it for a bit.

    I’d like to see a more polished version of this before sharing my thoughts. I last checked a couple of days ago and had issues using the plugin.

    Report


    1. A polished version still doesn’t address my major concern with this change. The issue is the ongoing fragmentation of the admin UI. Soon you’ll be doing half the things in the Customizer and half in the old Dashboard. That is a terrible UI and UX decision.

      Report


      1. I actually consider your concerns valid. If and when I have something to add to the discussion of them, I’ll reply directly to your other comments or your blog post on the subject.

        Report


  19. I very much like the Customizer but I still prefer the backend Menu system. I don’t see why as a user we can’t just be able to choose whether to use the frontend or backend. There are far too many 3rd party integration with the Appearance -> Menus screen that will likely never be ported to work with the customizer or not make sense in this context any more.

    If they decide to take away choice because of a “you’re just a user and we know better” attitude, then that’s the first version of WP I won’t upgrade to until there’s a plugin that adds the old Appearance -> Menus screen back / links and all.

    I’m all for democratizing WordPress, removing the existing Menus screen seems more like a move toward a WP dictatorship. Don’t remove choice from the equation. It’s mistakes like this which will cause WP to fall from it’s current lofty pedestal IMO.

    Report


  20. This is very bad. I work in a large company, we have several installations where wp is the backend and frontend is an iOS app or a decoupled web application. I believe that this approach will become more common as wp-api getting better.
    Pushing more settings and content editing to the Customizer (requiring a traditional theme) will block this development and move wp to a big monolith, when the rest of the world needs smart, decoupled api based microservices. Simply wrong direction.

    Report


    1. That’s a very good point.

      I have no real for/against opinion that is strong enough to warrant me coming out with a definite view as yet, but I think your point about using WordPress as a backend to a web application (which is one of the big talking points about the forthcoming REST API) is going to problematic if certain areas of the admin are only editable via the Customizer which would require a front end theme.

      The is no harm in integrating Menu Management into the Customizer as an alternative way of managing menus visually, but all ‘content’ (including menus) must be manageable via the admin so that the admin can be used in isolation without a theme if WordPress is able to say that it a suitable application framework?

      Report


  21. Well said but where does that community really get to make it’s voice heard? Where do the silent majority get to to go and make their contribution and voice heard?

    Report


  22. Its apparent that this guy believes he is smarter than all of us who use WordPress to make a living. How sweet that he thinks we need “more education” when we are the people who know that Customizer is not what we need. It sucks. It is a styler–to add the hundreds of dimensions we need it will be a monster that is ttally unworkable. What Team Theme wants to do is make everyone use 2013, 2014, 2015–and that’s not going to happen.

    I am particularly furious right now because I just paid for a year of WordPress hosting on Siteground and have several sites on another host that I just renewed. Now all that money is down the drain, because once this goes into effect I am leaving WordPress for good. There are other fish in the sea.

    This is the epitome of corporate arrogance. Next they’ll be telling us what to write.

    Report


  23. WordPress is shockingly distancing themselves from the people who uses their product. Customer is and should be the “true reality”.

    Report


    1. IMO, WordPress is a open source software and has no customer.

      How do you define customer ?

      Additionally, are these ‘customers’ voicing their opinions in https://make.wordpress.org/ ?

      Just my 2 cents …

      Report


      1. Anyone that uses a CMS is a customer, that is, a potential WordPress user. Therefore, changes have to be carefully made, criticism has to be carefully taken in consideration.

        In this case, obviously it hasn’t.

        You certainly aren’t expecting every new user to be voicing his opinion in https://make.wordpress.org/, are you?

        It would be more logical to publicly present this kind of changes before forcing it to core, like it’s being done now, against many opinions.

        Report


  24. Has this Menu-to-Customizer move been thoroughly tested, for instance, with multilingual WordPress installations? What about complex navigation systems, like we often see in WordPress themes? Were there real people testing it? How many? For how long?

    I’m very disappointed by this move, this “let’s just ignore criticism and call it resistance or education issue” IS NOT the WordPress Community way.

    I know WordPress is all for “decisions not options”, but that applies to stuff that doesn’t work. So I’m expecting this guys, who’re clear making a huge mistake and are ignoring a large portion of active users, take a step back and, at least, keep the Menus screen alive and let common mortals use WordPress as theirs, not the UI team’s.

    Report


  25. I do not want to design my site on a small sidebar; I want to design it on a dedicated page.

    Report


  26. This whole conversation makes me more excited for when the WP API becomes stable and official :)

    Report


    1. You know I hadn’t commented on this topic until now, because I didn’t quite know what to think of it. The WordPress Core itself (and its developers) seem to be going through some MAJOR changes that seem to be taking place without any sort of central direction behind it.

      At any rate, your comment about the upcoming new WP REST API might be the driving force behind all these changes. I’m wondering if the WordPress Core might eventually end up becoming nothing but a Tiny lean-and-mean-base, with all other components completely Modular.

      Report


  27. I don’t believe we need the customizer at all. Like many others in the community, I never use it. With thousands of WordPress sites under my management for myself and clients, I never use that screen.

    In my opinion the customizer is a horrible UI and worse UX. The entire thing seems completely useless to me. I do not want it, I do not want the features I access in other places to be moved into it. Please stop this.

    Report


  28. Moving core menu items to the customizer would be a good idea IF the results in the customizer were better than what we have now. I think most people would agree that the customizer experience with widgets is a huge step backwards from the existing functionality. For me, it’s so significant that I make extra clicks to AVOID getting the customizer version of widgets because everything I do there will take longer and won’t be as well done as in the existing widget area.

    This really appears to be a case of a lead designer who is incredibly attached to a product, and it looking for a way to use it, even if it’s a truly bad application. The customizer isn’t even a really great way to customize themes, it’s only saving grace is being somewhat standard. Yet most themes tend to have their own setup and options areas, as the customizer perhaps is a little too restrictive or time consuming to program to.

    This is really an area I wish WordPress as a whole would just stop and take a step back, and really think about it before they burden everyone with a poor UI and UX, one that makes this more complex, less standard (because themes can too easily change it), and more likely to create confusion especially with more basic users. It’s also likely to frustrate experienced users by making everything they do slower.

    I honestly wonder if someone at WordPress is just trying to make this as complex and diffcult to master as Drupal or Joomla.

    Report


  29. I believe this direction is leading towards detaching the whole Appearance menu from the Dashboard and ultimately becoming the Customizer. It somehow gives us the restriction in the future indeed but freedom can be chaotic and limiting in some ways. Now, dashboard can be a place of turmoil or pandemonium.

    Customizer can be the baseline as to how developers/users should manage to add options to site’s layout and style.

    Dashboard has to change. Even if this powerful thing we love so much is an open source – it should conforms to some sort of collaborated guidelines.

    Report


  30. I’ve only been using WP for about 5 years now, but I’ve been in the computer field for several decades. In its’ present form, Customizer is nothing more than a distraction. It should NOT be merged into core yet. It isn’t ready. Customizer should be completely REMOVED from core and be made into a plugin. Let those that want to use it, use it. In the mean time, the developer can continue to refine the appearance and capabilities. Once it reaches a critical mass of users of a million-plus users, then, and only then, consider merging it into core. At that point, it should have become a truly viable product.

    And what is this crap in Customizer disabling the browser enlarge/reduce function? PLEASE! Even way back in Visual Basic 3 we would resize elements based on the window size. This is a basic piece of interface design that is completely ignored in Customizer.

    Last, but certainly not least, please stop designing interfaces solely for use on cell phones. A valid interface should adjust to the device. Otherwise, we would all drop back to a 14-inch monitor (or smaller) and call it day.

    Report


    1. In which browser is an enlarge/reduce function disabled, and what function do you mean, exactly?

      Report


      1. I use Firefox. When I have the Customizer screen open, the Control-Plus and Control-Minus keystrokes do not work to enlarge or reduce the font size on the screen. Everything stays the same. This is the only place where I have the problem when working on a site.

        Report


      2. That (Ctr+/-/0) works here after I click one time, somewhere. Looks like a focus bug, and should be reported.

        Report

Comments are closed.