Importing a WP 6.3 exported site with block theme results in CSS problems [with solution]

Bugs
1

Bug Summary

Importing a WordPress 6.3 site with a block theme results in CSS not being loaded on the front end of the website with consequent display problems.

Steps to reproduce

Export a Local Site that runs WordPress 6.3 with a block theme. Re-import the exported site file to a new sitename. In the site editor the display will look fine. On the front end of the website the display will show problems due to CSS not being loaded.

This appears to be a result of a new WordPress 6.3 feature that creates a transient called ā€˜_transient_wp_core_block_css_filesā€™ in the wp_options table. This looks like it is used to cache a list of CSS files to load when using WordPress blocks. Localā€™s current process to rename the imported site do not appear to handle this, so the transient retains data for the original site. The solution is simply to delete the transient which forces WordPress to recreate it with correct data.

Environment Info

Problem the same on Linux and Windows 10. Solution works on both platforms.

2

Hi @nickt

I just tested pulling a site on WordPress 6.3 using the blocksy theme. I got it loaded into Local, exported it, and then imported that zip back but so far I havenā€™t been able to replicate the missing CSS issues.

Are you using a specific block theme or child theme? Or have you tested multiple?

3

Please check if the new WP_DEVELOPMENT_MODE constant might be of help here to bypass the caching mechanism.

4

Itā€™s using a block theme based on the ā€œBasicā€ theme from FullSiteEditing.com. The behaviour is not consistent. In our dev group of 7, 3 confirmed the issue and the others did not. So I suspect it may be that the transient does not always get written?

1 Like
5

The SAME Thing happen to me on SiteGround. They did a FIX.

My environment was WP 6.3 + 2023 Theme ā€¦ and can be re-created with No Plugins being used.

I originally reported the issue to SiteGround on August 2nd.

My SiteGround Correspondence follows HERE (This is After they did Fix) ā€¦

Aug 11, 2023 05:01 PM (Me to SiteGround)

Hi SiteGround People,
QUESTION: Did you guys fix the Staging issue? Staging is working Normal now again for me!

I just did a bunch of tests, and results are good each time.

Even the Live sites (I had problems with before), are working now.
ā—‹ The original Staging Copy is still there with the problem.
ā—‹ When I create a New Staging Copy of the Live site, that New Staging Copy is good!
ā—‹ I made NO Changes to the Live site, but when I re-stage, it works now!

So QUESTIONS: Did you find something? Did you change something? What was it?

I am very interested, because I was able to re-create the problem with ā€œWPEngineā€™s LOCALā€ environment.

When I use LOCAL

  1. Create bare minimum 6.3 site with 2023 Theme.
  2. Install NO Plugins.
  3. View Site (Everything is Good So Far).
  4. Clone Site in LOCAL Environment.
  5. View Site (Formatting/Settings have been LOST).

I just tested the above LOCAL process again, and problem is still there in LOCAL ā€¦ But things work with SiteGround Staging!

Thank you very much,
Larry

Aug 11, 2023 11:03 PM (SiteGround to Me)

Hello Larry,

I am glad to inform you that our team found a fix for the reported problem and already deployed it on all of our servers. The *solution essentially deletes the following transient record ā€œwp_core_block_css_filesā€ from the _options table. Regrettably, I am not able to provide more detailed information on the matter.

Thank you for your cooperation!

The ticket will now be marked as closed and if you need any other assistance, you can request such from here or use the Help Center.

Best Regards,
SiteGround
Senior Technical Support

6

Screenshots of what Issue causes ā€¦

2023-08-09_165116_ver001
2023-08-09_165116_ver0011362Ɨ943 87.6 KB

2023-08-09_165302_ver001
2023-08-09_165302_ver0011362Ɨ943 63.8 KB

2023-08-10_122459
2023-08-10_1224591034Ɨ852 88.3 KB

2023-08-10_122521
2023-08-10_1225211036Ɨ853 86.1 KB

1 Like
7

I updated my live site to WP6.3 with twenty twenty-three theme 1.2, and imported into Local.
When I open the site in Local, the navigation block configured as an overlay menu stays exploded and not working as an overlay. Iā€™ve tried changing ā€œoverlayā€ setting of the navigation, deleting the navigation and reinserting, so on and so forth, but it doesnā€™t seem to change the outcome.

Is this a WP and 2023 theme issue, or a Local issue?
Things look fine in my live site, even though the widths of separator blocks changed when I updated from WP6.2 to 6.3, and I had to reset them manually. So far that was the only issue in my live site.

I appreciate if someone could offer some insight on this issue.

System Details

Local 7.1.2+6410 running on Win 10 22H2.

1 Like
8

I have set the WP_DEVELOPMENT_MODE constant in the wp-config.php file for all my local and staging websites and it looks like the problematic transient isnā€™t generated in the wp_options table so this might be the solution instead of having to delete the transient manually.

/** Set development mode */
define('WP_DEVELOPMENT_MODE', 'all');
3 Likes
9

The WordPress plugins WP-Sweep and Transients Manager (not tested with WordPress 6.3) can be used to delete transients in the database. Use with caution!

10

I can confirm (at least on my end), that what @emmtre found & does, consistently works for me and avoids the issue.

I consistently had the problem (WP 6.3 with: theme 2023 & theme Ollie). I had the problem using Cloning & Blueprints.

Adding to the wp-config.php file define(ā€˜WP_DEVELOPMENT_MODEā€™, ā€˜allā€™); allows Cloning & Blueprints to work.

According to the documentation @emmtre referenced (Configuring development mode in 6.3)

ā€œsetting a development mode is only relevant for sites where any kind of development is occurring. For example, it is not advised or relevant to use on a production site.ā€

So I will have to pull the statement whenever I migrate to production & then put statement back in when I work in development! I donā€™t understand fully the details of all of this, but it seems at minimum that this change with 6.3 should be made well known -or- a more automatic & transparent solution be derived.

Thanks @emmtre ā€¦ it helps me a lot!

2 Likes
11

@Local_Larry No problems and thanks for the confirmation that it worked with your themes as well.

1 Like
12

Thanks for the help in hunting this down team, especially @emmtre!

It sounds like there are multiple ways to handle it. We could delete the transient on the flyā€¦ or set that DEVELOPMENT_MODE and go from there.

It does seem this is an issue with WordPress 6.3 as it isnā€™t specific to Local, and as mentioned above, has been on other hosts as well. I wonder if this is on the communityā€™s radar at all? Or if this is just the new way WordPress works and changes should be made on our end to accommodate. :slight_smile:

1 Like
13

What issue or error are you experiencing?

Hi Guys,

Iā€™m having an odd experience using Local on PC while developing my custom WP site.

At first, I thought it was some custom code I have added, but now I am thinking itā€™s a possible bug in the software.

Hereā€™s whatā€™s happening: -

Iā€™m developing a large WP site using local and have periodically been exporting from my PC to my Apple laptop for portability. This has not been an issue until recently when my navbar switched to mobile view by default and I was not able to change it back to desktop view regardless.

The navbar uses a navigation block with a few links, nothing fancy. I have tried deactivating all my plugins, removing my custom code and literally stripping the site back to the navbar itself, still with mobile view by default.

By this I mean the overlay is showing when set to mobile only, and the nav links have dropped style and are showing as an unordered list with bullet points. Again, I thought this might be an issue with the theme or some plugin, or some custom code. So, I installed a fresh version of WP and made a basic navigation on the sample page with nothing else.

I loaded the page, and it looked fine, I then exported the site as a zip file and reimported the same file and the mobile view was there on the nav as per my website. Not, my website is working fine, but if I export and reimport it, eg transfer to another machine it defaults to the mobile only view for the nav.

Please advise of any solutions for this?

Thanks,
KD

What steps can be taken to replicate the issue? Feel free to include screenshots, videos, etc

To replicate:-

  1. Spin up a new wordpress 6.3 site
  2. Use the TwentyTwentyThree default theme
  3. Add a navigation block to a page
  4. Add a few links to simulate the nav categories
  5. View the site and confirm it is working correctly
  6. Export the site as a zip file using Local running on Windows
    7 Import the same zip file and give a different name, eg [name]-test
    8 View the site and confirm that the navbar has imploded, dropping all styles and showing the mobile overlay button

System Details

Windows 10 Pro
Wordpress 6.3

  • Local Version:
    7.1.2+6410

  • Operating System (OS) and OS version:
    Windows 10 Pro

Local Logs

Attach your Local Logs here (Help Doc - Retrieving Localā€™s Log)

Security Reminder
Local does a pretty good job of scrubbing private info from the logs and the errors it produces, however thereā€™s always the possibility that something private can come through. Because these are public forums, always review the screenshots you are sharing to make sure there isnā€™t private info like passwords being displayed.

14

Hi @designmindz - thanks for reaching out!

We merged your post into this larger thread here - see above for a solve (either, adding define('WP_DEVELOPMENT_MODE', 'all'); to your wp-config.php file or by removing the transient value from the wp_options table in the database, which WordPress will then regenerate for you).

My take - I feel like this is a bug in WordPress 6.3, but something we can definitely handle better, so weā€™re taking a look at our options.

15

This was a lifesaver!

1 Like
16

Just following up here with some more info - this is indeed an issue in WordPress and a Trac ticket is open for it - #59111 (A stale register_core_block_style_handles cache can cause styles not to load) ā€“ WordPress Trac

In the meantime, an even easier fix is noted in that ticket - Opening a Site Shell in Local for the sites affected and running this command will resolve the issue:
wp transient delete wp_core_block_css_files

Weā€™ll stay on top of that Trac ticket and keep pushing it along where we can.

4 Likes
17

This worked for me. Thank you!

2 Likes
18

@austinwendt This issue also exists in the reverse direction (pushing from Local to Staging on Flywheel, for example). Unfortunately, the fixes presented do not resolve the issue when pushing from Local. Iā€™ve deleted the transient on the Staging DB and set the development mode, but it has no effect.

19

Have you tried flushing the server cache for Staging? Do you have any other theme or plugin cache/css that needs to be reset?