Jetpack: Custom CSS lost upon upgrade to WordPress 4.7

[kraftbj]

This is porting over https://core.trac.wordpress.org/ticket/39127 since it is either a bug in our compatibility layer or a Jetpack support issue, not a core issue.

From the original post:

Today I updated WPShout.com from 4.6.1 to 4.7, and lost all the custom CSS in my Jetpack "Appearance > Edit CSS" page.
Have since restored the site, so it looks fine now. I've attached screenshots of:
1) working.png: How it should look (including how the Jetpack styles make it onto the page), and
2) after_update.png: How it looked immediately once I updated to 4.7.
I created the screenshot for 2) by manually deleting all the Jetpack styles in Chrome dev tools, but it's exactly how the site looked when I updated to 4.7.
A couple of other details:
I tried the same process (update from 4.6.1 to 4.7 with the same custom CSS in "Appearance > Edit CSS") on a locally hosted site, and it properly loaded into the customizer. Clicking "Appearance > Edit CSS" now redirects to the "Additional CSS" view on the customizer, and the CSS is still properly there.
On another locally hosted site, I tried the same process (update from 4.6.1 to 4.7 with custom CSS in "Appearance > Edit CSS"), but with a single very simple CSS rule on the page: see simple_change.png.
The single rule continued to function, but there's no edit window for the custom CSS in the customizer: see after_simple_change.png.
So at this point I'm just seeing very inconsistent behavior in Jetpack's custom CSS feature during upgrades to 4.7.
I'm worried that a lot of 4.7 updates will end scarily for Jetpack users, so please let me know if this is an understandable problem and if there's a fix in the works -- or if it's a problem only I will have, which seems unlikely but would be nice.

[georgestephanis]

So, a quick summation of what's going on -- Old Core is Core < 4.7, Old Jetpack is Jetpack < 4.4.2.

Old Core, Old Jetpack

Legacy behavior. Both old versions.

Old Core, New Jetpack

Jetpack will detect it's an old version of Core, and fall back to the legacy Custom CSS implementation. No change from legacy behavior.

New Core, Old Jetpack

Jetpack's Legacy behavior will run in parallel to the new Core Custom CSS -- except Jetpack's is on /wp-admin/theme.php?page=safecss and Core's is in the Customizer. Both will print on the front-end and be available for editing.

New Core, New Jetpack, Pre-Migration

Jetpack will migrate legacy Custom CSS data into the new Core implementation, but only on admin page views. So if you've manually updated from the admin dashboard, Jetpack should have run the migration, or if it hasn't, visiting an admin page should run it.

Until the migration runs, if both Jetpack and Core are the new versions, Jetpack will continue printing it's custom CSS from the legacy Jetpack custom post type (because it hasn't been migrated to the Core data store yet). This behavior is to handle instances where a host upgrades your WordPress installation with no admin logins, so there is no one to trigger the data migration -- and to avoid race conditions, we don't migrate the data on front-end views.

New Core, New Jetpack, Post-Migration

All Jetpack Custom CSS will have been migrated to the Core Custom CSS post type. This includes splitting it out by theme into multiple posts, whereas Jetpack used to key off a single post, so switching themes will no longer blank your CSS, it will now be saved on the prior theme and comes back if you return to it -- similar to how a Theme Mod works. We have added a revisions viewer, and you can switch themes in it.

[georgestephanis]

If there is an "Additional CSS" in the Customizer, you're on New Core. If the "Appearance > Edit CSS" menu goes to the Customizer via "theme.php?page=editcss-customizer-redirect" you're on New Jetpack. If the "Appearnace > Edit CSS" menu goes to "theme.php?page=editcss" you're on Old Jetpack.

[jeherve]

All Jetpack Custom CSS will have been migrated to the Core Custom CSS post type.

I think that's the issue here. The migration doesn't always complete.

I've seen it fail completely on some sites, or fail half way through on others where there was a lot of CSS to migrate. I assume this could be caused by memory issues, but I haven't been able to reproduce or get my hands on a site where I could reproduce the issue yet.

The single rule continued to function, but there's no edit window for the custom CSS in the customizer: see after_simple_change.png..

This, however, is a different issue, and so far I've only seen it happen on sites where a theme broke or disabled Core's new CSS editor, thus leaving only the additional options added by Jetpack.

So far I've been able to confirm that the WPLMS theme was causing this issue, but I don't have any other confirmed conflicting themes. That said, this is clearly something that should be fixed by the themes, since they're breaking a core feature, not Jetpack.

[jeremyfelt]

I think that's the issue here. The migration doesn't always complete.

I think I'm seeing a couple of these sites right now. The sites both had many revisions of CSS in the Edit CSS interface and now have unexpected visual changes on the front end.

The revisions interface still shows at least some revisions, but the author information is removed and all of the dates are the same. I haven't had a chance to dig up a backup to see how severe the data loss is.

Is the old revision data still available in the DB? I haven't looked at all yet, but am happy to help troubleshoot.

[jeherve]

Thanks for jumping in!

Is the old revision data still available in the DB?

It should be, Jetpack doesn't delete anything during the migration process. You should be able to find all the revisions by searching for posts with the safecss post_name in wp_posts. You should see some posts with the safecss post type, and then a lot of revision post types for each revision.

I've been asking some folks to turn on WP_DEBUG and run through the 4.6.1 -> 4.7 upgrade again, hoping I'd get some info from the logs, but I haven't had any feedback on that yet.

[jeherve]

Sorry, I was wrong earlier. It's best to look for safecss as post_title, not post_name!

[jeremyfelt]

I jumped to conclusions too quickly earlier. It looks like the migration worked just fine! So I'm relieved, but bummed I don't have more data for you. :disappointed:

What fooled me is that new, only inline, stylesheet is output on wp_head at priority 11, which is the same hook and priority Make uses for inline styles. This causes the core CSS to be output before the Make CSS. Previously, Jetpack used priority 101, so it would always output after the Make CSS.

Off to core.trac to suggest a priority bump. :)

[georgestephanis]

This, however, is a different issue, and so far I've only seen it happen on sites where a theme broke or disabled Core's new CSS editor, thus leaving only the additional options added by Jetpack.

There have been some recommendations from third party sites that themes disable the Core implementation by removing it from the Customizer. In which case, maybe we should try and detect that with a late filter, and add in a notice that "While you have enabled Custom CSS in Jetpack, a theme or plugin has disabled this functionality. Sorry. :("

[alexjgustafson]

This, however, is a different issue, and so far I've only seen it happen on sites where a theme broke or disabled Core's new CSS editor, thus leaving only the additional options added by Jetpack

Had another user run into this issue, using the Blog Lady theme

2961562-t

[miragelimo]

I hate to sound like an idiot. A lot of this discussion is over my head. I just wanted to chime in that I lost some of my CSS customization when I updated to Vaughn. It looks like my background image disappeared. but only on desktop.
I know you said the old css is in my database. I have never been in there and not looking forward to going in there now.
I used the wayback machine and inspected the element. So I have the css that somehow got removed.
Just wanted you to know that this happened.
I had inadvertently used a .gif as my background image so maybe that is why it got stripped out. But it appears to be working fine on the mobile version.
I'll simply make it a .jpg and re-add it to my css. Hopefully that will solve it.
But now you have a record of someone else who lost css customization with this WP core update.
I also don't like working in the tiny screen. But I know there is another thread for that.

[stale[bot]]

This issue has been marked as stale. This happened because:

• It has been inactive in the past 6 months.
• It hasn’t been labeled `[Pri] Blocker`, `[Pri] High`.

No further action is needed. But it's worth checking if this ticket has clear reproduction steps and it is still reproducible. Feel free to close this issue if you think it's not valid anymore — if you do, please add a brief explanation.

[kraftbj]

Given the age of this and the reduced number of folks on these outdated versions of WP/Jetpack, going to close this one.