Viewing 9 posts - 1 through 9 (of 9 total)
  • Author
    Posts
  • #1486798

    Hi,
    recently we migrated an Enfold site into our Docker environment where we deploy our wordpress sites using CI/CD tools. The move solved a problem we had with the builtin Layerslider, but now a one came up:

    After deployment, the site looks defaced due to missing dynamically generated CSS files. We then have to manually go to the theme option settings page wp-admin/admin.php?page=avia and save the settings (even without changing values) to resolve this.

    Our uploads folder is persistent, so the content of uploads/dynamic_avia/… with files like avia-merged-styles-ddf276684ae525538791a02cb0e618c9—687602ac906a5.css survives deployments, but it seems as if after deployment the old dynamic css are not being used so reset/regeneration is necessary.

    How can we ensure that the CSS are generated upon deployment, mabye using a WPCLI action to enforce CSS generation? Or can/should we simply delete the wp-content/uploads/dynamic_avia/ folder?

    Also, if we run more than one WordPress container (in case of high load) sharing a common uploads directory, will the dynamic file names interfere?

    REgards
    Ulrich

    #1486846

    Hey onlineprodcontent,

    Thank you for the inquiry.

    The dynamic css will be generated during these instances: importing a demo, saving the theme options, updating a page or toggling the file compression settings. We recommend to toggle or temporarily disable the file compression upon deployment or resave the theme options to regenerate the required resources.

    Unfortunately, we can’t provide more details about the Docker setup because we’re not familiar with your compose settings. However, based on your description, each WordPress container is a clone of the original that shares the same volume, so it’s possible that a conflict occurs with the dynamic stylesheets. Are the WP containers accessible separately? Can you save the theme options for each container individually?

    Best regards,
    Ismael

    #1486864

    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

    #1486867

    PS: I just did a simple wp eval ‘avia_generate_stylesheet()’

    This re-created
    ./wp-content/uploads/dynamic_avia/enfold_child.css

    Will that be sufficient to avoid the site looking broken? Since currently the “broken” problem did not occur, I could not verify that this is what is needed.

    #1486910

    Hi,

    Why would Enfold not find and use the existing old dynamic/cached CSS and require the re-save process?

    Do the containers also share the same database? Please note that the theme relies on a database entry to generate the dynamic stylesheets and scripts. So, if each of your WordPress containers has its own unique database, a desync will likely occur in the shared uploads directory or volume from one of the WordPress instances. It will only work correctly on the instance where the theme options were saved last because that action triggers the file generation and saves the correct entry in the database in favor of the instance.

    Yes, the function avia_generate_stylesheet should regenerate the dynamic stylesheet, but we haven’t tested this on WP-CLI. You can try running it in each deployment to see if it correctly resolves the issue with the missing stylesheet.

    Best regards,
    Ismael

    #1486935

    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

    #1486955

    Hi,

    You can check out the functions in these files:

    — enfold/includes/config-enfold/functions-framework.php > avia_generate_stylesheet
    — enfold/config-templatebuilder/avia-template-builder/php/class-asset-manager.php > try_minifying_scripts | minimize_footer_scripts
    — enfold/config-gutenberg/class-avia-gutenberg-theme-integration.php > handler_generate_dynamic_stylesheet
    — enfold/config-templatebuilder/avia-template-builder/php/class-post-css-management.php > handler_enqueue_post_styles

    These functions are hooked into:

    
    add_action( 'ava_ajax_cet_delete', 'callback', 10, 1 );
    add_action( 'ava_after_theme_update', 'callback', 100, 1 );
    add_action( 'ava_after_import_demo_settings', 'callback', 100, 1 );
    add_action( 'avia_ajax_after_save_options_page', 'callback', 100, 1 );
    add_action( 'wp_enqueue_scripts', 'callback', 999999 );
    add_action( 'wp_print_footer_scripts', 'callback', 9 );
    

    Best regards,
    Ismael

    #1487069

    Thanks very much Ismael for your list. I will now use
    wp --user="admin.user" eval "do_action('avia_ajax_after_save_options_page');"
    and see how it goes.

    As far as I see, in the context of wpcli execution, not all possible callbacks for
    ‘avia_ajax_after_save_options_page’ are present, only these are executed:
    Function: avia_generate_stylesheet
    Method: av_responsive_images->handler_ava_reset_db_options
    Function: avia_reset_merged_assets
    Method: aviaPostCssManagement->handler_ava_reset_css_files
    Due to lacking context, the handler_* calls do nothing in this case, but I will see how it goes with this workaround.

    Regards Ulrich

    #1487095

    Hi,

    We’ll keep the thread open. Let us know if you have any more questions and keep us updated.

    Best regards,
    Ismael

Viewing 9 posts - 1 through 9 (of 9 total)
  • You must be logged in to reply to this topic.