Customizer Theme Switcher Officially Proposed for WordPress 4.2

This week, Nick Halsey officially proposed the Customizer Theme Switcher feature plugin for merge into WordPress 4.2. Halsey summarizes the goal of bringing theme switching into the customizer: “By integrating themes directly into the Customizer, live-previewing workflows are greatly simplified, and the relationship between themes and theme/site options is clarified for the user,” he said.

Halsey explained that the new UI is part of a long-term plan to move all the “Appearance” functionality into the customizer. “The future roadmap includes Menus, Theme-Install, and iterations on widgets that would allow the customizer to entirely replace those admin screens for most users,” he said.

His proposal includes a video that demonstrates how a user might scroll through the customizer to browse and preview available themes.

It’s important to note that if this feature plugin is cleared for merge, users will not have to search for and install themes from the narrow customizer pane. The Customizer Theme Switcher is intended for previewing and activating themes that have already been installed. Contributors on the project are proposing that WordPress 4.2 redirect the “Themes” link that appears in the frontend admin bar to the customizer, instead of the backend.

In the future, Halsey plans to integrate theme installation into the customizer, but this is a larger effort that will be added to the project in a later release. Coming up with a UI that doesn’t make this a cramped and inconvenient experience is going to be a challenge.

For more technical details on the proposed core changes and merge implementation, check out Halsey’s post on the Make/Core blog. If you want to test out the new UI for theme switching, you can download the Customizer Theme Switcher plugin from WordPress.org.

The feature plugin merge window will be closing the week of February 25th, and the official release is targeted for the week of April 22nd. Updates on whether or not the Customizer Theme Switcher is approved for merge will be available within the next few weeks.

21 Comments


  1. Please stop pushing every single thing in to the tiny-ass customizer – it’s not even a customizer anymore but a catch all for everything it seems.

    Report


    1. Yes, it does seem to be a catch all for options that change the look and feel of the site. But isn’t that the point of having a “customizer” area? Isn’t it better to collect all these features into one spot instead of users having to hunt around for them across the admin board?

      Report


      1. Having all customization options in one place does, but are we customizing the look and feel of the site, or choosing a theme we already have etc. It just seems un-focused right now and the UI/UX is horrible in such a small window – not even sure at this point expanding it slightly in width would really benefit long term.

        Overall having all customization options in one place is a good thing, but how that happens and looks and works is not an easy challenge but certainly needs addressing I feel before more things are thrown inside it

        Report


      2. I’m wondering if it will require some kind of dark magic to make it suitable for theme search and installation. I don’t like the idea of eternal scrolling in order to browse theme search results. It will be interesting to see what they come up with.

        Report


      3. @Jami that’s exactly right – the point of the Cutomizer is to create a unified experience for customizing the site, with a live preview of changes before publishing them. For many, many users, selecting and changing themes is the most important part of the site customization process, hence this project.

        I’ll also point out for everyone that while the Customizer controls window is fairly small, this is a balance with providing a reasonably sized preview of the front-end, and the narrow controls UI window is mobile-first out-of-the-box. Being forced to work with less real estate in the Customizer controls forces developers to simplify their UIs and make things easier to use. If you’re shoving hundreds of options into the Customizer, you’re creating something that’s just as bad of an experience to use as if you’d done that in a custom admin screen.

        Report


  2. If you’re using WordPress like Tumblr, this makes some sense.

    Report


  3. I know this would irritate the heck out of me on my dev install, which currently has 146 themes installed. On my personal site, not so much. Then again, I don’t actually use the customizer on my personal site.

    Report


    1. Not only would it irritate the heck out of you it would also cause the Customizer to take AGES to load 146 880×660 screenshots – good luck trying to even make the slightest change in your customizer ;)

      Report


    2. I’d argue that the experience of browsing through that many themes isn’t much better in the admin. The in-Customizer version is exactly the same UI, just in one column. Search, etc. can help but ultimately you’re going to have to visually browse through all of them or search for a specific theme either way. We need a fundamentally different approach for both places to make it easier to handle having that many themes on a site.

      For everyone with scaling-type issues, probably worth noting that we’re planning on bumping out the Customizer controls area to almost full-width when we add theme-install, which is more the process where the entire focus is on finding a theme out of a large collection, whereas browsing installed themes is more limited (except in multisite-type setups).

      Report


      1. With regard to the following statement:

        “probably worth noting that we’re planning on bumping out the Customizer controls area to almost full-width when we add theme-install”

        Do I understand this correctly that you will make the customizer side panel almost fullwidth all the time? If so how can you then see the live preview of the customizations you are making? Or, are you meaning that the customizer will grow in width if you are browsing and selecting a theme specifically?

        Report


      2. No, it would only go larger for theme-browsing/install, where we feel the preview window is less immediately relevant. But the rest of the UI is not necessarily constrained to the standard controls window on larger devices, see widget-addition, for example.

        Report


      3. I actually like the current version that we have, even with that many themes. It’s fast and easy to scroll through. It’s by no means a perfect system, just better than the previous. Any improvements are more than welcome though.

        I’m not going to say too much one way or another. I’m just going to wait and see what you all come up with and wish y’all luck.

        Report


  4. I’m probably walking into a mine field here, but I really don’t understand this at all. There are plenty of more pressing issues with the UX/UI of WordPress than jamming the theme switcher and other appearance options into the customizer. If the core developers need a place to find inspiration for how a front-end customizing/editing experience could flow more effectively, there’s plenty of places out there doing it right.

    Look at Medium. Look at SquareSpace. Look at Maptia. Hell, even look at Wix. They all have WordPress beat hands down in this department. I think the real issue with the customizer, and lots of other front-end efforts within WordPress, is that there’s really no leadership in the UX/UI department.

    If you ask me, it’s really a shame. The simplicity of the UI is a big reason why WordPress was attractive to me back when I first started working with it. At the time, nothing else could touch WordPress in terms of easy-of-use. The problem is that if you look at things closely, there haven’t been many REAL advancements in that area over the last few years. We’ve taken baby steps, but with the exception of the media handling, there’s really been no large advances.

    I wish I had something more constructive to say about how to fix this problem, but I honestly don’t. I’m not sure if the WordPress ecosystem just isn’t attractive to UX/UI people or if they’re not listened to when they do turn up.

    Whatever the case is, I hope someone is able to stand up for logic and reason on behalf of the users soon. If all we’re going to get is more of this, I think we’re headed for trouble.

    Report


  5. I’m on board with the rest here – why do we need to add a theme switcher into the Theme Customizer . Isn’t the purpose of the TC to customize the current theme? It’s already starting to feel bloated.

    Report


    1. No, the purpose of the Customizer is to Customize your site; ideally the customizer has all options related to the front-end of the site regardless of whether they’re added by themes or plugins. Adding theme-switching to the Customizer clarifies the difference between themes and theme options, and makes the live-previewing process more centralized to the front-end context instead of the admin.

      Report


  6. Maybe replace the visual editor with a more modern one so users can style their posts more easily? I don’t want to tell my customers that they have to learn HTML in order to insert a table in the post when needed.

    Report


  7. Bloating the core with this nonsense is sad. If I had my way, I would want the entire “Customizer” code base to be a spun off into plugin itself not unlike JetPack. Distribute with WP like “Helly Dolly”, people can deactivate / delete if they like. Then you’re free to add what goofy features you like without much opposition. Developers that want to ensure it’s installed / activated can use something like TGM Plugin Activation the way they already do. Just my two cents. ;-)

    Report


    1. Themes and the ability to change them are one of the most fundamental features of WordPress. How do you feel that introducing a streamlined workflow for changing and previewing themes introduces bloat? There are no new features here, just a simplified way for using an existing, critical feature.

      The Customizer exists to provide an API so that themes and plugins can add whatever features they want in a standardized way, providing a consistent experience for users across the board. It’s up to themes and plugins to actually add options to it to determine exactly what it will look like, but as a core API you’ll find that it’s actually one of the better areas in terms of extensibility.

      Report


      1. Bloat IMO isn’t limited to features but also reduced performance and cluttering the UI / UX.

        “Themes and the ability to change them are one of the most fundamental features of WordPress.” – Agreed.

        However, this happens whether the customizer gets used or not. The Appearance menu / Settings API is plenty enough. If the “Customize” option ceased to be it would make no difference to me.

        The customizer and settings API are not the same to me. I use one but the other. The Customizer could live happily as a plugin even while the Settings API lived on in core. Right now it’s just a growing source of irritation that I put up with because I really like WP and it’s free.

        I really love WP’s Flexibility and Modularity but as far as the Customizer is concerned, WP is pretty rigid to me.

        Report

Comments are closed.