Customizer CSS not findable/editable after recent Jetpack update

[kevinzweerink]

We had a weird issue on Newspack's marketing site and I think it may be related to changes Jetpack has made to its CSS support. I don't have the clearest understanding of how all this fits together, so apologies if I've misunderstood anything here.

• Last week, I added a bunch of custom CSS to Newspack's site via the Customizer (I know, not the preferred place to do this).
• Today, when I went to make some updates to that CSS, the Customizer nav item had disappeared from the Appearance subnav.
• There's now a nav item that says Additional CSS.
  • I believe that you used to be able to get the Customizer back by clicking that nav item, and turning on Enhanced CSS in Jetpack.
  • However, now that nav item takes you to a result that tells you to do custom CSS in the site editor. This is fine, except that none of the CSS I wrote in the Customizer appears in the Site Editor's Additional CSS panel.

I'm not sure if this is a Jetpack issue or a Core issue (or user error somehow), but it seems like a recent Jetpack update removed Jetpack's Enhanced CSS feature. This causes the Customizer to disappear from the nav for sites where Jetpack Enhanced CSS was the only plugin adding a panel to the Customizer.

This might not be inherently problematic, except that the Customizer CSS seems to then be locked in some unfindable place. If the user wants to edit (or remove) any CSS they wrote for their site in the Customizer, they need to install another plugin that adds a panel to the Customizer in order for it to be re-added to the nav. They also need to understand the logic of the Customizer being shown/hidden to arrive at this solution.

Is there a reason CSS written in the Customizer can't be automatically mirrored in the Site Editor's Additional CSS panel?

I would imagine that this might impact a non-negligible number of sites.

[jeherve]

Moving this to the Jetpack repo, where custom CSS is being built.

[jeherve]

Newspack's marketing site

What is the site URL? Was this on https://newspack.com/ ?

Jetpack's Custom CSS feature is not active on that site, but it is possible you were using the CSS editor in the past, and when you deactivated the Custom CSS feature you lost access to the customizer menu where you could edit CSS until now.

You could try to activate the feature back, long enough for you to copy the CSS and then paste it in your theme's global styles?

Is there a reason CSS written in the Customizer can't be automatically mirrored in the Site Editor's Additional CSS panel?

That may be a good improvement indeed, although we would have to be careful not to overwrite anything. It may be something better done in WordPress Core itself, since Custom CSS is saved by Core these days.

@glendaviesnz Since you worked on WordPress/gutenberg#46141 , I wonder if that's something that had been discussed when the panel was introduced? I could not find any related issues or trac tickets about it.

[kevinzweerink]

Hey @jeherve !

What is the site URL? Was this on https://newspack.com/ ?

Yep, that's it. For what it's worth, we've been able to reactivate the Customizer by adding another plugin; the issue I'm trying to report is related but not currently an active issue on newspack.com.

Jetpack's Custom CSS feature is not active on that site, but it is possible you were using the CSS editor in the past, and when you deactivated the Custom CSS feature you lost access to the customizer menu where you could edit CSS until now.

This is sort of what I'm trying to get at — I think Jetpack's Custom CSS feature was deprecated for Block Themes (maybe slightly ahead of schedule, based on the warning on this page). You can see in this screenshot that the setting in Jetpack > Settings > Writing that used to have toggle for "Custom CSS" now just prompts the user to use the Site Editor. We definitely didn't disable Custom CSS on our end, so my theory is that this is a change that came in a Jetpack update.

The issue I'm trying to report is this:

• I believe when this Jetpack option changed, it made the Customizer disappear. This is expected if the site doesn't have any other plugins adding functionality to the Customizer.
• Once the Customizer disappears, all of the Customizer CSS is still active and applied to the site, but the user has no way to access the Customizer to modify or delete that CSS. Any CSS that the user added via the Customizer seems essentially "locked in" unless the user figures out a way to bring the Customizer back via another plugin.

The crux of the issue is the ambiguous state of any CSS added in the Customizer when the Customizer disappears. It's probably a Core issue not a Jetpack issue. But I think it's relevant to Jetpack because the deprecation of Custom CSS either already is or will soon put a lot of sites into this state.

[jeherve]

I think Jetpack's Custom CSS feature was deprecated for Block Themes (maybe slightly ahead of schedule, based on the warning on this page).

It hasn't been deprecated yet, but we did indeed update the UI in Jetpack settings last year to recommend global styles when your site uses a block-based theme:
#31413

We definitely didn't disable Custom CSS on our end, so my theory is that this is a change that came in a Jetpack update.

For now we've made no changes to Custom CSS. We will in the next few releases though. If you did not recently disable Custom CSS on your end, then it's most likely you had never used Jetpack's Custom CSS module before, and another plugin on your site forced the display of the Customizer menu, allowing you to access the core CSS edit page. When you disabled the plugin, you lost access to the customizer.

The crux of the issue is the ambiguous state of any CSS added in the Customizer when the Customizer disappears. It's probably a Core issue not a Jetpack issue. But I think it's relevant to Jetpack because the deprecation of Custom CSS either already is or will soon put a lot of sites into this state.

Right, that is indeed the crux of the issue. Losing access to the Customizer after you've added Custom CSS there makes things complicated, and since Jetpack's Custom CSS does give you access to the Customizer for now, when we remove it folks will start running into the issue.

Within Jetpack, we could force the display of the Customizer menu if we detect Custom CSS saved on your site, but when folks disable the Jetpack plugin they'll run into the problem again. I believe this is a problem that would be better solved in Core, and not in the different plugins that force the display of the Customizer menu today.

That said, Jetpack may be one of the only plugins that does force the display of the Customizer menu. I'm not sure.

cc'ing @monsieur-z who is working on deprecating Jetpack's Custom CSS module. This may be something to keep in mind in Jetpack: we may have to keep displaying the Customizer menu even when the Custom CSS module will be gone, when 2 conditions are met:

• When the site is using a block-based theme, and
• When there is Custom CSS saved for that block-based theme.

[glendaviesnz]

@glendaviesnz Since you worked on WordPress/gutenberg#46141 , I wonder if that's something that had been discussed when the panel was introduced? I could not find any related issues or trac tickets about it.

It was mentioned here, but the feeling was that using both would be a rare case so trying to merge them was not worth following up.

[monsieur-z]

Issue added to our board.

[monsieur-z]

cc'ing @monsieur-z who is working on deprecating Jetpack's Custom CSS module. This may be something to keep in mind in Jetpack: we may have to keep displaying the Customizer menu even when the Custom CSS module will be gone, when 2 conditions are met:

When the site is using a block-based theme, and
When there is Custom CSS saved for that block-based theme.

I've done tests with a brand new Jetpack self-hosted site with a block-based theme. I enabled the Custom CSS module, wrote custom styles in the Customizer, disabled then removed the module altogether.

At that point, the Additional CSS item was still present under the Appearance menu.

That seems to cover the needs you discussed, @jeherve. Am I missing a case?

[jeherve]

At that point, the Additional CSS item was still present under the Appearance menu.

Where did that menu item lead? Didn't it lead back to wp-admin/admin.php?page=jetpack#/writing?term=custom-css, where:

1. It doesn't allow you to turn the module on since you're using a block-based theme;
2. We wouldn't want folks to turn the module on, instead they should be copying the CSS and pasting it in global styles.

[monsieur-z]

Didn't it lead back to wp-admin/admin.php?page=jetpack#/writing?term=custom-css

Right, I'm so used to seeing that section in the Customizer that I must have missed it.

In this case, the label Additional CSS seems more straightforward than Customize. I think it makes sense to just update the URL to link to wp-admin/customize.php?autofocus%5Bsection%5D=custom_css (the Additional CSS section in the Customizer).

[jeherve]

I think it makes sense to just update the URL to link to wp-admin/customize.php?autofocus%5Bsection%5D=custom_css (the Additional CSS section in the Customizer).

It does, with a caveat: when Jetpack's CSS module is inactive, I think we should only display that menu item when the site uses a block-based theme AND when there is already custom CSS saved on the site.

• When the site uses a Classic theme, we do not need to add any menu item; folks already have access to the customizer.
• When the site uses a block-based theme, we do not really want to encourage folks to use custom CSS. They should use global styles instead. We really only want to give them the option to edit existing CSS (or even better, copy it and paste it in global styles).

[coder-karen]

This was solved here: #37761