Widgets Bundle carousel CSS not enqueued on the static front page

Bug: SO Widgets Bundle carousel CSS not enqueued on the static front page (WordPress 7.1)

Summary

After upgrading WordPress from 6.8.8 to 7.1, the CSS assets required by `sow-anything-carousel` widgets (Slick + carousel-specific stylesheets) stop being enqueued **only on whichever page is set as the static front page** under Settings → Reading. The exact same widget, with identical content, works correctly on any other (non-front-page) page using the same template.

Environment

– WordPress: 7.1 (issue appeared immediately after upgrading from 6.8.8)
– Page Builder by SiteOrigin: 2.36.0
– SiteOrigin Widgets Bundle: 1.74.2
– Theme: custom theme (not a SiteOrigin theme)
– Other active plugins: Yoast SEO, Duplicate Post (ruled out via conflict testing — see below)

Steps to reproduce

1. Create a page with two `sow-anything-carousel` widgets added via Page Builder (Anything Carousel widget).
2. Set that page as the static front page under Settings → Reading.
3. View the page while logged out (and logged in) in any browser.
4. Compare the “ output to the same page when it is **not** set as the front page (e.g. duplicate the page, or temporarily set a different page as the front page).

**Expected:** the following are enqueued and present as “ tags in “:
– `slick.css` (`/wp-content/plugins/so-widgets-bundle/css/lib/slick.css`)
– `anything-carousel/css/style.css`
– The per-instance generated stylesheet(s) under `/wp-content/uploads/siteorigin-widgets/sow-anything-carousel-base-{hash}-{page_id}.css`

**Actual:** none of the above are enqueued when the page is the front page. All other page-specific SiteOrigin Panels CSS (`siteorigin-panels-front-css`, the inline `#pl-{id}` layout styles) load correctly. The widget HTML itself renders correctly and completely (all carousel items, images, and text are present in the page source) — only the stylesheet “ tags are missing, so the carousel displays unstyled (items stacked, no slick positioning, no arrows/dots layout).

What we’ve ruled out

– **Caching:** no caching plugin installed; issue reproduces in multiple browsers (Chrome, Firefox) and incognito/logged-out sessions.
– **Theme templates:** issue persists regardless of which page template is assigned to the front page (custom `page.php`, a custom “Landingpage” template that doesn’t even call `get_header()`/`get_footer()` the same way). Reassigning templates makes no difference.
– **It’s tied purely to the “is front page” designation, not to page ID or content:** duplicating the front page and testing the duplicate (not set as front page) shows no issue. Setting an entirely different, unrelated page as the front page reproduces the same missing-CSS symptom on that page instead.
– **Generated CSS file itself:** the per-instance file (`sow-anything-carousel-base-{hash}-{page_id}.css`) exists on disk with correct content. Manually deleting it causes SiteOrigin to regenerate it correctly — but it is still never linked in “ when the page is the front page.
– **JS errors:** browser console is clean (only the standard jQuery Migrate notice).
– **PHP errors:** `WP_DEBUG_LOG` shows nothing related to SiteOrigin/Panels — only an unrelated deprecated-hook notice from our own theme’s `rest_enabled` filter.
– **Plugin conflicts:** Both SiteOrigin plugins are up to date (Page Builder 2.36.0, Widgets Bundle 1.74.2). No SiteOrigin-specific “Home Page” builder setting is present/enabled in our install.

Suspected cause

We noticed that WordPress 7.1 introduces a new core mechanism, `wp_hoist_late_printed_styles()`, visible via placeholder comments it leaves in “:

html

<style id="wp-block-styles-placeholder-inline-css">
:root { --wp-internal-comment: "Placeholder for wp_hoist_late_printed_styles() to replace with the block styles printed at wp_footer." }
</style>

Since SO Widgets Bundle needs to inspect the actual Panels layout data to know which widget-specific CSS to enqueue, and that inspection can only happen once widgets are rendered during `the_content()` (i.e., after `wp_head()` has already fired), we suspect SO Widgets Bundle’s own mechanism for hoisting late-registered styles into “ may be interacting badly with this new WP 7.1 core hoisting mechanism — specifically in a way that only manifests on the front-page request. We were not able to confirm this in the plugin source, but it’s the most consistent explanation for what we’re seeing.

Current workaround

We’re currently forcing the missing stylesheets to enqueue manually via a `functions.php` snippet, targeted only at `is_front_page()`:

php
add_action( 'wp_enqueue_scripts', function() {
    if ( is_front_page() ) {
        wp_enqueue_style( 'slick', WP_PLUGIN_URL . '/so-widgets-bundle/css/lib/slick.css', array(), '1.8.1' );
        wp_enqueue_style( 'sow-anything-carousel', WP_PLUGIN_URL . '/so-widgets-bundle/widgets/anything-carousel/css/style.css', array(), '1.74.2' );
        wp_enqueue_style( 'sow-carousel-home-1', content_url( 'uploads/siteorigin-widgets/sow-anything-carousel-base-bce3a72a55c8-13.css' ) );
        wp_enqueue_style( 'sow-carousel-home-2', content_url( 'uploads/siteorigin-widgets/sow-anything-carousel-base-96fe56b154c3-13.css' ) );
    }
}, 20 );

This resolves the visual symptom but is fragile — the per-instance filenames contain a hash that changes whenever the widget is edited/re-saved, so the hardcoded URLs need to be updated manually each time. We’d much prefer a real fix so we can remove this patch.

Request

Could someone from the SiteOrigin team confirm whether:
1. There’s a known interaction between SO Widgets Bundle’s style-enqueue timing and WordPress 7.1’s `wp_hoist_late_printed_styles()`, and
2. Whether the front-page-specific asset detection (whatever check differentiates a front page request from a regular page request in the enqueue logic) has a known edge case in the current release.

Happy to provide a site URL, further debug output, or test a patched build if that helps track this down.