ClassicPress PetitionsClassicPress Petitions
This is a read-only archive. Post or comment on the live version of this page on our forums.

Remove the Customizer / move it to a Core plugin

October 24, 2018 · 16:57 · Pieter Bos

Businesses do not need the Customizer as they hire developers to customize on their behalf. Business owners simply want a functional website and they certainly don't have time to fuzz around in a sidebar with sliding elements.

This petition therefore aims to remove the thing altogether.

Possibly the Customizer Remove All Parts-plugin which hasn't been updated for more than 2 years can be used as a starter?

+33 more
Difficulty: Hard
Request: Remove feature
Glenn Dixon

Not all businesses. Don't forget 'small business' which might not have a budget for developers...

Ray Gulick

I'd like to see the customizer disabled by default, but with a simple box-check in settings to enable.

Josh Angehr

Agreed. I have used that code outside of the plugin on many sites with no issues. It definitely helps clean things up.

Mike Schinkel

LOL. Not that I agree with using the Customizer for all things, but a certain very large newspaper publisher in Australia has their entire editorial workflow centered around the Customizer.

Of course the CTO for the agency they hired to build it was the lead developer of the customizer in WordPress, so there is that! :-D

Paul van Zyl

businesses large and small, more than anyone else need the customizer. If they had the dev capacity and budget, why would they use a CMS?

To me the whole point, is really that marketing or editorial teams, don't need any technical skills, to manage the site or its content.

James Nylen

The following applies to pretty much any "remove X" feature request.

Simply deleting the code for the customizer would mean it's gone for everyone, including the people who do actually make use of it. In this case it is quite a lot of people.

We've started discussing a "core plugins" approach which would allow us to pull chunks of code out into plugins. That could be used here.

Most features that end up this way will need to stay enabled by default, definitely for sites migrated over from WP, and probably for new ClassicPress installs as well until it's clear that usage is very low.

There's a lot more work that needs to be done behind the scenes in order to make this work well, too. What happens when a user installs a plugin or theme that extends the customizer, and crashes if its classes are not available? How do we know which plugins and themes are in this situation, since we can't realistically expect them to be updated with this information?

So we also need to calculate and execute plugin dependencies in order to make this happen.

Daniele Scasciafratte

Please don't remove the Customizer after all is only to add specific settings to the theme, so is used only if the theme support it.
Also a lot of users love it because is more simple and easy to use and extend from developers.
It is talking an user that used on business websites.
An interface is important in this websites because they don't want that everytime for a label to call the developer as example.


I've seen one or two plugins talk about their use of Customizer for their "visual" editing. I don't think, at this point, removing Customizer would be a positive step.

If I'm not mistaken, WP has pushed theme developers, who use WP to host their themes, to use Customizer exclusively for their settings.

Neal Umphred

Thanks, James Nylen, for calling attention to those of us who are IT-challenged and use the Customizer religiously. I have "designed" my blogs using Twenty Seventeen, Customizer, and plugins. Wouldn't know how to do anything else and coudn't afford to pay anyone to do it for me.

Daniel Klose

I'm trying to avoid the customizer for one specific reason: the automatic preview. When a customizer has heavily been customized or the site is JS heavy, it becomes literally unusably slow to me. I'm not against the customizer per se, I just find it to be a performance disaster. Besides turning customizer on and off, I would actually like to see an easy way to disable the preview functionality. I've did some hacks before and believe simply disabling the preview fixes the performance issues, but would require more testing on this subject regarding implications.
Does anyone else sees this as an issue with the customizer as well?

Tim Kaye

Daniel, I experience precisely the same issue. In fact, the preview often does not load at all. And why anyone wants to do stuff in something the width of a phone beats me completely. I absolutely loathe the thing.

Daniel Klose

@Tim, agreed. I saw many premium themes move away from Custom Theme Options into the customizer tho. I guess removing the customizer completely is a big issue, but maybe just disabling the preview on user select might help. In general I think the customizer is a good approach at organizing the wrath that were custom Theme Options. Just the execution didn't work very well for me. Again, it's a large pothole I think and probably triggers many incompatibilites, just removing it, but maybe we can at least improve on the general painpoints with it instead?
Btw Here is a snippet to kill the customizer preview. Would actually be very easy to add an option for it via hooks into core:

Mike Schinkel

In my perfect world ClassicPress would turn the Customizer into a plugin and then in v2 or v3 implement a much better solution to achieve the same end-user goals, one that was not driven by the need to complete a client project on a client imposed deadline by its lead developer who had core commit rights, nor with any of the issues that came from rushing a technology that was not given time to mature, as were both the cases for the Customer. #fwiw


@Mike, I would agree with that. If it's a core plugin then it would be a dependency for some themes and plugins and could be activated in case that is needed. With page builders being more popular, it's likely that the Customizer wouldn't be used at all in many cases.

In which case . . . I can see the benefit of having Customizer as a plugin.

Pieter Bos

I have adjusted the title of the petition to reflect that moving the Customizer to a Core plugin is an acceptable outcome too :)

Daniel Klose

mhm just as a side concern: wouldn't that trigger some plugin errors if customizer core files are moved out? not sure to be honest so please ignore if thats not a problem.... Update: Sorry just saw that all customizer calls are done via the customizer hook...

Code Potent

I've seen a few petition titles changed. Please stop this. If the title is changed, then all votes should be removed from it to ensure that we're not voting on things that we didn't intend to.

Ray Gulick

I think moving 'unnecessary' features to core plugins is a good approach in general. Anyone who wants to use them can install the plugin, and anyone who doesn't want to use them doesn't have to be burdened with them.

James Nylen

In this case I think the title change is fine since it won't change the outcome of the petition. We can't delete the customizer for everyone (it would break a ton of stuff), so the only reasonable path forward would be splitting out the customizer into a core plugin.

This particular change is unlikely to happen due to the difficulty of splitting out the customizer and then maintaining it separately...


I would remove the preview module, and I would MOVE all the useful setting to a "site options" screen.

Must also check compatibility with themes and plugins that do rely on it like woocommerce


Just like the Guy said!


Possibly core plugin territory. For now, my free Classicpress plugin "ZP Remove Customizer" is available for everyone who hates the customizer.