Viewing 2 posts - 1 through 2 (of 2 total)
  • Author
    Posts
  • February 11, 2026 at 6:53 pm #1494998
    M1000000

    We’re running Enfold 7.1.3 with WooCommerce on a SiteGround Cloud VPS and we’re seeing repeated database writes on every checkout page load that appear to be coming from Enfold’s per-post CSS management.

    Summary of the issue

    Our Checkout page is post ID 6494 (/checkout/).

    Enfold repeatedly executes an UPDATE against postmeta for this page:

    meta_key = ‘_av_css_styles’

    with serialized data including css_file = ‘post-6494.css’ and status = ‘no_css’

    The file post-6494.css is never created, despite Enfold generating other post-XXXX.css files normally.

    ——————————

    What we observe

    Enfold is successfully generating per-post CSS files in:

    wp-content/uploads/dynamic_avia/avia_posts_css/
    (multiple post-XXXX.css exist here, and the newest are generated today)

    An older legacy folder also exists:

    wp-content/uploads/avia_posts_css/
    (files exist, but last modified in 2023)

    post-6494.css does not exist in either location.

    Folder permissions are correct (directories 755, files 644).

    ——————————

    Query Monitor stack trace (from a frontend checkout request)

    UPDATE mjwp_postmeta
    SET meta_value = ‘… status:”no_css” … css_file:”post-6494.css” …’
    WHERE post_id = 6494
    AND meta_key = ‘_av_css_styles’

    update_metadata() wp-includes/meta.php:324
    update_post_meta() wp-includes/post.php:2746
    aviaPostCssManagement->update_meta() …/enfold/config-templatebuilder/avia-template-builder/php/class-post-css-management.php:557
    aviaPostCssManagement->check_create_file() …/class-post-css-management.php:268
    aviaPostCssManagement->handler_enqueue_post_styles() …/class-post-css-management.php:205
    do_action(‘wp_enqueue_scripts’) wp-includes/plugin.php:522
    …

    ——————————

    Impact

    During traffic bursts to checkout, these repeated meta updates contribute to additional DB load and resource usage (we had an autoscale event during a checkout load spike). Even if Enfold decides the page should be no_css, it seems to be re-writing the meta repeatedly instead of persisting a stable state and moving on.

    ——————————

    Questions

    Is Enfold expected to generate a post-6494.css file for WooCommerce checkout pages?

    If not, is there a recommended way to prevent aviaPostCssManagement->handler_enqueue_post_styles() from continually updating _av_css_styles for checkout pages?

    Is this a known behavior/bug in the current Enfold/Avia CSS management layer when a page is treated as no_css?

    Are there settings (or a filter/hook) to disable per-post CSS management for specific post IDs or for is_checkout() pages?

    If you’d like, we can provide the full serialized _av_css_styles value and/or additional logs.

    Thanks!

    February 12, 2026 at 6:44 am #1495016
    Ismael

    Hey M1000000,

    Thank you for the inquiry.

    The post css files should only be generated when creating or updating a page. They should not be generated on page load unless the file is not yet available, which is probably the case here since it fails to generate. To exclude the checkout page from generating the dynamic css file, you can try adding the following code to your functions.php file.

    add_filter( 'avf_post_css_create_file', function( $create ) {
    if ( is_singular() && get_the_ID() === 6494 ) {
        return false;
    }

    return $create;
});

    Let us know how it goes.

    Best regards,
    Ismael

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