Cancel

Sarah Gooding

Filter to Disable the Customizer Shot Down on WordPress Trac

photo credit: shutoff - (license)
photo credit: shutoff – (license)

WordPress 4.3 will introduce menu management via the customizer, providing live previews on the frontend for adding, deleting, and ordering menu items. Although users still have the option to manage menus using the admin interface, developers who are not keen on the feature are searching for an easy way to disable the customizer and remove its links throughout WordPress.

In certain scenarios involving client work, the customizer can be more trouble than it’s worth and may not be a beneficial addition to a custom-tailored WordPress admin.

Gabe Shackle, an application developer and UI engineer at Risdall, created a ticket on WordPress trac last week, requesting a filter to disable the customizer. His patch offers developers an easy way to enable the ‘no-customizer-support’ class within the body tag.

Due to the fact that the ‘customizer-support’ class is added via JavaScript on page render, it cannot be manipulated using any core filters or actions currently.

By setting the filter value to false, the Customizer is essentially hidden from the admin and the links that were currently pointing at the Customizer (widgets, themes, etc…) are reverted to their previous dashboard destinations.

Currently, developers who want to disable the customizer have to employ a combination of different methods in order to effectively remove everything that the customizer introduces into the admin.

“This filter makes this process into a simple boolean filter so that developers who do not want or need the Customizer can easily remove it,” Shackle said.

WordPress lead developer Dion Hulse replied to the ticket to say that although he doesn’t use the customizer much himself, he doesn’t think that WordPress users would benefit from an easy way to turn it off.

Personally as much as I don’t use the customizer a lot of the time, I think offering a filter to disable it is probably not in the best interests of WordPress users.

The customizer, as much as some dislike it, is a major component of the future of WordPress UX – whether that is a good or bad thing remains to be seen by some – but like it or hate it, it’s here.

Hulse suggested, as an alternative, that a better way to disable it would be to remove the customize capability from the roles.

Shackle further explained that he was attempting to follow the precedent of the admin bar, which he considers to be a similar type of UX component.

“The Admin Bar can be disabled not only by a filter but by a global variable, core function, and user profile setting,” he said. “The Customizer has none of these options.”

Nick Halsey, the developer of the Menu Customizer plugin that is being merged into 4.3, replied based on assumptions about why Shackle might request a filter to disable the feature:

I have yet to see a valid reason for something like this. In most cases, concerns about not wanting users to have access to the Customizer stem from the fact that you’re not giving them the appropriate capabilities. And the customize capability can be used to turn off the Customizer if you really must.

While you can remove the customize meta capability (or re-map it or whatever), doing so simply because you don’t want to train users or don’t want to use the Customizer is doing yourself and your users an enormous disservice. As dd32 mentioned, the Customizer will only continue to grow in importance within WordPress. Additionally, user testing has shown that the Customizer experience is generally easier for users to grasp than the admin, which largely stems from the value of having live-previewing available. We’re putting a significant amount of time into the Customizer every release to continue improving it, conducting frequent user tests along the way to optimize usability.

Halsey promptly closed the ticket following this exchange. I followed up with Shackle to find out why the proposed alternative to remove the customize capability is inadequate for his purposes.

“Mostly I was hoping that the Customizer could be treated more like the admin bar, which has 3+ methods for disabling it,” Shackle said. “Having a clearly labeled filter is, in my opinion, more legible than modifying user capabilities. A PHP developer with virtually no WordPress knowledge could most likely understand much quicker what’s happening with a filter named ‘enable_customizer_support’ rather than ‘map_meta_cap’.”

Obviously, not all tickets and patches will be considered valid by the maintainers of WordPress core components, but Shackle was disappointed by the defensive response to the discussion.

“Honestly, had the reply simply been something along the lines of ‘You should just use the customize capability to achieve the same effect’ I really wouldn’t have had any issue,” he said.

“Unfortunately, it seems any approach other than ‘Customizer for all things!’ means I get to be told multiple times how much of a disservice I’m doing my clients and what a lazy developer I am for not just re-training my clients how to manage their sites’ appearance.

“It feels like the Customizer team themselves have an all-or-nothing approach to the project and that anyone who questions this is wrong, regardless of their reasoning,” Shackle said.

This exchange demonstrates that since core contributors view the customizer as a major part of the future of WordPress, this is one feature where there will be little willingness to support efforts to make it more modular. Disabling support for the customizer will continue to require use of ‘map_meta_cap,’ the same method the creators of the Customizer Remove All Parts plugin have employed.

Category: ,
Tags:
61

61 responses to “Filter to Disable the Customizer Shot Down on WordPress Trac”

  1. call me crazy, but i think maybe the idea here is that the customizer may at some point evolve to the point where it truly is a front end editor for all roles. maybe it wouldn’t even be called customizer at that point but ya.

  2. I’m starting to see how at least some core developers are becoming so arrogant and refusing to really listen to users. As one person mentioned not too long ago that perhaps it’s time to fork WordPress into something new and better.

    • I can’t say I’m surprised about how polarizing the issue of community feedback and the Customizer has become. I think it has to do with a fundamental misunderstanding of how and why core decision-making happens.

      Part of the confusion I think lies in the difference between need vs want. Core decision-making happens based on what the perceived needs would be for 80 percent of the user base – many of whom just want to publish content in an easy way and don’t care about the nuts and bolts.

      So it’s not that the core team isn’t listening, it’s that the feedback they’re getting much of the time often isn’t 1) constructive or informed, 2) keeping with future development in mind, and/or 3) what would be considered useful for that 80 percent of users.

      In the case of this ticket, the author proposed a solution without really outlining the problem. And that’s nothing against the author, but in a world where we’re developing software used by nearly a quarter of the internet, problems should be defined before solutions whenever possible.

      In this case, the problem is: “I don’t want my users to see the Customizer because it’s too complicated/slow/confusing.”

      Core developers responded in-kind to the problem with the best future-proof solution currently available: capabilities. We know how capabilities work now, and likely how they’ll work in the future. This is an important distinction to make.

      Due to the backward-compatible nature of how WordPress is developed, the core team has to consider not just how something will work for core, but also how it will be extended by others (like theme and plugin developers) now and in perpetuity. Adding a filter in this context means that the filter must be supported in perpetuity.

      And if you consider the vision for the Customizer posted on the core development blog a few weeks ago, the time for consolidation of the legacy Appearance screens isn’t now, but we need to consider that someday it might be.

      All of the above is to say, boiling down the response to “the core team isn’t listening, let’s fork WordPress” is to drastically oversimplify what’s going on. It also isn’t particularly constructive.

      • @Drew Jaynes,

        Actually, Drew, you have just exemplified how much the core team isn’t listening.

        The problem isn’t that those objecting to the Customizer don’t have vision. The problem is that the core team think they have a monopoly of vision. Apparently, you also think you have a monopoly on deciding what feedback counts as constructive. You’re wrong on both counts.

        You might get to decide what goes into core. But that’s all you get to decide. You don’t get to say what counts as vision or feedback.

        So how about actually listening instead of attempting to define the issue out of existence?

        You see, many of us have a vision too. As a writer, not a developer, I don’t feel qualified to talk about the Trac ticket. But I do have a vision for how I want to be able to adjust how things look on my site. Quite literally, in fact: I use a large, widescreen monitor so that I can see everything clearly. That way I need only do something once. But you want to squish me into a tiny, narrow area wwith clunky functionality where I really can’t see what I’m doing. That’s literally a lack of vision.

        And please don’t attempt to justify the Customizer with talk of what it might become. If it’s going to be so great, then develop it as a plugin until it’s ready to wow us all. Until then, it’s just another thing I have to turn off.

        In fact, here’s my real vision. How about a WordPress where core isn’t so peculiar that I have to ensure that, before I start using a theme, I have to remove or disable over twenty different things?

        As I said, I’m a writer, not a developer. Yet the core team’s vision is so strange that I currently have to check over a theme’s code before I know I can use it.

        That’s the problem with thinking you have a monopoly of vision. It can often turn out that you’re really suffering from myopia.

        • The problem is that the core team think they have a monopoly of vision.

          It takes a community to innovate, and WordPress is indicative of that. One of the key purposes of having lead developers is so they can define the vision for the future of the project – and they have. That involves making decisions that weigh the perceived needs of the many with the few.

          It’s true that of late there have been a few instances of contributors lacking tact in how they address feedback, but I don’t think it is fair to characterize the entire core team as arrogant as being shut off from the community – a community, mind you, that we’re all members of. Concerns are not going unheard, in fact, many of them are already shared by active contributors.

          I think a lot of the vitriol we’re seeing of late stems from a feeling of disempowerment, and of being ignored, something I think we can all work harder at addressing. This isn’t a power struggle, the point is that there is a process for how core decision-making happens, and getting actively involved in that process is the way to affect change. Armchair criticism and hyperbole are one thing, action is another.

          Write a blog post. Write a plugin. Build a movement behind your ideas and help the project innovate through the community at large.

          And please don’t attempt to justify the Customizer with talk of what it might become. If it’s going to be so great, then develop it as a plugin until it’s ready to wow us all.

          As usual, context is important. If the Customizer were to be proposed today it would absolutely be developed as a feature plugin. Larger features going into the Customizer have all been conceived as feature plugins themselves, namely, Widgets, Menus, and the theme switcher. Of course, the problem we have is that that the Customizer itself was introduced before the feature plugin development process was conceived. So the next best option is to continue to iterate and make what we have better with the resources at our disposal, which I think is largely the message that the project leadership is sending.

          WordPress is never going to be all things to all people, and that’s OK. In my opinion, the best possible things we can do are try to make WordPress as simple and robust as possible, while allowing for flexible extension. I think that’s what we’re constantly striving for, but in a community of volunteers, change doesn’t happen overnight.

          • @Drew,

            This was funny: “Write a blog post. Write a plugin. Build a movement behind your ideas and help the project innovate through the community at large.”

            But I doubt you meant it to be. You see, I was one of the first to criticize the Customizer. I was even told at one point on WP Tavern that only I and one other person objected to it. There now does seem to be a movement. You just don’t like its direction.

        • How about a WordPress where core isn’t so peculiar that I have to ensure that, before I start using a theme, I have to remove or disable over twenty different things?

          Hi! What 20 things are you disabling, exactly? Why are you disabling them? Without this basic information, we cannot have any sort of meaningful discussion about how we can improve them, or why they might be bad for your particular use-case.

          There’s many things we all don’t like. Putting our voices out there and explaining our problems is step 1. You say you’re a writer. Can you write about it for us?

          • @Otto,

            Eddie Machado already has most of them covered in his Bones starter theme. You can download it from here: http://themble.com/bones/

            You can see his list, together with the code, in the /library/bones.php file.

          • @KTS915 None of what that theme is doing there has anything to do with the Customizer, and, in addition, would not be accepted for a theme listed in the theme directory.

          • @Otto,

            Do you have a thing with straw men?

            “None of what that theme is doing there has anything to do with the Customizer”

            So it’s just as well that I never said it did. I was simply pointing out that the Customizer was yet another thing that I have to turn off.

            “[T]hat theme … would not be accepted for a theme listed in the theme directory.”

            Again, I didn’t say it would be.

  3. I think this is being blown out of proportion. As others explained, it can be disabled and capabilities is a much, much better way to do it than a filter. While admittedly modifying capabilities is not as easy as a filter, it’s the more correct way of doing it. I meant think about it — the request is “I don’t want user X to be able to do Y” (in this case Y being “use the customizer”) and that’s exactly what capabilities are for, controlling what users can do!

      • We are working on a sister plugin to Remove All that give options. Lots of options. One thing I noticed as we were developing the first plugin is they did a really good job not making Customizer bloat the admin if you’re not on that page. The buttons and links are only a query or two and don’t load much.

        Removing it for performance is thus a waste, so its removal is purely for keeping users out of it and for people who never, ever use it to not be bothered by its additions to the dashboard.

    • Totally agree with Alex Mills. They are doing storm in glass of water. If you have 3+ options to solve everything related to UX and capabilities will dull the code. Each thing in its place and each place for its thing.

  4. If you think that your clients need to be “trained” to use the customizer, then a better approach is to address the issues directly by explaining the problems they have and what they don’t understand about it.

    Fundamentally, the customizer is a change-thing-see-result type of interface, so if there’s something your clients don’t get, explaining what that is will get you further. A straight “turn-it-off-because-i-dont-like-it” will get exactly that sort of response. As well it should. You didn’t identify a problem, and didn’t suggest a solution. Problem first, solution second.

    • Otto, I think there are plenty more questions at play here. The idea of turning it off is more about making sure that your clients continue to see the same interface they have always used, without the need to go back and re-train them for a new (and still evolving) interface. After all, shouldn’t the look and feel of the admin be something that can be reasonable configured without too many forces?

      Moreover, every time the admin interface is changed dramatically, it makes all existing tutorials and information meaningless. If you are working from tutorial information to teach clients how to operate in the wordpress world, it’s really a whole lot harder if the target keeps moving on a very regular basis.

      Finally, it would be much, much better if the customizer was always an advancement. As an example, I feel that the customizer for sidebar widgets is a pretty big step backwards, slower to use, and way less intuitive. Forcing it as the default on the admin bar is just frustrating for those of us who are use to and work efficiently with the existing widget admin area. It just adds more clicks, and worse yet, I suspect at some point the straight forward widget admin will disappear as part of an “improvement” program, slowing my workflow further.

      When things move forward, we are suppose to advance. The idea of “it’s not a problem, it’s just the fact that you’re not giving them the appropriate capabilities” is perhaps the most arrogant statement possible.

  5. This issue is starting to wear me out, and I might have a Puppy Dog brain hemorrhage.

    Let the Core Developers finish what they’re doing and then Plugin Developers who want to, can create their own plugins to disable Customizer it to their hearts content. Those who want to use them WILL, those that don’t want to WON’T.

    I’d just like to see WordPress Version 4.3 completed.

  6. While I don’t have strong opinions one way or the other about the customizer filter, the constant arrogance/rudeness (e.g. essentially calling this dev lazy) being thrown by Nick Halsey is really getting to be something. Unfortunately, it will really make me think twice before I open another Trac ticket to report a bug – especially if it is related to the customizer in any way shape or form. I try to avoid getting my efforts stomped and and my head chewed off by people as much as I can. That sucks because I know some of the core team are working so hard to make Trac more accessible and friendly to outsiders.

    • Unfortunately, it will really make me think twice before I open another Trac ticket to report a bug – especially if it is related to the customizer in any way shape or form. I try to avoid getting my efforts stomped and my head chewed off by people as much as I can.

      +1

      I stopped opening new tickets long time ago for this very reason. I don’t like being looked down on, thanks.

    • I wouldn’t expect this to happen with WordPress. I feel shame, really, and, if I had the chance, I would ask this people working on the Customizer to take a deep breath, move a few steps back and think twice about what they’re doing and what they’re saying.

      “Doing so [disabling the Customizer] simply because you don’t want to train users or don’t want to use the Customizer is doing yourself and your users an enormous disservice.”

      WTH? Who’s this guy to interpret whatever reason a person has? This kind of response shouldn’t be anywhere near the trac or the core devs. This has to stop.

    • If you ever feel unable to contribute to WordPress on any particular ticket or topic (like the Customizer) because of how another contributor is acting, please ping me privately. I’m easily reachable as @sam on the WordPress Slack or sam@wordpress.org via email.

      The above is true for absolutely anyone on absolutely any topic. It doesn’t need to be core-related.

      You’re right that the core team has made great strides to make trac a welcoming place for all contributors. When things hinder that progress, we need to address them.

      • People really shouldn’t need to contact anyone at this point. Nick’s responses over the last few months have been childish, dismissive, and generally insulting. Nothing has happened, no one in core has spoken up about it, and nothing is being done about his conduct.

      • It’s good to hear there is a reporting system in place for this type of behaviour. I wasn’t previously aware of that – thanks for your efforts!

  7. I believe the reply from “Nick Halsey,” is very childish and immature. He takes the suggestion as criticism and is completely ignoring the excellent suggestion. As if he does not want his ‘menu idea’ to be able to be turned off a more elegant way or even turned off at all.

    Personally i believe the complete customizer should be flushed down the drain as it is utterly slow and very unpleasant to work with. The option fields in the sidebar are way to small to contain any good explainative helptext, but after each setting waiting on the refresh…. pfff I rather do it the old way, save the settings and in the next tab refresh my page.

    But having the menu’s in there? Sorry its a absurd and idiot idea that should have never gotten into the customizer. It seems that the WordPress team is going to make the same mistakes like microsoft did with removing the startbutton in windows 8.

    I never thought I would say this but I am started looking at Joomla and Drupal as since version 3.7 of WP their cms system is becoming slower and slower on each update making the joy of using it disappear rapidly.

    • is any software or UI/UX concept ever perfect especially in it’s early iterations? should we let our past paradigms define our future? what if i told told you i wanted to make plugin which completely disabled the wp admin interface, not replace, mind you, disable. would you still hold this position?

      if we try to put ourselves in the shoes of a new user as opposed to someone who has already been accustomed to wp admin are these complaints still valid?

      just asking…

      • Funny you ask that. As i recently saw one theme designer releasing a new theme with the customizer integrated for his settings and not like he did before with a separate theme settings section in the admin area. And guess what. The first questions that popped up on his forum, not only from old previous theme users but also users who bought his theme for the first time, was about having separate theme settings, a bigger left customizer area, the freaking slowness of the customizer etc etc. Not a single positive comment on that.

        If you want to make a plugin that disables the complete admin area. Go ahead i don’t care as long as you dont impose it on me to use it. And that is exactly what WP is doing. Its not about what i am used to use or not. Had it worked properly i would have loved it.

        But the discussion here is about the idea somebody has for simplifying the ability of turning off the menu in the customizer. I dont have anything against that idea and anything making stuff easier to do i welcome. But what “Nick Halsey,” does with his reply is insulting and rude going by the actual easiness of the request and better solution then the role capability method. As if he is “egotripping” on getting his menu into the customizer which nobody should touch.

        As said if the customizer would have worked nicely and speedy. Welcome. Did you try the widgets? What a horrible way to add widgets in the customizer. I liked the way it was in before 3.7, That was speedy and handy.

        The whole customizer is a irritating slow crappy visual way of applying settings to the front of your website. As many i hate it more and more.

      • is any software or UI/UX concept ever perfect especially in it’s early iterations? should we let our past paradigms define our future? what if i told told you i wanted to make plugin which completely disabled the wp admin interface, not replace, mind you, disable. would you still hold this position?

        Well the thing you are missing is that its not a concept anymore. It is fully integrated and has been for some time now. Without community feedback or public concept iterations etc. It was created in a 25 day codesprint.
        Also disabling the wp admin is something people want to do. Heck people want to be able to disable much of core as well.

          • @Neo i have and do agree the widgets customizer bothers me at this point i’d rather the admin bar did link to the backend widgets screen, but that doesn’t mean it can’t get better and be just as good as, if not better than the backend.

            I think my point about disabling admin is that it logically doesn’t make sense, what’s the point of having a CMS that doesn’t do anything, this front editing experience is coming like it or not if for no better reason than it needs to keep wordpress competitive with other platforms and services. Could it be better? Absolutely. Should we try to fight that or rather try to contribute to make it better and as Otto says identify and solve it’s problems? That’s the path i would tend to choose.

            Regarding the politics of the situation i can’t really speak to any of that but i do know that if we care about wordpress as an open sources project then we cannot allow our emotions positive or negative make our decisions for us we must keep the end users (especially new ones) and their experiences in focus. The scenario you gave actually isn’t a new user its one that already expects wp admin. I have seen several of these themes using the customizer for their options screen now and at first it is a bit startling but when integrated well i see a lot of benefit as well not least of which is a more consistent options editing experience from theme to theme.

            @Andrew being a UI/UX concept actually doesn’t have anything to do with it’s age imo wp admin is also a concept albeit one which is much more evolved than the customizer. Perhaps the language i used was too ambiguous. The question in my mind, again, is ultimately which is a more intuitive concept for those unfamiliar to learn? i don’t know about you guys but i have customers that i am still trying to hammer in the distinction between front and backend many years after the concept was first explained.

          • @ubernaut A concept need to materialize into something etc. The customizer is no longer a concept, it never really was a concept. Its a feature now, its not a feature concept. Featured plugins can be considered concepts of a sort but not when its actually in core.
            I dont think the Customizer helps with the idea of frontend and backen, it sort of adds a middleend =).

  8. The problem with the current approach to the Customizer is it is being forced down throats.
    Instead, I strongly suggest, the Customizer team adopt ASAP a sales/buy-in attitude.
    The Customizer needs to be so good and so useful that it will come to be that its adoption is universal to the point that removing other methods become like how removing the blogroll was a few years ago. This is a long-term challenge. Meanwhile, I suggest the TRT back off from its recent ultimatums. They have been counter-productive. The ability to admit to mistakes and move on is the measure of leadership.

  9. Can someone explain why on earth he said the following: ” but the customizer is hell in the agency world.”? Why would an agency specifically hate customizer that much?

    • Probably because it adds to the confusion. You have frontend, backend and now the Customizer which is backend but on the frontend but not fully. So you have frontend, backend and middlend =).
      The problem boils down to confusion for end user. I know people that have trouble differentiating between a post and a page.

  10. I’ve recently seen a couple of themes where the Customizer has been customized even further and although I have reservations about it I do think it’s very useful for the DIY’er and those without a lot of coding experience.

    From a developers point of view it is potentially dangerous in the hands of a client who is able to make site wide alterations without necessarily being aware of the consequences.

    At the very least there should be an easy way to save a ‘Default State’ protected by a password so changes can be easily fixed.

    I struggle to understand why the WordPress developers should get so defensive about a request to make it easy to hide. I realise we live in a world where everybody wants things easy but easy is not always faster.

    I believe WordPress has become as powerful as it is in large part because web developers make great use of it and very few of the developers I know use the customizer. If you know your way around WordPress it is far quicker to code changes or make use of existing menu/widget systems.

    Adding the Menu and Widget system to the Customizer is fine for those that need it but don’t take away the current methods.

    In my experience developers do not have a problem training clients in what they need to know to operate and update their website efficiently. It would take a lot of convincing for me to train them in the use of the Customizer as I know who they are going to call when their site falls apart :(

    There will be plugins developed to hide the Customizer, so all is good but it would be so much easier if the WordPress developers would take on board that the ability to hide it has benefits.

    • You can easily hook into the customizer and create a export import of its settings. I a developer that uses the customizer should provide that ability out of the box which would solve your problem of clients wrecking the looks of the website.

  11. In my opinion the dev team stopped listening to the voice of WordPress users. Unfortunatelly it looks like another symtom of the direction WP and Automattic is heading – turn “Democratize publishing” into an empty phrase.

    • … tens or hundreds of comments are not representative source from millions of WP users.
      WP is amazing tool what allows me to do amazing things. WP is there bc. these developers do what they do, not bc. me or anybody else post a comment.
      They do great job.

      • Yes, these “tens or hundreds of comments” from active and interested users/devs/trainers are indeed representative.

        Your comment is precisely what’s in discussion here: criticism from active and concerned users treated as “ignorance” or simply “resistance”.

        WordPress evolves by integrating concerns along with innovation and trends. I don’t remember the last time such a criticized change was integrated in a rush like this everything-in-the-customizer approach is.

        If it’s a so well thought and tested approach, why this kind of response to criticism? Why the rush?

  12. The real issue isn’t the Customizer. The real issue is that the WordPress Foundation and the core development team are outright dismissing anything non-core WordPress Developers have to say if it’s not to agree with them.

    WordPress hasn’t become this popular because they made a great CMS. The reason it’s this popular is because developers recognized that it’s a great CMS and sold their clients on WordPress. If they don’t start listening to the WordPress Development community that developer support will disappear, along with the WordPress dominance.

    • Couldn’t agree more. The Core DEV team has become insular and isolated from the rest of the community and that’s the way they prefer it. The interesting thing is that, with the exception of “personal blogs” to show off their skills, many of them don’t actually use WordPress for anything real world. So they reject anything that doesn’t make them look “cool” to the rest of their clique.

      • This notion is completely unfounded. Many core devs use WordPress in the real world every day, whether it’s through building WordPress.com, freelancing, or working with top agencies that serve clients all over the world.

        • In addition to the aforementioned consultant and WordPress.com folk, committers also work full time for The New Yorker Times, Conde Nast( New Yorker, WIRED, etc.) and Washington State University. Additionally, contributors come from multiple hosting companies, media sites like Fusion, governments.

  13. I’ve read through these comments and I have yet to find a legitimate reason for all the “Customizer hate”. So far the only criticism I have for the Customizer is what Neo mentioned, there needing to be an import/export settings function by default. But as he also mentioned that it’s fairly easy to create your own hook to save customizer states which is what I’ve done on various projects. Then there’s the “is_customize_preview()” function that can be leveraged on the preview screen itself.

    I would love for someone to write an in depth itemized article as to why the Customizer is the Devil, because so far I have nothing but kudos for the api. I understand it’s not perfect, and it will continue to grow but it’s far superior to most of these settings pages I’ve encountered in themes that look like one of those daunting computer control panels you’d see in a bad 1970s sci-fi flic.

    As far as clients are concerned, generally the first thing out of their mouths when they use the customizer for the first time is “oh cool, I can see changes in real time…”

    • At first, a couple of years ago, the customizer seemed a bit clumsy implemented, was slow and, most of all, very limited in power. But it worked as a demonstration of how to get instant preview of changes. The feature most absent, after the introduction of widgets management, was menu management. Now (upcoming 4.3), with this, and with partial updates, it feels a lot more mature.

      I really look forward to get rid of the big options pages, even if they will not disappear for plugins yet. Future will show if plugin developers will adopt the new API,

      With the exception of the new site icon setting, it’s possible for plugin authors to disable it without taking away functionality. And it’s easy to create an options page for site icons. It’s also easy for theme authors to offer a plugin to manage theme settings through an options page, as an alternative to using the customizer.

      Both lovers and haters of the customizer should be able to live happily together for years to come.

      • Why do you want to get rid of theme option pages? If it works for others, why do you care? It’s not like others using them is going to effect you one bit. Why tell other folks how to work?

        • there is something to be said for consistency in UX/UI. We should all care about improving the UX/UI for wordpress or it will stagnate and fall behind other platforms. This effects users more than anyone else do you feel the needs of developers outweigh the needs of users? Standards are valuable in any profession.

          • those are just your opinions, i think when its properly used the customize is more than capable when it comes to theme options. is it perfect certainly not but nothing is ever perfect for everyone, and the idea idea here is that it’s the future you are fighting against, at least in my opinion.

            :)

        • @mac2net Why are you saying this? Let others use the options pages, I don’t care, of course. Where did I advocate to forbid options pages? I can’t influence that and don’t want to. Why do I have to state the obvious for you to understand that I’m merely stating MY humble opinion on the matter? Am I constraining others because I say I like a feature?

          • I really look forward to get rid of the big options pages, even if they will not disappear for plugins yet. Future will show if plugin developers will adopt the new API…

  14. Honestly if all you want to do is “disable” it from your clients you can just hide (with a filter or with css) the link to the Customizer in the dashboard. Most clients won’t be savvy enough to browser there directly.

    • This is a fragile and backwards strategy.

      Imagine setting up security checks that will catch criminals wearing red hats only (because for some reason all criminals have worn red hats for 3 months now). Then one day the bad guys decide “let’s wear green hats now”. What happens to the security checks? Or what if cops decide to wear red hats too?

      Hiding stuff using CSS classes (and similar) is not the correct approach. The correct approach is a canonical and supported way to remove all the stuff with a filter or a global setting for instance.

      “Most clients” is not all clients. There are WP-savvy clients out there, who know exactly what is available and where.

You may also like

Newsletter

Subscribe Via Email

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

%d bloggers like this: