Cancel

Sarah Gooding

Proposed Customizer Improvements for WordPress 4.0 Land Amid Concerns Over Underlying Architectural Problems

photo credit: beccaplusmolly - cc
photo credit: beccaplusmolly – cc

When widgets were added to the customizer in 3.9, WordPress users were generally surprised and delighted. Live previews are so beneficial to the editing experience that contributors are starting to pursue an expansion of the role of the customizer into all aspects of WordPress.

Nick Halsey has been working extensively with the customizer as part of his Google Summer of Code project and recently published an update detailing the planned improvements for the upcoming 4.0 release. The Appearance trac component has now been renamed to Customize. Halsey’s clarifications of the terminology reveal where the project is heading in terms of prioritizing the customizer:

We’re shifting toward using ‘Customizer’ rather than ‘Theme Customizer’, as it isn’t necessarily theme-specific (though most of its uses currently are)…’Customize’ could refer to anything. That’s the point; it could be used to customize any part of a site. The Customizer can be used for anything, and we’d like to encourage more experimentation with different uses of the Customizer.

WordPress 4.0 will include a number of UI changes to the customizer along with a new Panels API that enables developers to group controls into sections.

panels-ui

The proposed customizer changes for 4.0 provide support for a wider array of controls and parameters to help developers extend it for more varied uses beyond themes. Contextual controls are also on the list of proposed changes, which allow the controls to be visible or hidden based on the page the user is viewing.

Is WordPress putting all its eggs in one basket with the customizer?

Improvements to the customizer are expanding on all fronts. WordPress developers will soon be able to use it in many more ways after this iteration is complete. But are we putting a lot of effort into rapidly expanding a feature that may not be able to evolve as the web changes?

Matt Wiebe, design Engineer at Automattic, recently wrote a piece, enumerating some of the most critical issues in evolving the customizer as it currently stands. His article highlights the difficulty of using the customizer on mobile devices, performance issues, a confusing UI and the fundamental limitations of its architecture:

It’s also a JS-driven app wrapped around a PHP-only public API, which is I guess about what you’d expect from an early WP foray into something JS-driven. But this fundamental PHP dependency makes it basically impossible to account for a seamless switching of state while changing a previewed theme: a full page reload has to happen.

Wiebe believes that some of the smaller issues he outlined can be addressed with core changes, but the underlying architectural issues may be impossible to address in a backwards-compatible manner. He is hopeful that eventually the customizer could make use of the upcoming WP API, though that would require a massive overhaul:

Also, looking forward, the Customizer itself should be a client app of WP-API. Everything related to site appearance should be an API call away, rather than the tightly coupled thing that is the Customizer. This will open the door for, say, a native Customizer on Android or iOS or some other platform that doesn’t exist yet but will be important.

The WP API is slated for inclusion in WordPress 4.1 which should arrive later this year. Meanwhile, development with the current customizer architecture charges forward.

Halsey briefly mentions a few of these issues in the conclusion of his proposal under the “future work” section. He cites tickets that recognize the customizer is not intuitive on mobile and needs some help in terms of performance. Customizer-related tickets tagged for a future release address a few of the issues that can be improved with core changes.

It’s easy to nitpick problems with a relatively new feature in WordPress that hasn’t had time to develop. Many contributors have put a great deal of hard work into all of the upcoming improvements to the customizer. But the question here is whether or not this feature, with its current architecture, is a dead end until it is completely refactored to be able to provide users on all devices a better and more seamless editing experience. Are we sweeping too many concerns under the rug for future work? Or will the customizer be able to evolve and find a path forward through the roadblocks?

Category:
Tags: ,
32

32 responses to “Proposed Customizer Improvements for WordPress 4.0 Land Amid Concerns Over Underlying Architectural Problems”

  1. My main concern in regards to WordPress architecture is the little amount of attention paid to backward compatibility. Yes there are great strides being made in the evolution of WordPress. But I have witnessed so many plugins fall into disuse because of compatibility issues. With every new version that rewrites core files, the dependability of WordPress suffers in the eyes of developers. If you are not a fortune 500 company with 6 figure programmers at your beck and call, you had better not depend on WordPress beyond it’s basic shell, no matter what your vision for your WordPress site. Add-on capabilities are transient at best.

    I am reminded of the IBM PC in it’s heyday. As long as they maintained a bus architecture that supported third party participation and development, it remained at the top of the market. But when they went to a proprietary architecture, they fell into disuse. Not saying that WordPress isn’t king. But the next thing that comes along that will adhere to a dependable (or at least predictable) standard and at least pays lip-service to backward compatibility for their plugin developers; that will be the day that WordPress will be displaced as the forerunner in this arena.

    There have been many upgrades as of late. But the trend has been towards lateral moves that supports WordPress.com as the next great cash cow; not forward moves that establish WordPress as the current and future king of content management interfaces. There will always be the next great thing. How the current or the next remains in that position is entirely dependent on its’ third-party developers. Lately, it has been very discouraging to be counted in that number.

    Create forum topic from comment

    • While great strides are made to keep WordPress backwards-compatible with the thousands of free plugins and themes out there, the onus of such a thing cannot be placed on the core WordPress developers alone.

      While a new major release is being prepared, there is often a month (sometimes more) during which it’s available to anyone for testing, that includes plugin and theme developers. If the developers of these plugins and themes aren’t interested in testing and correcting (if necessary) their plugins and themes up to a month before launch, that’s more of a reflection on themselves and their product than the core WordPress developers.

      To be fair, there could be many reasons why a plugin or theme developer chooses not to test or correct their product, but placing the onus for such backwards-compatibility on the core developers alone is unfair and not productive. It’s simply better for one developer to check their few plugins or themes than for the few core WordPress developers to check thousands of plugins or themes.

      Things change, and the good news is that the core WordPress developers have made it incredibly easy for plugin and theme developers to keep up with such changes.

      If you do find yourself with a suddenly incompatible plugin or theme after a major WordPress update, contact the plugin or theme’s developer, as chances are they just aren’t aware of the problem. If they can’t help you, search for an alternative. There are so many plugins available these days that there is bound to be at least one up-to-date alternative.

      Lastly, I just want to address that last bit of your comment. WordPress.com (a product of Automattic) and WordPress.org (the free and open source software we’re discussing, of course) are two entirely separate entities. While it is true that WordPress.com benefits from enhancements made to WordPress, absolutely nothing goes into WordPress simply to benefit WordPress.com. That would be like Microsoft adding a feature to Word just to benefit one book publisher, it’ll never happen. :)

      Create forum topic from comment

      • James, thank you for your well considered reply. I am sure that from your perspective, you are correct in your assessment – at least in part. There are several points that I willingly concede. Yes, there are a great number of free themes and plugins. Yes, new releases are made available for developers to scrutinize. Yes, the dot com and dot org are separate entities. And in truth, my comments may be a bit unfair on one level or another. I appreciate all the work that has gone into WordPress and I certainly do not begrudge anyone for trying to make a buck.

        You said, in regards to the compatibility issue, “…the onus of such a thing cannot be placed on the core WordPress developers alone.” Who then? Surely the ‘after-market’ developers have absolutely no control over this issue. They are not the tail wagging the dog. The core WordPress developers act and the theme and plugin crowd responds. Such is the nature of the relationship (excepting those core file developers that have their own theme and plugin efforts).

        I should mention that I am unaware of the efforts to make WordPress backward compatible. That is to be expected. I am a user, not a developer. I only know what my experiences and those of my associates convey to me. My barometer are the many themes and plugins that are broken with every automatic update. Another telltale sign are the numerous broken and unsupported plugins that remain available for download long after their associated websites have gone the way of the dodo bird and the developer no longer responds to emails or any other efforts at contact..

        Finally, you said, “There are so many plugins available these days that there is bound to be at least one up-to-date alternative.” An associate and I are volunteers. We are trying to put together a project for a charitable organization (read: no available budget). We are currently testing about ten different sites simultaneously. Having spent day after day – for months on end – doing nothing but evaluating plugins and themes that play nice with each other, I gotta tell you; from a user’s perspective, your optimism sounds like wishful thinking at it’s best or simply unsupported hyperbole on the other end of the spectrum. I CRINGE at every WP update. It usually means everything breaks and starting from scratch.

        I stand amazed at all the things that WP can do. It is a wonderful content management platform. But as it stands, WP is the worlds best blogging software. If a user’s vision exceeds those parameters, he better have a team of PHP programmers on retainer. I think that the core developers have a programmer’s perspective. Self hosting isn’t just for the deep pocketed or technically capable anymore.

        Thanks for lending an ear to the little guy.

        Create forum topic from comment

        • I’ve been doing this for 10 years, well before WordPress even had plugins, so it’s definitely not “wishful thinking at it’s best or simply unsupported hyperbole.” ;)

          Who would I place the onus on? The plugin and theme developers themselves. The core WordPress developers are already doing their best to keep things backwards-compatible, they provide complete transparency during development with the ability to test a month before the release, and WordPress has a huge and helpful support community for any developer (and user) who has run into trouble.

          The few core WordPress developers have done everything possible to ensure backwards-compatibility and to help the plugin and theme developers, short of testing all of the thousands of plugins and themes themselves (something which would undoubtedly drag WordPress development to a halt). It’s up to the plugin and theme developers themselves to pickup the torch the rest of the way.

          To be honest, I have yet to see a single WordPress upgrade in the 10 years I’ve been doing this where “everything breaks” necessitating “starting from scratch.” If that ever happens to you again, head over to the WordPress Support Forums. We’re a huge and helpful community, and we’ll do our best to get you back up and running, all for free. :)

          Create forum topic from comment

        • “It usually means everything breaks and starting from scratch.” – Wow, I don’t know who you have working for you but this is very unusual from my experience. You can always prepare for updates by staging them on a development site while they’re still in beta.

          Create forum topic from comment

        • What plugins/themes have you been using? I’ve been using WordPress for nearly 10 years now and have never had a site break when WP updated because of a plugin/theme. I haven’t always been a developer either. There was a time when I was simply a user of the software, muddling my way through putting a site together.

          If something breaks on update, more times than not it wouldn’t be a backwards-compatible issue when it comes to WordPress. It’s probably more of a problem of poor code. That comes down to education for developers, which I think WP is making great strides with on a number of fronts.

          Create forum topic from comment

        • I’m a plugin developer and I run a business based entirely around several large scale plugins that in turn are used to power thousands upon thousands of other peoples entire businesses. My entire business’s revenue (and the revenue of many of my customers), which is, to be frank, not small, depends on these plugins working on top of WordPress. Over the six years that I’ve been operating my plugins-based business, WordPress core has not broken my plugins in a significant manner even once.

          I can think of perhaps 4 examples where WordPress core made a change that I needed to account for, but that’s it. Of these 4 examples, most were exceptionally minor and were quite simple to take care of before they even became a problem.

          WordPress core gets blamed for things breaking far too often. The vast majority of the time when something breaks, it’s due to a negligent plugin or theme developer, not WordPress core.

          If WordPress core didn’t care about backwards compatibility and constantly broke things, there’s no way I (and many many others) could run my business on top of WordPress. I have no concerns whatsoever with the core WP developers making breaking changes that significantly impact my business.

          Create forum topic from comment

    • Plugins will fall into disuse if their developers stop working on it. This has absolutely zero to do with how well WP scores on backwards compatibility. Third party code just needs to be maintained and the truth is with tens of thousands of plugins this isn’t always going to be the case. The majority of update issues are dealing with the reality that 3rd party developers are not maintaining their code in time with major WP updates, not because it has been made impossible or hard. For end-users the answer is to financially support the plugins they use and to test major updates first, especially if their site is a business site.

      If changes are made that are hard to overcome or require entire rewrites then perhaps you could rmake a case that backwards compatibility has become an issue. Have you got some concrete examples of that? I can’t really think of one earth shattering update that has been a net-negative. Keep in mind most 3rd party developers want the API to get more powerful, quicker.

      Create forum topic from comment

    • In my experience WordPress is excellent at maintaining backwards compatibility.

      It’s the theme and plugin developers that neglect their themes and plugins that are to blame for any issues you may encounter with plugins or themes when a new version of WordPress is released.

      I’m coming at this from the perspective of running a company that produces one of the most popular commercial WordPress plugins there is. WordPress does an excellent job of changing things in such a way that backwards compatibility is maintained. Almost to a fault in some cases.

      There are situations, major updates to jQuery for instance, that most definitely will require plugin and theme updates. But this is completely unavoidable and it’s exactly why theme and plugin developers must maintain the themes and plugins they make publicly available.

      WordPress development isn’t done in private. What they plan on doing is publicly known. It also goes through a long beta process and release candidate process before being publicly released. This is when plugin and theme developers need to be testing their themes and plugins to ensure they function properly with the new release.

      If you have plugins and themes that are constantly breaking when WordPress releases an update then you should probably revisit which plugins and themes you are using. It sounds like they aren’t being maintained properly by their developers.

      Create forum topic from comment

  2. Gotta agree with the above comments, there expectations of back-testing for thousands and thousands of free plug-ins, many of which have been all but abandoned by the original developers, can’t be dropped at the feet of one small group. If you build it, maintain it, and test ahead of time. A better customer experience is everyone’s responsibility.

    Create forum topic from comment

  3. James Huff – “The core WordPress developers are already doing their best to keep things backwards-compatible, they provide complete transparency during development with the ability to test a month before the release, and WordPress has a huge and helpful support community for any developer (and user) who has run into trouble.”

    Sarah Gooding – “Wow, I don’t know who you have working for you but this is very unusual from my experience. You can always prepare for updates by staging them on a development site while they’re still in beta.”

    Justin – “If something breaks on update, more times than not it wouldn’t be a backwards-compatible issue when it comes to WordPress. It’s probably more of a problem of poor code. That comes down to education for developers, which I think WP is making great strides with on a number of fronts.”

    Peter Knight – “Plugins will fall into disuse if their developers stop working on it. This has absolutely zero to do with how well WP scores on backwards compatibility. Third party code just needs to be maintained…”

    Jason “WordPress” Kiles – “Gotta agree with the above comments, there expectations of back-testing for thousands and thousands of free plug-ins, many of which have been all but abandoned by the original developers, can’t be dropped at the feet of one small group.”

    Wow indeed! James, et al. Do you guys not even hear yourselves? We are having a MAJOR disconnect over a definition of terms. It seems that all of you have confused ‘backward compatibility’ with ‘developmental transparency’. It’s not the same thing. Never has been. Not even close. In case you have forgotten:
    (http://en.wikipedia.org/wiki/Backward_compatibility) “In telecommunications and computing, a product or technology is backward or downward compatible if it can work with input generated by an older product or technology.[1] If products designed for the new standard can receive, read, view or play older standards or formats, then the product is said to be backward-compatible; examples of such a standard include data formats and communication protocols. Modifications to a system that do not allow backward compatibility are sometimes called “breaking changes.”

    Sarah – When you say, “I don’t know who you have working for …”; Is that the standard that you expect for a WP user?; that they are employed as a PHP programmer? I find that quite telling and indicative of the bias that I have been trying to illustrate.

    Justin – You said, “…education for developers…” So what do you think the difference is between users and developers? You have made my point for me.

    Peter Knight – “Plugins will fall into disuse if their developers stop working on it.” Again, thanks for making my point about ‘backward compatibility’.

    Jason “WordPress” Kiles – “…many of which have been all but abandoned by the original developers, can’t be dropped at the feet of one small group.” Developers again. OK. You do realize that my original comments was about ‘backward compatibility’ and ‘users’ – not developers. And yes, this falls squarely in the purview of the WP core file developers.

    Like I said, WP is the king of content management platforms. It’s a great system. But with WP updates, things “break”. For all you developers out there, no big deal. You have a ‘window’ in which to see where your code will break and the opportunity to fix it.

    It seems that most of you guys are intimately familiar with WP. Many of you are familiar with HTML5, CS3, PHP, JS, etc., right? Well I know a little about standards and compatibility (related field). The WP ‘team’ may be working on backward compatibility, but I’ve got a bulletin for you. They aren’t there yet. Again, not even close.

    QUESTION: If WP is backward compatible, why provide the opportunity to test theme and plugin code – and the opportunity to fix it with every update? Why do themes and plugins need to be ‘constantly maintained’?

    ANSWER: If WP is backward compatible, you don’t need to test and they don’t have to be maintained at every update.

    Your perspective is skewed. The simple truth is that the normal DIY ‘user’ that installs WP through their web host will not be familiar with PHP or anything else related to ‘development’. Should they find a plugin or theme upon which they build their vision, many will end up being disappointed. Something will break. There are even odds that they will not find a suitable replacement. Their WP ‘experience’ will suffer as a result. That is the point I was trying to make. Is that really so hard to understand?

    Create forum topic from comment

    • You seem to have a rather sizable axe to grind with WordPress, fueled by many assumptions and hyperbole.

      I’m not going to address any of the comments directed at me, because that seems like a waste of my time at this point, but I would like to point out that I’m not a developer myself, I’m a 10-year user of WordPress directly involved in many aspects of the community. The developers here who replied to you also started our as users at one point, and many of the core WordPress developers started as users and built their development education on the back of WordPress.

      To answer your question above, PHP and MySQL (the backbones of WordPress) are constantly evolving, and so is WordPress. Unlike your definition of backwards-compatibility, there are no “older standards or formats” to “receive, read, view or play,” just interoperable code by way of PHP, MySQL, Javascript, and APIs, and those are all constantly evolving.

      This is web development, and unlike software development, to evolve is to survive. Just ask b2 where it is now. :) You’ve probably never heard of it, because it stopped evolving over 10 years ago until others picked up the torch, began upgrading it to current standards and expectations at the time, and called it WordPress.

      Code has to evolve, it’s not about reading or writing a format, it’s about interoperability. Trust me, even if WordPress were 100% of what you feel backwards-compatibility should be, you should never use a 4-year-old untouched plugin. Chances are, it won’t even operate under the current version of PHP, much less WordPress.

      This evolution is why the focus is on developer education and assistance. If developers want to monitor development, they can. If they want to test their product with a new WordPress version before a release, they can. If they need help making their product compatible, it’s only an email away. And, if they choose to abandon their product, it is very likely that it will take several versions for anything of note to break in it (I use one in particular which hasn’t been touch for 2 years), and by then there will be plenty of alternatives (there are currently about 5 for the one I mentioned).

      Remember, everyone is doing this for free, they are all volunteers, that includes the core WordPress developers as much as it does the free plugin and theme developers. The only people actually profiting from this for sure are those who charge for their plugins and themes outright. Thus, the load has to be shared amongst all involved. The core WordPress developers do their best to keep things backwards-compatible, they provide education and help where that isn’t sufficient, and it’s up to the plugin and theme developers to do the rest.

      Anyway, if you’re still reading: Like we have all mentioned, we have never actually seen a major release of WordPress where “everything breaks” necessitating “starting from scratch.” It’s not because they’re all developers (again, I’m not), it’s because we are actively involved in the entire community, including supporting other users. So, if that ever happens to you again, head over to the WordPress Support Forums. We’re a huge and helpful community, and we’ll do our best to get you back up and running, all for free. :)

      Create forum topic from comment

      • Phillip, what you are asking can only be fully true for a company that has created software and its “plugins” themselves. Or for a company that is “officially” supporting a specific plugin from development company X.

        If WP made an upgrade and their own WP plugins were not compatible then there is a major problem.

        If a plugin made by Joe Developer is not compatible and WP has done everything to extend help (beta access, documentation, email or forum support) there nothing else they can do. the onus is on the developer.

        WP could remove all hooks therefore not allowing developers to extend their framework and create a closed environment. Outside of that being a watchdog for every plugin is not possible.

        This is just basis of software development.

        One thing to remember (free aint always free). WP is doing users a great service (and disservice to a degree)…for free. Your expectations are pretty high for free software. It seems WP is providing pretty good support with their core software… again for FREE. But if you are expecting more from them and a particular plugin developer, you should pay for software that also have a paid support model that matches your expectations.

        Create forum topic from comment

    • Phillip I think the disconnect can be put a little differently. You have drawn a conclusion that updates to WordPress core are not done with enough care toward backward compatibility.

      I think the problem is expectation management. It is a nuisance when a site is updated and one or more things don’t work. Everybody can agree on that. But this is highly dependent on the plugins you use and how your theme is coded. And even when update issues occur they are almost always overcome. This doesn’t take away the fact that 3rd party code sometimes runs behind and that sites need to be maintained and maintenance sometimes requires work and diligence. All of that can been seen as a burden, especially if your expectations are different.

      But, let’s say you are correct in pinpointing the cause of your frustration. To make that observation – that WordPress itself evolves in ways that are lacking toward backward compatibility – you would have to be actually familiar with the code yourself and all the work and care that core developers put into it, just to make that particular diagnosis. It might sound offputting, but you’d need to be pretty familiar with the innerworkings of core development to really make such an acute diagnosis. I don’t think that’s the case here. I think it would be more helpful to focus on articulating the frustration you have so people can give better feedback on it, instead of complimenting it with a self-made diagnosis.

      It needs to be said that it is completely unrealistic for WP Core to evolve – something all developers clamour for – and also guarantee that 3rd party code (which varies in quality) is going to work in every single case.

      You can avoid all manner of update issues if you run a heavily customized site by adopting a better update policy: test updates on a staging server, have a system to rollback updates, let another party manage the particulars, pick plugins that are well maintained, support the plugins you use or rein in the amount of custom code running in your projects which reduces the maintenance upkeep costs.

      Create forum topic from comment

  4. Mea Culpa. I see in my first comment I said ‘…in the eyes of developers’ where I meant ‘users’. I suppose some of this disconnect is my fault. But the tendency of most of you to equate backward compatibility with developmental transparency is pretty clear in your responses. My answer remains the same. Two different animals.

    Thanks for taking the time to listen.

    Create forum topic from comment

  5. After several years of Working with WP and was quite happy with what I had going on several web sites, I upgraded to 3.9 and found that a couple of plugins were misbehaving and/or nonfunctioning.
    Haha!
    I was forced to use my brain and find a work-around. No problem. (Thinking is a good thing, right?)
    The new WP is very responsive and there are a lot of young, brilliant minds developing Themes and Plugins that are quite wonderful.
    Many of my older Plugins were built years ago and the authors of those had long abandoned their updates.
    I applaud everyone on the WP Team as well as those of us who embrace it! It’s not perfect but it’s beautiful!

    Create forum topic from comment

      • There is standardization. But standards aren’t static. They evolve and change over time. It’s software, not a physical product.

        The perfect example to illustrate this is jQuery. WordPress makes extensive use of jQuery and properly developed themes and plugins also use the jQuery library that is bundled with WordPress core.

        As WordPress evolves so does jQuery and the version of jQuery that is bundled with WordPress is updated to make sure it’s running the latest. This sometimes does necessitate changes to themes and plugins to maintain compatibility with the new version of jQuery.

        If you use GOOD plugins and a GOOD theme this shouldn’t be a problem. The developers of quality themes and plugins will be on top of it and release the necessary updates to maintain compatibility.

        If your plugins or theme breaks because WordPress updated then instead of blaming WordPress you should take a long hard look at the plugins and themes you are using. There are thousands of them and they can’t be policed by the WordPress core team, nor can their quality and maintenance be policed by the WordPress core team. You have to use reputable plugins and themes that are actively being maintained.

        WordPress, WordPress themes and WordPress plugins are NOT static. They are constantly evolving. As WordPress evolves so do the themes and plugins that run on WordPress.

        It isn’t a “set it and forget it” platform. You have to keep plugins and themes updated just like you need to keep WordPress updated.

        Use good themes and plugins and this issue won’t arise.

        Create forum topic from comment

  6. While I love this discussion, the first comment kind of hijacked this post. I am really wondering what y’all think about the original topic at hand regarding the customizer’s architecture- can it evolve from where it’s at or will it have to be totally overhauled in the very near future?

    Create forum topic from comment

    • I’m really excited about the new customizer, but at the same time I am a bit neutral with how I think its future will develop. On one hand, it certainly seems to be far more extensible, and if I know the folks behind it like I think I know them, it can be extended to be even more extensible (for lack of a better phrase). On the other hand, every great thing is totally overhauled eventually and always winds up being even better.

      So, can it evolve today? Via awesome extensibility, of course! Will it have to be totally overhauled in the future? Such is the fate of all things, but it’s a good fate. :)

      Create forum topic from comment

      • That may be a good fate, but it seems sort of crazy to keep putting features and enhancements into something that down the road, will be a real pain in the rear to overhaul and cause more pain and grief then, than if it were done now. We have Matt Wiebe on WordPress Weekly this Friday so I hope I can figure out why it’s beneficial to not overhaul the thing now instead of waiting so long.

        Create forum topic from comment

        • Awesome, I look forward to hearing it.

          At the end of it all, I trust the developers’ approach, it hasn’t destroyed us yet. The way I see it, if they’ll need to overhaul everything they’re working on now, they’ll probably be the ones to overhaul it anyway, so they know what they’re doing. :)

          Create forum topic from comment

          • Definitely with you on that line of thought. Curiosity has the best of me with this subject. WordPress has always been great with backwards compatibility but that appears to be one of the sticking points with the current architecture of the customizer.

            Create forum topic from comment

        • While it unfortunately started with the headline, these two comments are textbook examples of a false dichotomy.

          Even if backwards compatibility were a sticking point (and I don’t think it is), that’s not a justification to not make an existing feature better. It’s not going to be any more painful today to overhaul the customizer than it will be three years from now. Believing this is a bad assumption.

          The customizer is incredibly well-designed from an architecture standpoint. It really is. It solved exactly the problem it was built to solve, and it does it really, truly well. It also did it to some fairly exacting design constraints. As a version 1, it needed to work perfectly with all themes out of the box. And to ease developers in, it needed to be primarily PHP-based. This was not our first modern foray into a JavaScript-heavy feature — for that, I’d go with distraction-free writing — but it was our first truly JavaScript-driven feature that developers would want and need to interact with. (This was before media, remember.)

          But it still has a powerful JavaScript API under the hood, and that’s an API that can only get stronger. A lot of the incremental improvements we’re working on are also pretty low-level in terms of making it faster and more flexible. We’ve looked at all sorts of other improvements, and I’m not sure I’ve seen a single one ruled out as impossible. Well-designed features are great because it’s easy to make major adjustments without a “clean break,” even though you can end up with all of the benefits of such a move.

          Create forum topic from comment

    • Sorry Sarah, forgive me. I had no idea I would set off the firestorm I did. Just to set the record straight, I don’t have an ax to grind, just a preference that I expressed.

      There was a lot of attention that Matt gave to the speed of the customizer due to the current architecture. I get that. To reach the level of optimization he would like to see, it is apparent that he believes a major rewrite is in order. I would have to agree.

      That said, how critical is speed to this process at this juncture? It isn’t part of the everyday experience of editing and publishing content, so I see it as a trade-off that is not time critical for most users. What do you think?

      Create forum topic from comment

      • Hey no worries, glad to hear your thoughts. Performance isn’t the only issue here. It’s also that the customizer is virtually impossible to use on mobile and it doesn’t (and possibly cannot) provide a truly seamless switching of state for the live previews. Both of those are even more critical than performance, in my opinion.

        Create forum topic from comment

        • Mobile is a completely different animal. Many things are going to be sacrificed on the altar of mobile until we figure out a way to shrink humans by 200-300 %. :D I see that as a non-starter. Mobile is inherently limited and we are going to have to learn to live with it.

          Seamless switching of state for live previews is desirable as a long-term goal, but are we ready to burn the house down and start over right now for the perceived benefits? Because that is what it would take. In any implementation I can envision, there would be a certain amount of robbing Peter to pay Paul on the performance side, no matter how the process is optimized. I wonder how that will play with the consuming public?

          Create forum topic from comment

    • I really appreciated reading Matt Wiebe’s post and the issues he highlighted, not because they identified fundamental problems with the Customizer but rather because they set forth key areas for improvement. Some of the issues weren’t even on my radar. But as I read the list, I could think of possible solutions for most of them. Many of the issues raised have already been logged in Trac with solutions to explore. Because of how well the Customizer is architected, as Nacin said, it provides an excellent foundation to iteratively build upon. Thanks, Matt, for shedding light on where the Customizer is falling short for users, so we can focus on these areas!

      Create forum topic from comment

    • I really enjoyed Matt Wiebe’s piece on the Customizer. I haven’t looked under the hood enough to comment on the architecture, but I trust Nacin when he says they’ve been looking long-term and don’t see any insurmountable issues. I also think the coming improvements to the Customizer are awesome and can’t wait for them to land.

      Aside from the technical considerations, I worry about the customizer-for-all-the-things approach. It doesn’t matter how well-designed the Customizer is or becomes, the more that is packed into it the more complex and confusing it will be for end users. As a niche theme developer, my themes have relatively few visual options but they’re bundled with plugins that bring more complex CMS-like data structures and functionality appropriate to my niche. I like how clean the Customizer is now for my users. However, at some point in the mid-future, as the Customizer becomes the de facto place for setting up your website, I think it will really get cluttered.

      I’m sure the development team will iterate when this pressure arises. But I do think that at some point down the road the front-end editing group and the customizer group will need to work together to come up with a common vision for how WordPress will be administered. The live editing feature is great. But I regularly run into situations where I really can’t decide where the best place to put an option or data component is. Where will a user expect to modify this component, a Settings API page or the Customizer? What’s easier for her to use? If I have a plugin, should I be splitting my settings between a Settings page (data inputs) and Customizer sections (appearance)?

      I understand that with iterative development on a large-scale project, it’s not always possible to have a crystal clear long-term view. But I’d love to hear more guidance on this division of responsibilities.

      Create forum topic from comment

  7. As Nacin said, the Customizer is very well-architected. The ease with which the improvements in 4.0 were made is an excellent example of this.

    I think we are overhauling the Customizer, from a developer’s and end-user’s perspective. But in core, we’re doing it itertatively; maintaining backwards compatibility because we can and should, and making changes bit-by-bit so that improvements get to users more quickly. In 4.0 we have improvements to the Customizer controls UI/UX, and several significant additions to the PHP API. For 4.1, 4.2 and beyond we’re already working on several things including a much-expanded JS API that would enable significant performance gains, alternative approaches to accessing the Customizer so that its role shifts to a squarely front-end context, the addition of custom menus to the Customizer (fixing numerous existing issues with menus in the process), a better experience on mobile (the Customizer is functional on mobile currently in Core and that fact should be made more obvious, although WordPress.com’s extended version isn’t), and, of course, improving speed/performance. I predict that we’ll have the entire appearance-customization aspect of WordPress integrated into the Customizer within the next year or so, including integrating themes, provided the community continues contributing work to the Customizer in core at a strong rate.

    In WordPress core, significantly backwards-incompatible changes simply aren’t an option because the developers do go to extreme measures to put users’ needs first. We take our philosophy seriously, and the majority of users’ problems are the result of plugins and themes ignoring the core philosophy or being otherwise poorly coded.

    There are many options for developers who aren’t satisfied with a WordPress core feature; big ones are to leverage WordPress’ extensibility to either expand the feature (like WordPress.com currently does with the Customizer) or replace it with a custom implementation of something better (like Automattic is experimenting with for their Customizer), or to help improve the feature in core. Core contributors are just regular developers; I barely consider myself a developer now and I’ve been contributing to core for over a year. You don’t need to do anything special to jump in; all help is appreciated, patches are welcome, and the more people we have contributing to the project, the more we can accomplish and the more we can improve WordPress for everyone. Even if you’re not a developer, anyone can help test features and work on improving the user interface and user experience.

    So rather than dwelling on issues with the Customizer, I’d love to see more people jump in and work on constantly evolving it through core’s iterative approach, and taking advantage of newer technologies like Backbone.js and APIs like WP-API as they become integrated into core over time.

    Create forum topic from comment

  9. The thing I like about the Customizer is how it brings standardization to the options being added by themes and plugins. It’s not just the way it keeps a consistent UI but also the registration of fields and extending them, which will be very successful long term.

    The things I don’t like are mostly related to a feeling of confinement and restriction. I don’t like the options being forced into such limited real estate and while that will probably evolve, it keeps me from wanting to use it. There are things that don’t belong in this interface and I’m afraid the more it gets extended into other areas of WP the more we will see those things in the Customizer. I actually think including widgets in the Customizer is great. I almost like that more than the theme options in some ways but I don’t love the existing widget interface and this seems like a much better one.

    I’m trying to keep an open mind about the Customizer and for my own work I have built the options to exist in the WP admin with an option to replicate any of them in the Customizer. This way we only put relevant fields into the interface and keep them available to users that prefer working in the admin also.

    Create forum topic from comment

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.