Justin Tadlock
Nine years ago, the customizer had a rocky start among theme authors and users. Despite this, it has become the standard for modifying the look and feel of a website. Developers have become comfortable with the API. Users have grown accustomed to adjusting colors, fonts, and even internal WordPress options through it. However, it will disappear for many once a block theme is activated.
I began writing this post on the upcoming block-based theme system and site editor. However, I spent so much time explaining the customizer changes that I thought it best to focus on that aspect to let users know their options if they run into a snag.
It is also a follow-up to a post I published in October 2021 on the same subject. Since then, some things have changed.
WordPress 5.9 will launch with several of the final components of Full Site Editing. The centerpiece of these features will be a new theme system, which allows themers to build designs entirely out of blocks. Once such a theme is active, users can edit their site’s front end via the site editor and global styles system.
The site editor is, essentially, the next iteration of what the customizer aimed to do. The difference is that users can now customize every aspect of their site’s front-end and not just configure the options their theme author made available.
For many block theme users, the disappearance of the customizer will be a non-issue. However, three missing options have no exact equivalent:
Technically, the customizer is available via /wp-admin/customize.php. Even though no links to it are shown in the admin, any user with the requisite permissions can access it via that URL. At the very least, the first two issues can be mitigated by editing options in this way. It is not ideal, but it will work in a pinch.
The Site Logo block has a “use as site icon” option. This is a quick and easy way to update the logo and favicon via the new site editor, assuming they use the same image.
If they are different images or if the user does not use a logo, the only built-in way to change the site icon directly is through the customize.php URL trick mentioned above. The Site Logo block also adds a link to the customizer option. Users can also opt for one of the dozens of favicon plugins.
A custom CSS solution in core WordPress is unlikely to be reimplemented in the site editor. The global styles panel and per-block design options are the future of styling. This makes many of the most common stylistic tasks much easier for non-coders. In the context of block-based themes, the average user is unlikely to need the CSS editor in the customizer.
However, there are situations where custom CSS is necessary. Again, the easy answer is to access customize.php once again. For a more dedicated solution, there are numerous plugins available.
There is currently no solution for live previewing and customizing inactive block themes. With classic ones, users can test customizations before activation. In the customizer, block themes will appear with a warning message.
Once a block theme is activated from the customizer, WordPress will return the user to the Appearance > Themes page in the admin. They can then modify their site via the site editor.
However, this can be problematic for some sites. Just about any theme change will mean there is at least some customization work in order, and most people will not want their visitors to see an unfinished site. Working from a dev or staging site before migrating the changes is ideal. However, that option is not always available or even easy to figure out for everyone.
Another solution is to install a maintenance-mode plugin if working on a live site. This way, visitors will at least know some changes are happening under the hood and that they can return later.
There is an open ticket for previewing and editing inactive block themes. As ticket creator Anton Vlasenko wrote as the proposed solution, “It’s simple: we need to implement that feature.” In the long term, this is a must-have feature.
There is one situation where the customizer will still be accessible via the admin menu and toolbar. WordPress will automatically detect when a plugin or theme hooks into the customizer and make links to it available. I like to think that my first post covering block themes and the customizer raised awareness of this issue. At the very least, we now have a fix in place.
Assuming there are no other changes in the next two weeks, this is how the customizer will function when paired with an active block theme.
We often use a lot of custom CSS in the Additional CSS area of the customizer. Are we to go back to using a child-theme or a plugin for this… like Simple CSS?
Not having the custom CSS will be a bummer. I’ve tweaked many themes for my clients using this option.
Will this then mean that for more extensive custom CSS, a child theme would be better?
I suppose it will depend on your approach. There are tons of things that can be done directly via the site editor. However, for those things that cannot be done, yes, I would recommend a child theme.
That’s been my recommendation in the past too. I’ve always used the custom CSS option for quick fixes when I didn’t have my entire dev environment spun up. Then, I’d later add those directly to the theme or child theme’s stylesheet.
But, you can always go to the wp-admin/customize.php URL and make changes like that for a client.
Customizer was a revolution in WP but built on near Dead Technology. Gutenberg is the best thing that is happening in WordPress. Question, are Metaboxes also remove in WP. The 5.9 is really a refreshing start to WP all over again.
No, meta boxes are not going anywhere. They surely are not first class citizens anymore, though.
ok thanks for clarification. The video demonstrations from WP on 5.9 / FSE do not have them which made me assume they’ll be gone. It seems a little off having metabox below does not really give a full site editing experience. Obviously, I do understand the emotions around it how big metaboxes are and the impact it has had.
Just how long is the customizer going to be supported when a user is not using a block theme? Also, what is WP looking for that will determine if a block theme is active–therefore disabling the Customizer?
This will be interesting for millions of WP users, how well this will be accepted; especially when the custom CSS will be gone.
Just how long is the customizer going to be supported when a user is not using a block theme?
As far as I know, there is not even anything close to a discussion on dropping it.
Also, what is WP looking for that will determine if a block theme is active–therefore disabling the Customizer?
A theme is considered a “block theme” if it has a /templates/index.html file.
WordPress will be Joomla. I hope Joomla will do the opposite.
Removing Customizer will lead to more own “Theme Options” pages, partially with security holes due to not/bad implemented nonces and similar.
To be clear, WordPress is not removing the customizer. At least, there are no plans to do so anytime soon.
Block theme authors will utilize the block standard instead of options pages, which should lead to far fewer security issues on the theme end than even when building via the Customize API.
Customizer was a really awesome feature in WordPress. Hope new features will soon get introduced.
Hi Justin, nice article. I wanted to share the part of the favicon with someone, and noticed there’s no anchor links. You might want to add those in longer posts, so people can link to a specific part of your posts. 🙂
“There is currently no solution for live previewing and customizing inactive block themes.”
Any idea if this is something that will be addressed in the near future? The inability to preview adjustments and amendments is annoying. Users shouldn’t have to install a maintenance plugin to make alterations before going live.
There is an open ticket for the feature. There are several others that are related too. I’m fairly certain this will happen at some point (I don’t know when) because it’s a pretty major regression.
I know that there are no plans now to remove support for the customizer but over the long haul (and I’m talking 5 years or more) I expect it to vanish as block themes take over.
And I suspect there will be away – if not already – to convert a classic theme into one where the customizer is not used.
For those who have said, “The customizer must die” your wish will become reality. It was inevitable since Gutenberg 0.1.
Customizer is built on backbone which is near dead : https://trends.google.com/trends/explore?date=all&q=backbonejs , should WordPress use it : Definitely No. With full site editing in place who needs a Customizer. I am developing Blocks and theme on the new WP and it is really awesome. You can directly add CSS to the page using the raw HTML block. The Custom CSS feature which is being missed so much was already a wrong way to add css to pages. If there is css which has to be applied to all the pages of a site it should added in the style.css of the theme, not as an inline css.
This is not good, as a person with visual disability I depend on my sight assistance to do changes on the site. More often they get things wrong & without having a preview this is going to be difficult. I also depend a lot on Additional CSS in customizer, I will have to move my custom CSS to child theme style sheet then.
I’m really looking forward to trying this; for a long time it has felt as though WP was dragging its feet when it came to really facilitating theme development – overall it is positive shift; but I hope they don’t dawdle in replacing / fixing lost functionality – otherwise it will be self defeating.
The global styles editor can be used to modify the CSS of blocks, but not some HTML elements.
e.g. In the Twenty Twenty-Two theme I want to change the H1 font to Arial.
Can’t do it in the WP5.9 global style editor.
I’ve got 4 options:
Use customize.php and “!important”
Use a style.css file in a child theme css file and “!important”
Use a custom css plugin and “!important”
Use a theme.json file in a child theme
Options 1-3 have to use “!important” because the Twenty Twenty-Two global styles are written at the bottom of the page, and these options write css into the section.
If option 3 allows the custom css to be written just before the tag, then “!important” is not needed.
Enter your email address to subscribe to this blog and receive notifications of new posts by email.
WordPress Tavern is a website about all things WordPress. We cover news and events, write plugin and theme reviews, and talk about key issues within the WordPress ecosystem…
© All Rights Reserved. Powered by WordPress, hosted by Pressable
