We are experiencing a recurring problem where our site's ui patterns are broken after deploying new code to our live environment on pantheon. When someone visits the site after a release, the css files for the patterns cannot be loaded and it takes a series of cache clears before things return to normal.
After some digging, it appears that this is likely due to the fact that the ui_patterns module is storing the absolute path to the patterns in the caches, which on cloud hosting environments look something like: /srv/bindings/59a55e0d10ad4961ab2ac98294d4f6b7/code/web/themes/custom/theme_name/patterns/organisms/pattern_name
When a deployment is done on Pantheon, the storage for the code base is swapped out, and that binding id changes to another long series of random letters and numbers. However, since the old binding id is stored in the cache_discovery table, the ui_patterns module keeps looking for the resources in the old path, and the urls for the css files end up being served using the wrong paths.
This issue should be resolved by storing the base path for the patterns in relation to the drupal site root instead of the server root.
We are experiencing a recurring problem where our site's ui patterns are broken after deploying new code to our live environment on pantheon. When someone visits the site after a release, the css files for the patterns cannot be loaded and it takes a series of cache clears before things return to normal.
After some digging, it appears that this is likely due to the fact that the ui_patterns module is storing the absolute path to the patterns in the caches, which on cloud hosting environments look something like: /srv/bindings/59a55e0d10ad4961ab2ac98294d4f6b7/code/web/themes/custom/theme_name/patterns/organisms/pattern_name
When a deployment is done on Pantheon, the storage for the code base is swapped out, and that binding id changes to another long series of random letters and numbers. However, since the old binding id is stored in the cache_discovery table, the ui_patterns module keeps looking for the resources in the old path, and the urls for the css files end up being served using the wrong paths.
This issue should be resolved by storing the base path for the patterns in relation to the drupal site root instead of the server root.