Custom CSS stops applying after SPA navigation (iAPI / WordPress 7)

  • Marcus

    (@power2009)


    1 week, 5 days ago

    Hi Complianz Team,

    I’m reaching out to report a compatibility issue between Complianz dynamically injected custom CSS and the new WordPress Interactivity API (@wordpress/interactivity-router), which is becoming a core part of frontend navigation in WordPress 7.

    The Bug When a site uses the iAPI router for SPA-like client-side navigation (using data-wp-router-region), any custom CSS applied by Complianz (e.g., custom banner styling from the CSS editor) silently stops working after the first navigation.

    The tricky part is that the <link> or <style> node remains visible in the DOM Inspector, so it looks like it’s there. However, in DevTools → Sources → Page, the stylesheet disappears from the loaded resources. The browser’s style engine simply drops it, with zero console errors.

    The Root Cause Currently, Complianz injects custom styles by appending <link> elements to <head> via JavaScript (document.head.appendChild()), bypassing the standard WordPress wp_enqueue_style() system and pulling assets from the uploads/complianz/css directory.

    The iAPI router performs a head-merge diff during navigation. Because Complianz styles are injected client-side and are absent from the server-rendered HTML, the router’s applyStyles() function catches them in an unconditional else { el.sheet.disabled = true } block and disables them.

    This exact issue is documented in detail in this Gutenberg PR: 👉 Fix: interactivity-router preserve dynamically-injected and deferred stylesheets across navigations #76289

    Specifically, the section titled “B — dynamically-injected plugin stylesheets disabled on navigation” describes the Complianz use-case exactly:

    “Plugins like Complianz GDPR append <link> elements via document.head.appendChild(), bypassing wp_enqueue_style(). These elements are absent from every server-rendered response… The unconditional else { el.sheet.disabled = true } in applyStyles() catches them on the first navigate() — consent banner CSS, accessibility overlays, anything injected outside WP’s enqueue system stops working silently.”

    The Proposed Solution / Modernization I understand that the Core team is working on a fix on the router side (the PR linked above introduces a routerManagedStyles Set that ignores elements without standard WP id attributes, which should protect Complianz styles in future WP versions).

    However, relying on client-side appendChild() to load CSS from the uploads directory feels like a legacy approach that clashes with modern WordPress architecture. As WP moves towards SPA navigations and stricter hydration lifecycles, scripts and styles need to be registered properly.

    Would you consider updating your architecture to use the standard WordPress enqueueing system (wp_enqueue_style)? If a user adds custom CSS, it would be much more robust and future-proof to:

    1. Enqueue the stylesheet properly via PHP with media="all", or
    2. Output the custom CSS inline within a standard <style id="complianz-custom-css"> tag during the wp_head or wp_footer PHP rendering phase.

    This ensures the router and other modern block-editor features recognize the assets as part of the server-rendered state, preventing them from being unloaded during navigation.

    I’d love to hear your thoughts on this. Is there a specific reason the uploads/complianz/css + JS injection method was chosen over standard WP enqueuing? With WP 7 in its RC stages, adapting to the standard enqueue pipeline seems like the right move for plugin sustainability.

    Thanks for your great work on the plugin!

    The page I need help with: [log in to see the link]

Viewing 1 replies (of 1 total)
  • Plugin Support Antonio Candela

    (@antoiub)

    23 hours, 15 minutes ago

    Hi @power2009,

    Thank you so much for taking the time to put together such a detailed and well-researched report. We already have an internal task open regarding this issue, so it’s on our radar. That said, I’ve personally forwarded your proposed solution to our development team, so they can take your input into account when working on the fix.

    I’ll keep you posted as soon as I have any concrete update from their side.
    Thanks again, feedback like this genuinely helps us improve the plugin!

    Kind regards,
    Antonio

Viewing 1 replies (of 1 total)

You must be logged in to reply to this topic.