#59223 closed defect (bug) (duplicate)
Block styles missing when using symlink and separate core block assets
Reported by: | lukasbesch | Owned by: | |
---|---|---|---|
Milestone: | Priority: | normal | |
Severity: | normal | Version: | 6.3 |
Component: | Themes | Keywords: | |
Focuses: | Cc: |
Description
I noticed core block styles were missing, but only on production/staging.
It could be temporarily fixed by setting the should_load_separate_core_block_assets
filter to false or by deleting the transient wp_core_block_css_files
. This is what I found out:
The theme was a custom block theme, but even after switching to Twenty Twenty Three the problem remained.
I am deploying my sites using Trellis: there is a release directory for every release, and current
symlink that will be updated once the deployment succeeded.
After deploying, I also pushed my database and search/replaced URL/Domain. The path to WordPress stays the same (/srv/www/examplesite/current
), with one difference:
Locally, current
is an actual directory.
On the remote server, it is a symlink pointing to the release (e.g. /srv/www/examplesite/releases/20230828160120
).
That seems to break something in the function register_core_block_style_handles
.
After deleting the transient wp_core_block_css_files
, it works again.
The transient is deleted during WordPress upgrades.
Example before deleting:
$ wp transient get wp_core_block_css_files array ( 0 => '/srv/www/examplesite/current/web/wp/wp-includes/blocks/archives/editor-rtl.css', ...
Example after deleting/regenerated version:
$ wp transient get wp_core_block_css_files array ( 0 => '/srv/www/examplesite/releases/20230828160120/web/wp/wp-includes/blocks/archives/editor-rtl.css', ...
I know this is very much an edge case, and you're probably supposed to delete the transients anyway after migrating a database. But still, I wanted to report it.
Change History (3)
#2
@
17 months ago
- Resolution set to duplicate
- Status changed from new to closed
Hi @lukasbesch
Thanks for the ticket and the detailed description. The issue with the wp_core_block_css_files
transient breaking if the path changed is already tracked in #59111 where a patch is being tested.
I'm going to close this issue as duplicate. Feel free to continue the discussion in #59111.
Thanks again for reporting this issue !
This problem happens after every deployment, as the release path changes every time. Maybe there should be a check if the base path is still valid. Right now, the transient has no expiration date and will only be regenerated on upgrades.