WordPress Passes 27% Market Share, Banks on Customizer for Continued Success

photo credit: Luis Llerena
photo credit: Luis Llerena

WordPress now powers 27.1% of all websites on the internet, up from 25% last year. While it may seem that WordPress is neatly adding 2% of the internet every year, its percentage increase fluctuates from year to year and the climb is getting more arduous with more weight to haul.

credit: w3techs.com
credit: w3techs.com

In January 2015, Mullenweg said the next goal for WordPress was to achieve 50% market share (the majority of websites) and he identified Jetpack as a key factor in preventing WordPress’ decline, a controversial statement delivered at Pressnomics. At that time Automattic was secretly working on Calypso, WordPress.com’s JavaScript-powered interface, but did not unveil the project until November 2015.

It’s difficult to say what effect Calypso has had on WordPress’ market share, as the w3tech’s 27% stat covers mostly self-hosted sites. Following up with him a year later, Mullenweg estimates that less than 10% of those sites are hosted on WordPress.com.

“It does look like about a quarter of it is using Jetpack, though, and that has grown since Calypso was released,” he said. “Remember – Calypso is for Jetpack sites as well as WP.com.”

In a recent interview on WPWeekly, Mullenweg said he is also optimistic that the WooCommerce acquisition and Automattic’s sale and management of the .blog domain extension will contribute “another 5-10% each to that market share.” In fact, there is a team inside Automattic called Team 51 that works on strategies for getting the market share to 51%.

“For getting to 51% and beyond – it’s more than just blogs and more than just websites,” Mullenweg said. “We need to do stores well, we need to do wikis well, we need to do real estate sites well, we need to do restaurants well – all these things that may be outside what you normally think of as a core WP experience.”

In order to provide the best content-creation experience on the market, in any niche, WordPress has some major work to do. The software is in imminent danger of being eclipsed by newer competitors if its core features don’t improve, especially when it comes to customizing a new site. Jetpack cannot single-handedly solve WordPress’ onboarding problem.

WordPress’ Weakest Link Is Also Its Greatest Opportunity

In the past Mullenweg has identified customization as the weakest link in WordPress but also one of its most important areas for improvement, saying, “The Customizer is everything.” During the 2015 State of the Word address he said, “Customization is the single biggest opportunity for improving the WordPress experience.” I asked him if he thinks the necessary improvements to make the software more competitive need to come from core itself or if commercial products could introduce game changers for the Customizer, the editor, and other problem areas of WordPress.

“I think to have an impact on WordPress’ growth improvements to customization have to happen in core or Calypso/Jetpack, otherwise there isn’t enough reach,” Mullenweg said. “It doesn’t matter how great a commercial product is – being behind a paywall will mean it won’t reach enough people to make a dent in WP’s growth curve.” He outlined how he sees the Customizer as a critical component of WordPress’ future:

I think the needed improvements will only come from a customizer and theme system which is flexible, intuitive, and instantaneous, which might also need to break backwards compatibility, and a post editor which leverages the same language, patterns, interface, and concepts. We need to use and adopt a React / Redux approach to the javascript, like Calypso, and rename or make irrelevant concepts like Menus which are just plain confusing to people.

Customizer improvements have been a focus throughout 2016 and the feature’s small team of contributors have made major strides towards improving the underlying architecture to build upon.

“It’s customization that is the key need here, not necessarily the existing ‘Customizer’ interface that we have today,” Customize component maintainer Weston Ruter said. “The key need WordPress has is to be able to live preview more functionality in WordPress, as Helen tweeted here:”

Selective refresh was added earlier this year in 4.5, giving WordPress the ability to preview elements without full page reloads. This is one way the Customize API addresses that “instantaneous” aspect Mullenweg outlined above.

“The Customize Posts plugin is an effort to rebuild the post editor from the ground up with live preview for all changes to post data and postmeta at the foundation,” Ruter said. “It’s a JavaScript-first approach to the post editing experience. No more waiting for a full page reload to save a draft. No more clicking a preview button to load the post in a new window. All of the changes are saved as drafts and previewed live. It’s reusing the TinyMCE editor component.”

WordPress may be looking at front-end editing powered by the Customizer in the not-too-distant future. Ruter and contributors are also working towards using the Customize API to power the next generation of widgets in core, which would use JS for UI and open the door for widgets to be managed via the REST API.

“Changesets, coming in 4.7, is the most far-reaching architectural improvement to the customizer since its inception,” Ruter said. “Changesets allow for live preview functionality to be de-coupled from the current Customizer interface. This architecture allows for live preview to be developed in other contexts, namely on the frontend and in REST API-driven apps and headless sites.” Ruter anticipates the REST API endpoints for managing changesets to come in 4.8.

The WP JS Widgets project shifts widgets away from their heavy reliance on PHP and creates a JavaScript foundation in the Customizer that allows for any library to be used to build widget controls.

“A control can actually be implemented using any JS technology stack,” Ruter said. “In the JS Widgets plugin I have a demonstration of widget controls in the customizer being built using the customizer Element, Backbone.js, and also React.” The plugin currently implements three core widgets and contributors are working on more.

“It’s somewhat of a ‘Widgets 3.0’ in core, focused on what they would look like in the Customizer first,” Ruter said, “where the widget instance data is stored in a setting, and the control listens to changes to that setting and updates its UI to reflect the changes in the underlying instance data.”

Although this particular project is being built to be JavaScript-library agnostic, Ruter said he thinks there would be value in exploring the use of React/Redux in a “Customizer 2.0” interface:

Taking the Customizer Beyond First Impressions

Ruter said he would have a difficult time proposing to build a client site that depended on the WordPress admin for site management and content authorship.

“A lot of the work we’ve done at XWP for the past few years has been building on the Customizer to provide the editorial experiences that I think are lacking in the WP admin,” Ruter said. “We invest heavily in the customizer because we see it as the best foundation that WordPress has to offer to provide the experiences we want to deliver to our clients.”

If the Customizer is so critical to WordPress’ success, it’s curious that the contributor team remains relatively small and few companies are investing in the feature specifically. XWP invests heavily in Customizer development and a great deal of that is prototype work in the form of feature plugins such as Customize Snapshots, Customize Posts, and several other plugin projects.

“I don’t know for sure why more developers across the WordPress community aren’t doing more with the customizer,” said Ruter, who is CTO at XWP. “It may be in part a perception problem, where it has seemingly been stuck with a negative reputation. Or it could be a technology problem, where the Customizer is vastly different from other areas of WordPress being a JavaScript single-page application.”

When the Customizer was first introduced it included support for ‘option’ and ‘theme_mod,’ followed by widgets and navigation menus a bit down the road. The WordPress community didn’t have a full understanding of the scope and capabilities of the Customizer for addressing some of the project’s chief concerns, including content authorship with live previews. Users simply saw a constrained UI they didn’t like using to customize themes. Most users had no concept of the Customizer providing the architectural underpinnings of other aspects of WordPress.

“Part of the problem is a lack of contributors,” Ruter said. “But even more than that, the biggest problem is one of having a shared vision. When the WP community throws hate on customizer improvements with each new release, it’s somewhat demotivating.

“If the community realized the vision behind and appreciated a full admin experience that had live preview and staging of changes, then that would make a huge difference,” Ruter said. He and contributors find it challenging to articulate the scope and they are considerably short-handed.

“It could be a problem with getting ramped up,” he said. “But that’s been the mandate for the WP community as a whole – to learn JavaScript deeply. I say, why not learn JavaScript deeply by building on the customizer?”

GoDaddy Plans to Invest in Core Customizer Improvements

GoDaddy is a surprising company to emerge over the past couple of years as another key player on WordPress’ road to 50% market share. WordPress product and service companies, along with hosts, are keenly interested in seeing the software continue its market dominance.

“It’s very important to GoDaddy that WP market share increases,” Gabe Mays, head of WordPress products at GoDaddy, said. “We’re deeply invested in the success of the WordPress community, not only because many of our customers use it, but also because of what it represents.”

Mays reports that approximately 1/3 of all GoDaddy sites and half of all new sites are running on WordPress. With millions of customers using the software, the company took the initiative to create a new onboarding experience specifically for WordPress customers. I asked Mays if GoDaddy is concerned about competitors like Wix and Weebly cutting into the WordPress market share.

“I don’t know if ‘worry’ is the right word, because 1) we know the problem and 2) we’re capable of addressing it,” Mays said. “As a community we either care enough to fix it or we don’t. There are negative consequences associated with the latter that pose an existential threat to the community.”

Mays has been involved with the WordPress community for the past 10 years and is working with GoDaddy to improve the new user experience.

“Part of the issue we’re experiencing now is that WordPress benefitted from such strong product market fit and, subsequently, such high growth that there weren’t the typical feedback mechanisms forcing us to make things like the UX better,” Mays said. “On the other hand, our competitors fought hard and iterated for every basis point of market share they have. We’re like that natural athlete that got to the top with natural talent, but now need to master the basics, get our form right, etc. to stay on top as the game changes.”

GoDaddy’s new onboarding experience is a stab at improving this UX and Mays said the company has significant WordPress core improvements in the works to provide a better first-use experience.

“I’m happy to say we’ll also be contributing these improvements back to core,” he said. “We’re happy to have had Aaron Campbell join us as our first core contributor earlier this year and we’re working on more ways to accelerate our core contribution efforts.”

Mays said GoDaddy is planning to submit core contributions to the Customizer and related core components in the near future but would not disclose any specifics at this time.

“Hosts benefit immensely from WordPress and as hosts we can collectively do a lot more to move WordPress forward,” Mays said. “We want to lead by example here and have big plans for this in 2017.”

WordPress product and service companies are also deeply invested in the software’s success and eager to see its market share grow. Cory Miller, CEO of iThemes, one of WordPress’ earliest theme companies, said growth is one potential sign of WordPress’ health.

“As WordPress has grown, so have we with it,” Miller said. “The opposite of growth is scary — it’s stagnation or decline. Many have predicted that in WordPress for a long time, but it continues to grow and push new limits, like the defiant teenager it is.”

Miller said one of his concerns with competitors in the space is that they have started to cut into the lower or lowest end of the market, “the do-it-yourselfers that many of us count as a key part of our customer base.”

“WordPress is fantastic, and so are all the innovative tools and services around it, from themes, plugins to hosting,” Miller said. “But I’m increasingly seeing the reason why many, on perhaps the bottom end of the market, say, ‘I don’t want to mess with updates, or worrying about security, or pulling 15 separate tools together to do what I need. I just want a simple website, I want everything in one bundle, mostly done for me, and so I’ll just go with SquareSpace or Weebly.'”

Although WordPress provides so much more in terms of community and extensibility when compared to Wix, Weebly, and Squarespace, getting started is the hardest part for new users. This is where tools like Jetpack and GoDaddy’s onboarding experience are useful for giving users what they need to succeed with WordPress.

Even with a strong background in HTML and CSS, customizing a WordPress site can be challenging. Your site will never feel like your home on the web if you struggle to customize it to suit your preferences. The good news is that the WordPress project lead, contributors, hosts, and product companies are working together to improve customization in different, complementary ways in order to ensure the future of the project in an increasingly competitive market.

86 Comments


  1. The customizer seems more suited just for theme options changes, than pushing menus, posts and other elements into the customizer.

    I really hope the customizer does not end up replacing the same features in the the WordPress admin.

    Report


    1. As the article says:

      It’s customization that is the key need here, not necessarily the existing ‘Customizer’ interface that we have today, … The key need WordPress has is to be able to live preview more functionality in WordPress

      A key need is to revisit the UX for the existing customization (live preview) interface and to look for other areas it can be added, such as inline editing on the frontend.

      Report


    2. To piggyback on this, the relationship between themes and content is an area where WordPress and the major site builder platforms (SquareSpace, Wix, etc) tend to thrive for their respective audiences.

      Being in the page builder space, we see a lot of folks struggle to grok the relationship between themes and content. Similar to how CSS decoupled style from HTML content, themes decouple style and structure from posts and pages.

      That said, WordPress is the better choice for sites that need to grow and adapt, whereas SquareSpace is well suited for the simple < 10 page, static/brochure style site. Many DIYers and businesses don't need or want to understand the relationship between content, structure, and style—they just need a website.

      It's hard to imagine a tool that can provide the flexibility that we as web pros desire, that also simplifies customization to the level that the web builder platforms do. Some of the friction might come from the idea of trying to make the customizer do "too much" without diminishing the vast flexibility of WordPress that we as web pros desire. Is it possible?

      I think Weston's comment touches on this, though, that a set of complementary tools and features, that have a familiar and intuitive UI/UX, could be a direction to look towards.

      Report


  2. there would be value in exploring the use of React/Redux in a “Customizer 2.0” interface

    I recall using React/Redux being described as yielding a 10x or 100x improvement for Calypso over the current WP Admin. This kind of improvement would not be the case for the customizer because it already implements a modern JS application architecture, with a state-managed UI and reusable components. Exploring a re-build of the underlying customizer UI in React/Redux would definitely be worthwhile, but it would be an incremental (2x) improvement not an exponential one (100x).

    Report


  3. If the community realized the vision behind and appreciated a full admin experience that had live preview and staging of changes, then that would make a huge difference

    To expound on this a bit more: the customizer architecture provides a radically different way of going about making changes to a site. In the traditional WP experience, you go into the admin, publish a post, it goes live, you then go to publish a page, then it goes live, and then you go add some widgets and nav menus, and they go live right away. The customizer provides the infrastructure to stage all of these changes together in a single changeset, one which can be previewed and iterated on, and then all of the changes can go live together. It’s really like bringing the staging environment into your production environment.

    In developer terms, changesets in WordPress are like what the stage is in Git: you add multiple changes to commit together. We’re also working on building on customizer changesets to be like Git branches, with conflict resolution between publishing changesets that have conflicting changes. This is being worked on in the Customize Snapshots plugin.

    The REST API, as important as it is, is still fundamentally very similar to the WP Admin in terms of what it can provide users for making their changes live. The REST API doesn’t provide facilities for previewing changes, staging, or batching changes together. Changesets, however, is designed to integrate with the REST API to make both of these things possible.

    Report


    1. When the Customizer was first introduced it included support for ‘option’ and ‘theme_mod,’ followed by widgets and navigation menus a bit down the road. The WordPress community didn’t have a full understanding of the scope and capabilities of the Customizer

      Aside from the small team of contributors, part of the reason for the slow progress for improving the customizer to be able to serve as a complete admin replacement is that it is fundamentally about ensuring all of the changes are staged and previewed. There should be no impact to your site when you make changes in the customizer until you hit Save & Publish.

      This ability to preview and stage changes, as I mentioned above, is a radically different architecture from WordPress in general. The closest WordPress offers outside the customizer is the flow of drafting and previewing a new post. In the customizer, however, this ability is extended to all changes. Because of this, there can be quite a bit of additional engineering required to introduce the management of new data types in the customizer: WordPress filters and actions have to be implemented to ensure that changes to a given object get injected into the preview without being written into the DB up front. This has been a major part of the effort behind the Customize Posts plugin, engineering the filters to WP_Query to ensure that changes to posts are reflected in the results. The same challenge was tackled for previewing changes to postmeta. The next customizer challenge I see as being previewing and staging the creation and modification of taxonomy terms. This in part depends on the introduction of a new term status API.

      Once all of the core datatypes in WordPress have the WP_Customize_Setting interfaces in place to model preview and stage changes, then I think we’ll be able to create a full admin experience on top of the customizer infrastructure (if not on top of the current “customizer”). The benefits we’ll get are many, including previewing, staging, batching, scheduling, and collaboratively iterating on any change to WordPress.

      Report


    2. I have been meaning to comment on Customize Snapshots in depth for a really long time, but each time I have seen it mentioned I had something higher priority, so I will just go ahead and put this out there.

      Snapshots is a great addition, but a big problem with the current Customize Snapshot implementation is that it is too tightly coupled to Customizer. To be a better component it should be able to be used via the REST API or via other subsystems. The naming alone indicates how tightly coupled it is; why not just call it Snapshots?

      Of course given how much you are advocating for the future WordPress interface to be Customizer I would ask if that high level of coupling was something you desired, or if it was simply happenstance?

      Report


      1. Snapshots is a great addition, but a big problem with the current Customize Snapshot implementation is that it is too tightly coupled to Customizer. To be a better component it should be able to be used via the REST API or via other subsystems. The naming alone indicates how tightly coupled it is; why not just call it Snapshots?

        Thanks, and by the way, the core feature is called “customize changesets” whereas the feature plugin where it was first developed (and where additional features are being prototyped) is called “Customize Snapshots”. Nevertheless, the “customize” part is in both, you’re right. The reason for it being tightly coupled to the Customize API is because it is in fact part of the Customize API. Changesets are just a way to store customized data, the values for settings that are registered with the customizer. It’s the Customize API that has the framework for modeling things (options, posts, terms, etc) in WordPress via the WP_Customize_Setting and its interface for getting a value, sanitizing a value, previewing a value, and updating a value.

        And customize changeset are indeed able to be used via the REST API. Given a REST API request, you can get the response back with the customizations applied for a given changeset by including the customize_changeset_uuid query parameter. The endpoints for creating new changesets are a priority for the next release, and they’ll allow you create new changesets entirely independently of the current “Customizer” app.

        Of course given how much you are advocating for the future WordPress interface to be Customizer I would ask if that high level of coupling was something you desired, or if it was simply happenstance?

        So yeah, the reason for calling it “customize changesets” is because it is part of the Customize API. The Customize API should be understood now to mean “interface for staging and previewing changes in WordPress”. It’s called “Customize” because that’s what it was originally called when the framework was first introduced in 3.4, so I expect it will continue to be called “customize” just as we still refer to objects as “posts” in WordPress for historical reasons. Maybe we can drop the “customize” prefix in the REST API calls and just refer to them as “changesets”. I’d welcome that.

        Good questions!

        Report


      2. Thanks, and by the way, the core feature is called “customize changesets” whereas the feature plugin where it was first developed (and where additional features are being prototyped) is called “Customize Snapshots”.

        My bad, I forgot which was the new name.

        Nevertheless, the “customize” part is in both, you’re right. The reason for it being tightly coupled to the Customize API is because it is in fact part of the Customize API. Changesets are just a way to store customized data, the values for settings that are registered with the customizer. It’s the Customize API that has the framework for modeling things (options, posts, terms, etc) in WordPress via the WP_Customize_Setting and its interface for getting a value, sanitizing a value, previewing a value, and updating a value.

        And that is the most worrying part, that they are too tightly coupled.

        What would be really good would be to validate that it it not too tightly coupled and implement the functionality in something completely unrelated to customizer like in ACF, Pods, or similar. My concerns when I reviewed the code was that it too tightly coupled to be used in any other way.

        BTW, where is the current codebase? I’d like to review it again but I have not been able to find it right now.

        Report


      3. @Mike:

        My concerns when I reviewed the code was that it too tightly coupled to be used in any other way.

        In the end you can create customize_changeset posts directly without interfacing with WP_Customize_Manager. Similarly, managing the posts will be possible via the REST API. But in the end, the logic for actually doing something with these changeset posts depends on the Customize API because they’re just storing the customized data that previously was only persistent in browser memory and POST data and then fed into the Customize API.

        BTW, where is the current codebase? I’d like to review it again but I have not been able to find it right now.

        You can refer to the patch on the ticket or to the diff on the pull request: https://github.com/xwp/wordpress-develop/pull/161/files

        Most of the changes are in class-wp-customize-manager.php.

        Report


  4. Yay the Customzier with full page rerendering per keypress when you enter text in widgets. Or inability to collapse parentmenus in the menu panel or ability to select parent menu to add items to etc. Flawed system for adding custom elements to the menu system and what not. (The whole menu system is a crap fest in WP so can’t really blame the Customizer for that. A total failure of a merge that was back in the day.)
    I’ve tried to get cumfortable with the Customizer but I just can’t. Some clients shy away from it as well and prefer to do things with the original widget and menu system. And these are folks that are new to WordPress.

    Report


    1. full page rerendering per keypress when you enter text in widgets.

      Eliminating the need to do a full page refresh when a widget changes is addressed by the selective refresh framework. It’s up to themes to support it, however. See Implementing Selective Refresh Support for Widgets.

      Flawed system for adding custom elements to the menu system and what not

      This is being worked on. In the customizer specifically, see https://core.trac.wordpress.org/ticket/18584#comment:82

      Report


      1. The thing is the theme maker should not have to care about the selective vs full page thing. And for example widgets by default should not trigger full page rerendering per keystroke if its an input text or textarea for example. That is just bad design. There are a lot of UI issues with the Customizer.

        Report


      2. The architecture decisions are based on maintaining backwards compatibility and maximizing cross-theme compatibility. This is why themes and widgets have to opt-in to to selective refresh. There are no limits to how a theme may be rendering a widget and no limits to what a widget may be rendering, so we cannot make any assumptions.

        Report


      3. You can make assumptions about not to render on each keystroke. How do you break backwardscompatibility on that? Oh my theme broke because when I write text in textarea it only rerenders after I have stopped typing.

        Report


  5. Contributors are really the key to evolving the customizer as a live preview framework in core, and to how quickly iterative improvements can be made. There’s been promising progress in the number of contributors to the customizer recently – 4.6 had 22 individuals receiving customize-specific props while 4.7 already has 60. If this growth continues, the next year could bring unprecedented progress.

    I would encourage companies interested in contributing to the core live preview experience to be as open in their processes as possible. Collaboration with others working on similar projects and core will help ensure that projects can merge into core much more seamlessly and follow core best practices from the start, to minimize reworking things. XWP has been doing a fantastic job with this, with their numerous experimental plugins developed openly on GitHub prior to being proposed for core.

    And for anyone concerned about a lack of customizer documentation for their projects, please take advantage of the 6000+ word official documentation page, https://developer.wordpress.org/themes/advanced-topics/customizer-api/, as well as the numerous make/core posts linked from there and the well-commented core code. There are some documentation gaps still, but the majority of the customizer is quite well-documented.

    Report


    1. Hi,

      First, I would like to thank you and @Weston for putting this amount of work into the Customizer. I love it, including the way it’s evolving. I use it in almost all of my projects to allow clients to customize their site without having to fear to break something or needing me for every small change.
      As @Nick mentioned, excellent documentation exists on WP.org that enables intermediate WP developers to use the Customizer features.

      However – using WP for almost 4 years and learning PHP and JavaScript – I still feel that I am missing the knowledge/skills to contribute to it. For me, it is hard to dig into the Customizer’s core, learning how it is built, how it ‘really’ functions under the hood. Of course, this is also true for a lot of WP features. But I think that some kind of in-depth tutorial explaining the core of the Customizer in WP (not the API, but the PHP and JS parts) could help people on-boarding and contributing to the project.

      Anyway, I don’t mean to give you even more work, so thanks again for all the great things! :-)

      Report


  6. Nick & Weston:

    I think one of the biggest impediments to working with the Customizer for myself (and I would guess for many others) is the lack of a Javascript-based hook system in WordPress. I think that is a prerequisite before you’ll get more traction from developers.

    FWIW.

    Report


    1. @Mike: The Customizer app does in fact have a JavaScript-based hook system. You can bind event handlers to most parts of the Customizer interface. You can listen to changes to the state, to changes in setting values, to addition/removal of controls, to messages being sent between the preview and the pane, to partials being rendered in the preview, and so on. You can get an idea of the events that are emitted throughout the app via the Customizer Dev Tools plugin.

      Report


  7. How did they manage to get 27℅?

    Did they poll EVERY website on the internet?

    Not every site will tell you if it’s using WordPress, Joomla, Drupal, etc…

    There are websites behind firewalls.

    There are websites that use ABC on the public area and XYZ for the private area.

    Report


  8. I will predict this now…sometime in the future, we will see user pushback (possibly the eventual collapse) of WordPress due to the insistance of adding too much into customizer (which should have been kept strictly for theme options). Then there is Godaddy getting involved.

    Report


  9. Customizer should have been a browser extension communicating via AJAX. Its limited space is a UX hell. It is basically impossible to find and understand settings in non trivial themes. The more developers will use it the less usable it will become.

    The code required to use it will either require a full page refresh on every key stroke, or will have to violate KISS and DRY.

    I actually think it is a better alternative to many things developers have done without it, and the ability to instant preview is priceless, but in the end the main problem is lack of definition what is the customizer supposed to be, which enables the push into it replacing the whole admin without anyone calling it as “out of bounds”.

    The problems start with the basic promise it make – reflect changes. The user is made to believe that what he sees is what he gets over the whole site, but even trivial things like menus can not be relied upon displaying the same on home page and post page and therefor customizing them in the home page is just not enough.

    Now this will get multiplied with changesets, if anyone will ever use them. You develop a changeset but from the time you have done it to the time you apply it some other very related option was changed that will render the whole changeset pointless. The worst scenario is of course when the changeset is only partially broken in a way which is hard to notice.

    Overall seems like it is not enough for the customizer to try to replace admin, now with changesets and the custom css it also tries to replace git. This is unlikely to end well especially with the strong bus effect on the customizer (is there anyone except for Nick and Westone that fully understand how the internals work?)

    I hope that before 4.8 starts, Nick and Weston will have a long soul searching session together to once and for all define what is the customizer. If the answer is “the future wordpress admin”, than before adding more things into it, work needs to be done to make the UX comparable to that of the admin.

    Report


    1. I agree totally. I’ve tried to understand the codebase of the Customizer but its a very confusing mess to me. I find it icky all the way.

      Report


    2. The code required to use it will either require a full page refresh on every key stroke, or will have to violate KISS and DRY.

      That’s not correct. This is specifically why selective refresh was introduced in 4.5 to keep the preview logic DRY and to eliminate the need full page refreshes. See post Selective Refresh in the Customizer on Make/Core.

      Report


      1. It is very annoying for core contributors always to respond to criticism with an attitude of “we know better/you don’t know what you are talking about” :(

        The selective refresh violates DRY for anything that requires a JS code, and shouldn’t everybody write JS instead of php now? If I need to write a special JS code to support selective refresh while the page is displayed in the context of the customizer then:
        1. I need to Repeat myself
        2. Many times it not totally Simple or not even possible
        3. It violates what the customizer should do. Instead of showing the page as it will be displayed it shows it as it will be displayed only in the customizer something the end user don’t care much about.

        Full page refresh is the KISS and DRY way, and the problem of it being so slow need to be fixed, and it should be triggered only when needed (user change the name of the site, he has a long text, why is there a need to refresh before he finishes typing it?).

        You can do selective refresh but it works well (ie without violating code architecture principals) only for very trivial cases, and AJAX request are in any case not much faster than full page rendering in wordpress.

        So again, it is not like the concept of the customizer is bad by itself, it is that there are architectural problems that are being ignored in favor of working on the next shiny thing.

        Report


      2. It is very annoying for core contributors always to respond to criticism with an attitude of “we know better/you don’t know what you are talking about” :(

        It’s not my intention to respond with a sense of superiority. If that’s how my comments read, then I am sorry. You’re asking good questions. But also understand that we spend countless hours architecting, discussing, debating, and engineering solutions such as selective refresh. So many of the questions you’re raising have already been considered and accounted for in the design.

        The selective refresh violates DRY for anything that requires a JS code, and shouldn’t everybody write JS instead of php now?

        Selective refresh is specifically designed to eliminate the need to write special JS in the vast majority of cases. Normally to register a new selective refresh area should should only have to do a single $wp_customize->selective_refresh->add_partial() call in a customize_register hook. The need to introduce additional JS to support the partial being selectively refreshed is needed only when JS is involved in the rendering of the partial.

        Full page refresh is the KISS and DRY way, and the problem of it being so slow need to be fixed, and it should be triggered only when needed (user change the name of the site, he has a long text, why is there a need to refresh before he finishes typing it?). […] it is that there are architectural problems that are being ignored in favor of working on the next shiny thing

        Selective refresh necessitated by WordPress’s PHP-centric rendering of templates. A slow refresh of the preview, while architecturally DRY and KISS, presents a horrible user experience. The only way we’ll be able to make a theme 100% DRY and KISS is if the theme is built using JavaScript, where changes to the customizer settings are synced into the corresponding JS models in the preview. A theme built using React would do well here in the customizer, and this is something that the changes in 4.7 are specifically designed to facilitate. I’ve also worked on a proof of concept that exposes REST API resources in the customizer and directly syncs changes into Backbone models in the preview: if changes to the models then trigger re-rendering of views (as they should) then this is also an example of a KISS/DRY selective refresh in the customizer. You can read more about this in my post Bridging the Customizer and the WP REST API.

        We’re also overdue to chat about selective refresh and JavaScript in #core-customize on WP Slack. Let’s try to do that this week. Cheers.

        Report


    3. The user is made to believe that what he sees is what he gets over the whole site, but even trivial things like menus can not be relied upon displaying the same on home page and post page and therefor customizing them in the home page is just not enough.

      You can preview any URL on your site, not just the homepage. You can navigate from the homepage to a category archive page to a singular post view, all within the customizer and all previewing how the changes (such as to menus) will appear in those contexts. If you are on the frontend and you click Customize in the admin bar, it is that frontend URL that is loaded in the initial preview, not the homepage.

      Report


      1. What a user can do and what he is likely to do are two hugely different things. Users have no information on what will be the global impact of a change.

        Please assume a plugin that changes the favicon for part of the site. Now when a user goes into changing the global favicon, what kind of indication he gets that this will not be a global replace? Obviously it is a hard problem to solve, but right now you just don’t know, there is no different UI for page specific changes, global changes or context based changes.

        So yes, the user can navigate to check other pages under the same settings, but what indication does he gets in the UI that he **should do that**?

        Report


      2. What a user can do and what he is likely to do are two hugely different things. […] So yes, the user can navigate to check other pages under the same settings, but what indication does he gets in the UI that he **should do that**?

        I suppose users should feel obliged to click links in the preview just as they naturally click links on the frontend to navigate around their site. In the customizer preview they should navigate to see how their site looks in different areas with the changes applied. Also, in the root of the customizer, there is a “?” help icon at the top. Clicking that reveals some help text that says, “The Customizer allows you to preview changes to your site before publishing them. You can navigate to different pages on your site within the preview.” So there is that, but I’m sure the number of users who click that is small.

        Obviously it is a hard problem to solve, but right now you just don’t know, there is no different UI for page specific changes, global changes or context based changes.

        Actually the customizer does provide a framework for this, to a degree. Panels, sections, and controls can be contextual to various URLs of a site by specifying the active_callback. When something is contextual, it is displayed; when not contextual, it is hidden (normally). For example, sections for widget sidebars currently only appear when the preview is actually rendering that widget area. Likewise, the front page sections panel in Twenty Seventeen are contextual to the front page. In 4.7, the Video Header controls are only shown when on the front page, since that is currently the only place where video headers are rendered.

        More work can be done to indicate whether a given control is related to a global setting or one that is related only to the current preview, but that’s probably something that needs to be configured when the control is registered and can’t be something we can programmatically determine.

        Users have no information on what will be the global impact of a change.

        You’re right. But that’s even more true when making changes in the WP admin. In the WP admin a user can’t even preview how a change impacts the homepage let alone the entire site. If the user can be encouraged to click around to more areas of the site in the customizer preview before publishing changes, they would then be able to have the assurance that a global change won’t have a negative impact on the entire site.

        Report


    4. I totally agree that the UX of the current “Customizer” app needs to be revisited. I am not advocating for all WordPress management to be crammed into the current Customizer. What I am advocating, on the other hand, is that all changes in WordPress should be previewable, staged, scheduled, and batched. Changesets in Customize API provide the plumbing for this, the underlying architecture and interface, and the API can be utilized without ever directing a user to customize.php. Part of the impetus for 4.8 will be to start prototyping more of these interfaces, including starting new changesets from the frontend context with inline editing and for managing changesets via the REST API.

      As for educating more developers on the internals of the Customize API, we’re trying our best. There is the handbook page, and you can read in depth about the changes on the Make/Core customize dev notes and there are also posts on the XWP blog under the customizer tag.

      Report


      1. +1 for previewable, it is really priceless, but what is exactly the plan for staged, scheduled and batched? Are you going to prevent posting new content, or do theme/plugin/core updates until the changeset is applied? because each of those may negate the impact of the changeset.

        staging is a solved problem in web development, you just need a different staging site to work on, and you make your changes in code so you can track them on GIT/SVN. The changeset feature is just a bloat for most people that don’t do any long customization sessions, and it is just not good enough and can never be made good enough for people that actually need staging.

        As for educating in the code…. This is truly black magic for any developer with less then 10 years experiance in web development. You need to know PHP well, you need to know JS well, You need to know jquery well. People that have this kind of skill set are usually too busy to work on a software that fully rejects OOP (if a class is final and have no interface then you only have a glorified namespacing, but no true OOP) and force code to be php 5.2 compatible

        Report


      2. what is exactly the plan for staged, scheduled and batched? Are you going to prevent posting new content, or do theme/plugin/core updates until the changeset is applied? because each of those may negate the impact of the changeset.

        Batched changes are just an aspect of how the customizer publishes changes to start with, where you can make X changes in a customizer session and publishing them makes them all go live together. Changesets then extends this to allow those pending changes to persist in a custom post type, which then allows for those changes to be drafted, scheduled, and published later.

        There is no content freeze to site changes when there is a pending changeset. There can be any number of changesets worked on concurrently. When you make a change in the customizer, only the modified (dirty) settings get included among the customized state and only these values get saved into the changeset. So if someone creates a changeset and schedules it for publishing in a week, other changes that are made to the site aren’t going to be overridden by the scheduled changeset unless they’re the same specific settings that were modified.

        The Customize Posts plugin makes use of auto-draft posts to reserve post IDs for a customizer session, and this ensures that IDs for posts specifically don’t conflict. Creation of new widgets in core is not resilient to concurrent user sessions, either in the admin or in the customizer. See #35669 for work being done in that area. There is also a feature plugin that addresses the problem of concurrent widget creation in the customizer. Nav menus need to be looked at for issues related to concurrent editing. See also #31436 for general concurrency improvements in the customizer, but concurrent editing is a general problem in WordPress not just the customizer.

        staging is a solved problem in web development, you just need a different staging site to work on, and you make your changes in code so you can track them on GIT/SVN. The changeset feature is just a bloat for most people that don’t do any long customization sessions, and it is just not good enough and can never be made good enough for people that actually need staging.

        Staging is a solved problem in web development for code not for content. There are many efforts underway right now to try to find the best solution for that, including VersionPress and Mergebot by Delicious Brains. The customizer has always been the WordPress interface for live previewing changes, that is, for staging changes to go live within a (short) user session. Even so changesets have immediate value for these users since they allow for the customized data to persist when switching themes in that same session and for recovering the pre-published changes after a browser crash. But changesets also open the door for staging content for longer periods. Users can (even now in 4.7) send the customizer URL to someone else so they can make additional changes to the same changeset. Changesets could go through editorial review and get stakeholder sign off while also being scheduled for publishing.

        It’s true that changeset conflicts will arise in such usages. So that is partly why there no UI exposed in core for long-term staging. The Customize Snapshots plugin is where we’re actively working on keeping track of conflicts and presenting UIs for drafting, scheduling, and publishing changes while considering presenting UIs for letting users resolve conflicts. Once the features are developed in the plugin, then they’ll be proposed for core inclusion.

        Report


      3. @weston, you can not rely on changesets since you can not isolate them due wordpress lacking a concept of contextual setting/db/whatever. Every DB write, every code update can potentially make a changeset void, every change (and code changes are impossible to detect) should mark all changesets as “dirty” and not ready for being applied without a renewed inspection. Every comment made, even if it is spam, should made all changesets void because there is no good way to know what would be the impact on the front end.

        And there is always the core problem of wordpress not supporting DB transactions. Which means that a changeset might fail due to whatever reason (DB disconnects for a sec) while it is being applied, potentially corrupting the DB. IIRC transactions are part of core PHP only since 5.5 which means core wordpress will probably need to wait 5 more years before being able to use them.

        Just the idea of applying anything (semi) automattically without human attendance and acceptance of each stage is crazy if it does not come with a good backup system bundled with it. Blogs can survive a loss of one day due to having to role back from a daily hosting backup, but shops can not.
        Changesets might be a viable thing only if you can easily undo them.

        … integrated backup system in core is years overdue

        Staging is a solved problem in web development for code not for content.

        This just exemplifies the core complaint against the customizer right now. Is it a content creation tool? an admin tool? an GUI configuration tool or maybe (since the 4.7 css code editor) a development tool?

        When you try to do so many things, which are mostly orthogonal to each other, at once it is rare that you get all of them right, a more likely result is that you will fall short on all of them.

        Report


    5. Now this will get multiplied with changesets, if anyone will ever use them. You develop a changeset but from the time you have done it to the time you apply it some other very related option was changed that will render the whole changeset pointless. The worst scenario is of course when the changeset is only partially broken in a way which is hard to notice.

      The question of concurrency locking changesets and providing an interface for conflict resolution is currently being worked on in the context of the Customize Snapshots feature plugin.

      Report


  10. In mid 2014, I assumed ‘Live Customize’ feature will gain prominent focus eventually. Once I dug into the code throughout the rest of that year, I was certain it could be the most controversial feature at times, but still core will improve it huge over the time.

    In 2017, probably the real impact will be there for Customize Components, since it’s now gain much more mature code-base, and REST API merged into the core, too.

    It would be interesting to see how it changes so fast in the coming years- either as a base of *new* ways to do things, or how it influence and spread the *live-preview* over a lot more features.

    Many thanks to the awesome contributions from the teams- :)

    Report


  11. Pretty great article, thanks for that Sarah. I have had been contributing regularly since WP 4.2 and Customizer is the component I fell for. I think it is growing and improving at a far better pace than almost any other component inside the core. Huge props to Weston and Nick for their work. This BTW is the only reason why I have started to contribute at Customize component.

    I think most of the developers who hate Customizer aren’t aware of what it has become in the last 2 years. Even here in this comment section two devs are calling ‘full page refresh at every keystroke’ a bad thing while there are partial refresh and transport methods to deal with it.

    Most of my clients are more happy and feel more comfortable while customizing themes via Customizer. WP admin has a huge tech debt, it is slow and sluggish. Customizer on the other hand has everything we need to make things better. A VueJS or ReactJS port might help but not as dramatically as it did in the case of Calypso. It might end up alienating a good chunk of contributing developers and slowing down the adoption in the long run.

    Anywho, I think more devs should consider reading the API and improving the component which so much vital from a user’s perspective. This kind of thing used to be a dealbreaker for WP – not anymore.

    Just my 2 cents.

    Report


    1. Most of my clients are more happy and feel more comfortable while customizing themes via Customizer. WP admin has a huge tech debt, it is slow and sluggish.

      I envy you your clients. My clients are usually older people with very limited computer skills. They can be taught how to operate admin because it’s very similar for example to their email client. But it’s almost impossible to teach them customizer because their brain can’t handle all these sliding disappearing panels and sections.

      I also have few friends which are pro affiliate bloggers and non of them is using customizer and they don’t understand why should they. No advantage for them. Just bad UX and it is much slower.

      Anywho, I think more devs should consider reading the API and improving the component which so much vital from a user’s perspective. This kind of thing used to be a dealbreaker for WP – not anymore.

      Just my feeling but maybe it is because “it is not a WP” anymore. I feel it like something different build on WP. For someone without very good js skills It’s much more complicated, much harder to debug, extend, easier to break and less documented than classic php core. As average developer It was always fun for me working with wp php core but is a pain and struggle to work with customizer core.

      Report


    2. Why do you think peoples lack of enthusiasm for the Customizer is due to them not being informed? Thats quite a condescending attitude. Assume people are informed and their issues are, at least according to them, well founded.

      And saying folks like X because its better than Y does not equal that X is good. Its better to get your leg chopped off than die of blood poisoning. But that doesn’t mean people really want to get their leg chopped off. Its about perspective. Could the idea that is at the base of the Customizer have been implemented in a better way from UI, UX and code? The answer to that is yes.

      Report


      1. Why do you think peoples lack of enthusiasm for the Customizer is due to them not being informed? That’s quite a condescending attitude. Assume people are informed, and their issues are, at least according to them, well founded.

        Don’t know how you ended up considering an **OPINION** a condescending attitude. But take a look at the comments on this post (which can be found elsewhere as well)

        The code required to use it will either require a full page refresh on every key stroke, or will have to violate KISS and DRY.

        I’d call it — Blaming Customizer without getting to know it properly. Also, nothing is perfect, and hell it’s open source, why not open a ticket and improve upon it.

        Could the idea that is at the base of the Customizer have been implemented in a better way from UI, UX and code? The answer to that is yes.

        Sure, it can be better. IT WILL BE :) I find it to be very well paced as compared to other components in the core.

        UI/UX and code could be better? Sure, why not! Head to the trac, open up a ticket and contribute. Share your thoughts. Weston and Nick would be there to help you and improve customizer.

        As a matter of fact, if you look at the growth of any component, you might (and I say MIGHT) end up deciding in favor of Customizer. So, in turn, your new ideas about UI/UX will have a much better chance of making into core.

        Nothing “condescending” about it.

        Writing it off is what I don’t understand at all. Just because it can be better, doesn’t mean its complete crap.

        Report


      2. Don’t know how you ended up considering an **OPINION** a condescending attitude. But take a look at the comments on this post (which can be found elsewhere as well)

        The assumption that people don’t know things because they don’t agree with your view is a condescending attitude.

        I’d call it — Blaming Customizer without getting to know it properly. Also, nothing is perfect, and hell it’s open source, why not open a ticket and improve upon it.

        Again with the false assumptions. You just can’t stop can you? Maybe just maybe people have come to their conclusions by revisiting the subject from time to time to see if it has improved only to see that it is still not very good?

        UI/UX and code could be better? Sure, why not! Head to the trac, open up a ticket and contribute. Share your thoughts. Weston and Nick would be there to help you and improve customizer.

        Haha yeah right. If I don’t agree with the fundamental concept of the Customizer my input is worth jack shit since it will go against the whole thing. All I could help with is with adding some lipstick.

        Writing it off is what I don’t understand at all. Just because it can be better, doesn’t mean its complete crap.

        Like I wrote just because its better does not mean its good. It can be “meh”.

        You really have drunk the coolaid.

        Report


      3. Blaming Customizer without getting to know it properly.

        I think I am one of the top people in the world at this point as far as it comes to understanding how the cusomizer actually works, but as I said before, your kind of attitude of rejecting any criticism because it doesn’t come from an insider is why people that have a lot more wordpress knowledge than the average contributor just stopped trying. Talking with walls is usually better, the walls will not insult you by assuming you are an idiot.

        Report


      4. Hey, Mark!
        I am not rejecting your criticism! I am calling it out on being a wrong assumption.

        The code required to use it will either require a full page refresh on every key stroke, or will have to violate KISS and DRY.

        Anyone who implements a full page refresh for an option where an end user needs to enter text is wrong. Customizer is a tool, you can use it both the right way, the way it is meant to be, or not.

        What you are referring to is wrong! Both as a principle fact and as an assumption. It is not the criticism that I have an issue with, but the WRONG assumption.

        Implementing partial refresh or transport methods to get text updated without a page reload is very simple, it does follow KISS and DRY rules.

        On that note, Customizer simply provides you with its API, it’s you (read as the Developer) who chooses to either use it the right way or violate the KISS/DRY rules.

        Report


      5. Andreas!

        The assumption that people don’t know things because they don’t agree with your view is a condescending attitude.

        That’s not something I ever said! I said, the complete opposite. It is not about agreeing with me. It’s about Customizer. Use it right, and your users will love it.

        Again with the false assumptions.

        If someone is refreshing a complete page on every single keystroke, they definitely don’t know what they are doing.

        Again, not sure, why anyone would want to implement an option like that. It’s a quote from a comment above yours, not a “false assumption.”

        Haha yeah right. If I don’t agree with the fundamental concept of the Customizer my input is worth jack shit since it will go against the whole thing. All I could help with is with adding some lipstick.

        So, you do not want to provide any input because others won’t know what you are talking about? Hmm… if you are so sure about that why take your time out to comment here, you can just go on and ignore Customizer.

        In my humble opinion, right now, it’s you who I think have a lot of assumptions here. I’ll leave it at that. The conversation ain’t constructive anymore. I’d like to talk solution instead of problems.

        Propose a solution, and I’ll be there to support it if it made sense :) (to me). But if you’re only interested in sitting on the sidelines thinking that your “input is worth jack shit” — nothing much we can talk about then.

        Unless until there is a better solution, I think I’ll have to settle for the “meh” version.

        Peace!

        Report


      6. That’s not something I ever said! I said, the complete opposite. It is not about agreeing with me. It’s about Customizer. Use it right, and your users will love it.

        You say tomato I say its actually potato since it grows in the ground is brownish etc.

        If someone is refreshing a complete page on every single keystroke, they definitely don’t know what they are doing.

        Add a standard text widget to a page and start typing in the textarea. So you claim the WP Core team don’t know what they are doing?

        So, you do not want to provide any input because others won’t know what you are talking about? Hmm… if you are so sure about that why take your time out to comment here, you can just go on and ignore Customizer.

        That’s not what I wrote. And still with the condescending attitude.

        Unless until there is a better solution, I think I’ll have to settle for the “meh” version.

        There won’t be a better version and thats why I won’t bother providing anything. Not that I have for years since I don’t agree with alot of the decisions that the core folks make.

        Report


      7. @Andreas, to be fair the text widget does selective refresh starting with 4.6 or 4.5 (an ajax request sent to the server to calculate new html) and not a full page, but probably no complex widget that needs to change CSS and JS will be able to use selective refresh.

        @ahmad, since it seems like you are the expert, maybe you can suggest to me how can I in my widget trigger full page refresh when I have to (change JS settings/ libraries being queued) and selective refresh when I can avoid the full page one?

        Report


      8. @mark-k How about posing your question on Stack Exchange and we can work out a solution there for posterity. Short answer is that the WidgetPartial needs to extend its refresh to invoke the fallback method when such a change is detected in the widget’s instance data. Or a better solution could be listening for the partial-content-rendered event. Or yet again, it could be better handled on the PHP side by adding a customize_partial_render filter to return false when the instance data perhaps disagrees with the placement context in regards to this aspect. Bottom line is there are a few options available so we can look at which would be best and perhaps establish one as the standard best practice.

        Report


      9. @weston

        1. Thanks, I will look for it. I assume this will be hard to hack from a widget but maybe my gut feeling is wrong here.

        2. AFAIK the general attitude toward the customizer (and media library) in WPSE is “The code is unreadable, not going to bother to put the effort to understand it just to answer a question”. And probably no one there has any reason to write anything for the customizer, people that build sites for client/workplace don’t need it at all, only “for sell” theme developers need it.

        As @rarst said on a comment here, wordpress is busy implementing features that might be interesting to users (and that is also in doubt), but have nothing in them for good developers.

        Report


      10. @mark-k: We actually work very hard to engineer new capabilities in the customizer so that they can be extended and we try to document these in Make/Core posts and demonstrate them via feature plugins. As a developer myself, I’m personally more interested in making the customizer a good experience for developers (for myself even) to extend rather than creating new user features. I want to create a foundation to facilitate future improvements. For example the changeset improvements took 2 years of iterating and prototyping, but in the 4.7 release there’s not really a flashy user feature that it brings. Nevertheless, it will open doors for new user features in subsequent releases and it improves the architectural foundation for the customizer to add those features and for plugin authors to develop extensions.

        As for WPSE, I’ve answered questions before on the customizer, and just this week I made a point to subscribe to a daily digest of the theme-customizer tag. A question was asked today in fact and already got a good answer, which I see you found: http://wordpress.stackexchange.com/a/247247/8521

        So I’ll get notified of your question once you post it there. Cheers.

        Report


      11. Looks, like Weston has answered all the queries. I am on vacations, couldn’t respond earlier. WPSE has an active WP community. I myself have started contributing Customizer documentation there. Do take a look.

        Report


      12. @ahmad, yet more assumptions on your side, but anyway the weston!!!!!!!!!! battle cry, while I think he deserves it, points to a bad bus effect problem (hate the term, lets call it a CTO effect instead, at least until trump selects a different CTO for the whitehouse ;) ).

        Your answer on the question will be very welcome http://wordpress.stackexchange.com/questions/247251/how-to-mix-partial-and-full-page-refresh-in-the-same-section-of-the-customizer?noredirect=1#comment368823_247251

        Report


      13. @mark.k Ok retesting quickly on a site and the response from the XHR post that is triggered by keypress is a whole page on my installation with latest WP version using Chrome. The whole thing flashes with blue overlay on each key press and results in up to 83 requests and 233KB transfer can even result in MBs of transfer due to that. The main cause of MBs etc is the result of using tracking blocking plugin etc if you have WP Stats or Facebook etc things on your site.
        All this is due to the full page response that triggers the redownloading etc of the site assets; scripts, style sheets.

        Report


      14. @Andreas I tested the core text widget with mostly vanilla 4.6. As far as I can see in the code, none of the core widgets should cause a full page refresh so manybe something is wrong on your install.

        I am actually not bothered with the full page refresh as it is still faster than working with admin setting pages, but it can be nice to have an on/off switch to control it. Even when the XHR works there is no point is sending a request for each letter a person types.

        Report


    3. Totally agree with you Ahmad! The changes to the Customizer API have really helped to fix initial issues that most developers complain about (and continue to complain about).

      All of our clients/users pretty much live in the Customizer now. It really comes down to how well the API has been configured in the theme/plugin.

      However, we tend to recommend that people configure menus and widgets in the traditional way. Some extra work is required for those sections, I believe.

      Report


      1. Glad to know that someone agrees with me. Yes, the menus/widgets area needs to be improved, I, on the other hand, find myself mostly using Customizer for them as well. But, it def can be enhanced, and it would be.

        Report


  12. Just some ideas…

    As has been mentioned numerous times the limited UI space can be awkward for advanced customization. If I’m working on a large screen in the customizer then it would be great if the UI could be expanded somehow to accommodate the larger space.

    Perhaps we should be thinking about responsive sizes for the main customizer panel? Maybe even having a left and right panel if the screen space is available?

    Or what about a floating panel that can sit on top of the page and could be dragged around and resized (e.g. to be wider rather than tall and long). And have sub panels that could be separated from the main one?

    If there is so much continued negativity regarding the customizer then we need to take a step back and understand exactly why this is. Is it purely a UI implementation issue? If so then a more flexible UI would be the key to moving forward.

    Report


    1. Cheers. Yes, good ideas. We have a ticket open about increasing the width of the customizer pane, allowing it to be resized, and also discussing the idea of letting it be a floating panel: https://core.trac.wordpress.org/ticket/32296

      Also, as part of the Customizer Roadmap, there is a point about “Bootstrapped Customizer” where the customizer can be loaded onto the frontend context. Now with selective refresh, we could actually let elements be edited on the frontend and the controls associated with the given elements could appear as separate floating elements.

      In any case, there is definitely UX work needing to be done to provide for more areas of WordPress to make use of live preview, whether this is inside of the traditional “Customizer” or not.

      Report


      1. This ticket has been opened for 19 months now and still nothing has happened with it. People have been begging for the Customizer to resizable since it was first implemented, back in WordPress 3.x, and still nothing has been done. The Customizer, in it’s current form is definitely not going to help get WordPress usage over 50%. Instead of just constantly trying to push more and more functionality into an already poorly designed feature, the existing experience needs to be improved if you want people to actually embrace it.

        Report


  13. I find it incredulous the difference between the lengths WordPress goes to please users and its expectation that developer engagement just falls from the sky unprompted.

    Yes, Customizer is important for cheap/DIY segment of users, which fuels WP’s market share, and Matt did tell everyone to learn JavaScript.

    Why would any of this matter to a developer?..

    Customizer is irrelevant to any other segment… Wait, it might not be… but if so it’s failing horribly at explaining its value to other use cases.

    WP market share doesn’t always benefit developers directly and symmetrically. In some ways it had been things worse for them by endlessly pushing for free things and devaluing to users what developers do and what it costs.

    If your learning strategy is to do what Matt tells you… Welp.

    The lack of developer engagement is not a problem with developers. It’s a problem with WordPress.

    Report


  14. What evidence is there for a causal relationship between the customizer and JetPack leading WordPress to increase its market share that can be separated from other products that allow users to customize their sites, like Beaver Builder, Divi, Visual Composer etc?

    Report


    1. I think the evidence you are looking for is called wishfull thinking. But mainly due to a very very low percentage of users actually use Beaver, Divi etc. Not that one can claim that Customizer has anything to do with increase in user share either. Increase of market share could just be that more hosts have single click installs etc and nothing to do with what actual features are available in WP or plugins.

      Report


      1. Beaver Builder and Divi both seem have a decent number of users who use either of them.

        Report


  15. I’m encouraged by the change in thinking regarding the customizer, which has always looked and acted slammed together. Stuffing more into it just increases confusion. Even the naming conventions currently used overlap. Good technology, and I have said this at the result of isolation by WP wiz kids in the past, cannot be achieved when the emphasis is always to hide behind backwards compatibility. You sometimes really do have to break a few eggs. Customizer is worth scrambling.

    Report


  16. “If the community realized the vision behind and appreciated a full admin experience that had live preview and staging of changes, then that would make a huge difference,” Ruter said. He and contributors find it challenging to articulate the scope and they are considerably short-handed.

    This is key. WordPres would benefit from more clear communication and roadmaps that contributors can get behind and base their work on. There seems to be a disconnect not only in how to do things, but also the foundational question of what should be done. The Customizer, as an example, is very much an ideological approach (which explains the resistance to it). To get people on board, that ideology has to be explained in such a way that people understand it instead of just seeing the practical outcome. I think this is what Helen was talking about in her Tweet: the Customizer is not what you currently see – it’s the ideal of a future where most administration is done with live preview on the front-end.

    Report


    1. the Customizer is not what you currently see – it’s the ideal of a future where most administration is done with live preview on the front-end.

      But some of us don’t think the Customizer is the best way to live up to that ideal or even that it is desirable that most of the administration is done on the frontend. Most of the usual tasks maybe but not administration. And by tasks I refer to things like frontend posting, page creation etc. Which then needs to be properly handle with all the metaboxes and what not and Customizer is not suited for that.

      Report


    2. What do you think about one clear landing page which did show the WordPress public roadmap?

      Report


  17. The customizer is cool and will have many benefits although the changeset feature is inherently flawed (someone explained the issues better back up this thread).

    However if the customizer plus changesets is a high priority for core then wp has big problems. As a developer this just delivers some nice to have features, but features I can live without.

    This article should be required reading.

    https://www.alainschlesser.com/project-moiety-a-hypothetical-wordpress-roadmap/

    Report


      1. Most of them still use WordPress just as a blogging platform, but still pretty nice.

        Report


      2. I’d defer to Automattic for details on some of those, since many are VIP customers, but I would say that it’s quite a bit more involved than a standard blog and more along the lines of a mature news publishing platform for them. But I think that one point that Matt has made is that the acquisition of Woocommerce was an indication that he’s aware that WordPress needs to become a more well rounded managed solution for commerce and other use cases from a core perspective, I believe. I think that is a wise move personally.

        Report


      3. Thats what WordPress was and IS intended for. Blogs and news. Big companies usually use software for what it’s intended for. Their not looking for cheap solutions to get around the real deal.

        Report


  18. I find customizer a pain in my ass. I create site for business owners, for creatives who want a showcase, for small ecommerce experiments. They want one theme, and they want it finished. They don’t want to upload a logo or decide on a different color for their links.
    I used to rely on Suffusion for an incredibly flexible framework. The opinions section was laid out logically, and I could finish my tweaks with custom css inserts.
    Now I’m using WP-Forge and child themes. I can skin a site pretty quickly editing a css file. But I am constantly being tripped up by the customizer, and its overrides.
    It would be WONDERFUL if there were a way to turn it off in cases like these.

    Report


  19. “Ruter said he would have a difficult time proposing to build a client site that depended on the WordPress admin for site management and content authorship.”

    Doesn’t that mean we should rethink the admin area entirely rather than shoehorning everything into the Customizer?

    Report


    1. Yes, we definitely should rethink the admin area. But again, I’m not suggesting we shoehorn everything into the current customizer interface. As I quoted Helen above:

      What if instead of opposing “shoving more stuff into the customizer” we supported “adding live previews to WordPress functionality”?

      What I am advocating is that we develop WordPress in a way that all changes can be previewed and staged. The underlying Customize API provides the mechanisms for this. The current “Customizer” app (which heretofore is the only application of the Customize API) should not be considered the ultimate UI for previewing and staging changes to a site’s configuration and content.

      Report


      1. I agree but too often that’s not the message that seems to get out. It’s “The Customizer will be increasingly important” which gives the message that more and more things will be stuffed into it.

        As I said in another comment here, what I’d like to see is a clear statement of what the Customizer is and is NOT. It started life as a way to customize themes, not a front end editor, admin, etc. Then I’d like to see some discussion around what else should be done and HOW. For things that are out of scope of the customizer, launch new projects. Ideally, these would define a new admin experience.

        To me, the customizer should be a rarely used, but powerful way to edit theme settings, including things like tagline, etc. It should NOT be a way to do day to day admin tasks. Those should be out of scope for the Customizer, but the need for them should drive people to start rethinking the admin interface.

        Also, don’t name the API the Customize API – that lends itself to confusion.

        Report


  20. This comment is both intended at the original thread, but also @Rick Gregory.

    In 2011 I started developing a custom Integrated System that relied on WordPress common interface even as it recapitulated WP into a Web Publishing driver, and CMS plugin to a larger data-abstraction-layer-as-engine. This allowed the development of decoupled, and “loosely coupled” content within the WP framework, and brought some formerly untouchable Enterprise tricks to small business scale. It also served several markets including Online Courses, and of course content marketing. I started offering these as Business Websites in 2012, and focused on hiding the complexity of the Integrated system in the familiarity of the WP Admin interface. This required serious UI work, some re-development and ultimately this has spilled over into new possibilities in the UX- both from Admin and End User point of view (and polymorphic classes…).

    My point is that I think there is some clout and some latent sensibility WP-ifying things, even if methods do change under the hood. When I release methods, they are usable by the average $10-$15/hr. admin assistant, or less for outsourced VA’s who love the simplicity of the interface, the unified interface, and the fact that if nothing else it occurs within a familiar framework, so this instills confidence. Music to the ears of most organizations and trainers.

    What I ended up building is much like a Kajabi/KajabiNext with the ability to whitelabel; and as much as I hate to put it that way because my system is far more robust and extensible, it’s the quickest way I can draw a comparison. Ultimately I’d like to see this system usable to benefit the entire online community even though I’ve reserved it for my own (family) private commercial enterprise. I have 6 years and over 30,000 hours invested in it personally.

    Is this line significant enough to warrant a conversation about collaboration and open-sourcing it with WP.org (self hosted WP) in mind? This and offering a Premium Hosted counterpart, like a managed service layer? (it’s too data intensive to work well as a SAAS, but it could be built with MU to offer Premium Shared Hosting accounts that would scale).

    I have been porting my code to work with Keystone.js to provide a second leg to my infrastructure, but I did not realize until now that Calypso was co-opted by Automattic… Calypso was my choice in 2012 based on the current iterations in JS at the time… but I had sensed a lull in their dev cycle, and when Keystone’s position strengthened between 2012 and 2013 I felt like I had a winner… Now this is an interesting turn.

    I’m curious the kind of feedback I’ll get here- I am serious about advancing the Open Source/Premium Hosting branches of my work if there’s enough interest.

    Report


    1. Sounds interesting. There are a few issues:

      1) something built for a very specific need can sometimes be hard to adapt to a more general case.

      2) and sometimes not… but it might still be best suited for some uses and not others (i.e. I can see an admin backend that’s designed to be used by a newsroom being very different in exposed capabilities and user interface from an admin design for a single blogger.

      The current admin is, frankly, not good anymore. It’s not terrible, but it doesn’t adapt well to different uses and installing plugins can leave a mishmash of menus, etc.

      What we need to do is to have different admins for different uses:

      a) A portfolio admin

      b) a news site/magazine admin

      c) a simple, Medium-like blogging admin

      and so on.

      A start would be a modern, highly configurable admin that used the entire screen. The Problem with the current focus on Customizer is that it feels like the team wants to expand customizer into some Frankenstein monster of an admin. What I’d do is this:

      Define what the Customizer should do and what its limits are to be. To me, the name implies that it’s there to customize some base look and feel and templates content (the tagline, etc), not to do full on content editing or other admin tasks.

      Define what other needs are there that the customizer API can do (and what additions might be needed to the API). Call this project New Admin.

      Rename the API – if you call it the Customizer API… guess what people think? Right.

      Report


  21. Redesigning the Customizer area is a great step forward in the right direction. I definitely am looking forward to great WP Customizer. Btw nice post. You can visit my website at http://www.thetechpower.com

    Report


  22. I’ve searched but have not been able to find any sort of ‘white paper’ or roadmap type of discussion for Customizer. As a newbie theme developer I’m both intrigued by it and a little worried about it – I’d like to get some basic education about what it does today, and where it is headed. Maybe my search mojo is bad…haven’t really been able to put my hands on it.

    Report

Comments are closed.