Hi Ismael,

our containers share both database and upload directory. So only if a plugin or theme would create ephemeral data in its plugin directory ( not shared between containers) it may become a problem, but this is considered bad practice anyway.

So we have in wp-options:
avia_stylesheet_dynamic_versionenfold (hash)
avia_stylesheet_dynamic_versionenfold_child (hash)
avia_stylesheet_dynamic_versionenfold-child (hash)
avia_stylesheet_existsenfold true
avia_stylesheet_existsenfold_child true
avia_stylesheet_existsenfold-child true

If doing wp eval ‘avia_generate_stylesheet();’, only one option value changes ( avia_stylesheet_dynamic_versionenfold_child ) , and only one file is refreshed ( wp-content/uploads/dynamic_avia/enfold_child.css )

If saving options manually, a lot more files are refreshed :
./wp-content/uploads/dynamic_avia/avia-gutenberg-dynamic-enfold_child.css
./wp-content/uploads/dynamic_avia/avia-merged-styles-15236a5ae6d86a1f9e74a9ba518a7c4c—68790b12ce27d.css
./wp-content/uploads/dynamic_avia/enfold_child.css
./wp-content/uploads/dynamic_avia/avia_posts_css/(*.css) – many files

So currently we are running wp eval ‘avia_generate_stylesheet();’ upon every deployment, and so far have not seen de-synced css. But there have been only 3 deployments – not enough to be sure it works.

I would still like to know whether there are better/more reliable ways to refresh the necessary CSS files. I could as well run mulitple WPCLI commands, if a developer would tell me which hook, action or function to use after deployment.

regards
ulrich

Thanks Ismael,

I think I need to better understand the root cause of the “missing CSS ” issue to find a solution.

Since our uploads folder is persistent across deployments, I would expect the CSS would still work, but very often (not every time) it does not and the site looks broken.
Why would Enfold not find and use the existing old dynamic/cached CSS and require the re-save process?

Regarding the trigger: you list a couple of activities causing the CSS to be re-saved. All these are , as far as I see, manual tasks to be done in the Admin GUI backend.
Is there no way to achieve the re-save programatically ( wp-cli ) ? If not, this would be a very desirable feature.

Otherwise, we could try to find a better workaround. Which wpcli commands could be used to trigger CSS regeneration? I could then simply do a wp eval ‘do_action(“the_hook_that_triggers_css_saving”);

Other commands that come to mind:
directly calling avia_generate_stylesheet(); with wp eval ?
re-saving options with wp option update … , if that will trigger the css?
wp option update avia_options “$(wp option get avia_options)”

You problably know best what is the most promising path …

Regards
Ulrich

Unfortunately not, even with debug enabled. As you may have seen in our environment, it looks as if the edit page simply does not load completey or does not render completely. Are there any debug flags that can be set for the React / JS part of the setup? Or will there be an update of the builtin layerslider version in the near future? If so, we could put the issue on hold for a short period.

Like I already said, the problem is also on a staging site that is a clone of the live site. Actually the clone was performed with WP-Staging ( problem still present) and then all pending Updates (Enfold and others) were performed in the clone (problem still present). What exactly do you mean by “export your project”?

If you mean exporting all sliders, and re-importing: I just did so, with no success:
1 – importing a zip of sliders into the staging clone with 6.x Enfold containing LS 7.12.x
2- importing a zip of sliders into the upgraded staging clone 7.1.1 Enfold containing LS 7.14.4
3- disabling all plugins that might interfere with editing, like ACF, RankMath , contentViews,

None of these steps were successful. It is still not possible to edit any of the slides. I include a site report in the private area.