86 Comments

  1. Luke Cavanagh

    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

    • Weston Ruter

      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

    • Robby

      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. Weston Ruter

    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. Weston Ruter

    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

    • Weston Ruter

      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

    • Mike Schinkel

      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

      • Weston Ruter

        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

        • Mike Schinkel

          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

        • Weston Ruter

          @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. Andreas Nurbo

    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

  5. Nick Halsey

    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

    • Csaba

      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. Mike Schinkel

    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

  7. Miroslav Glavic

    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. Tyler

    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. mark k.

    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

    • Andreas Nurbo

      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

    • Weston Ruter

      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

      • mark k.

        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

        • Weston Ruter

          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

    • Weston Ruter

      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

      • mark k.

        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

        • Weston Ruter

          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

    • Weston Ruter

      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

      • mark k.

        +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

        • Weston Ruter

          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

        • mark k.

          @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

    • Weston Ruter

      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. Omaar Osmaan

    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. Ahmad Awais

    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

    • Michal M.

      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

    • Andreas Nurbo

      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

      • Ahmad Awais

        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

        • Andreas Nurbo

          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

        • mark k.

          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

        • Ahmad Awais

          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

        • Ahmad Awais

          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

        • Andreas Nurbo

          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

        • mark k.

          @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

        • Weston Ruter

          @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

        • mark k.

          @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

        • Weston Ruter

          @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

        • Ahmad Awais

          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

        • mark k.

          @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

        • Weston Ruter

          @mark-k Here is my answer: http://wordpress.stackexchange.com/a/247514/8521

          Report

        • Andreas Nurbo

          @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

        • mark k.

          @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

        • Weston Ruter

          @mark.k @Andreas There’s actually a Trac ticket that was opened recently about this. I’m suggesting that the refreshBuffer be throttled with a decay when there are rapid changes in succession. See https://core.trac.wordpress.org/ticket/38954#comment:6

          Report

    • Phil C

      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

  12. David Gwyer

    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

    • Weston Ruter

      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

      • Anthony Hortin

        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. Rarst

    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. Gary

    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

    • Andreas Nurbo

      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

  15. John Teague

    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. Morten Rand-Hendriksen

    “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

    • Andreas Nurbo

      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

    • Luke Cavanagh

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

      Report

  17. Pete

    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

  18. Jeffrey

    It would be nice to know which big companies are using WordPress for at least some part of their business. In Oct 2016, Nasdaq decided to use Drupal 8 https://www.drupal.org/drupalorg/blog/nasdaq-chooses-drupal-8, and it would be encouraging to see if WordPress got adopted by some big names.

    Report

  19. probablepossible

    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

  20. Rick Gregory

    “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

    • mikeschinkel

      My thoughts exactly.

      Report

    • Weston Ruter

      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

      • Rick Gregory

        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

  21. bellasys

    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

    • Rick Gregory

      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

  22. Aakanksha

    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

  23. Chuck

    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.

%d bloggers like this: