Title: Real-time JS initialization after server-side blocking
Last modified: August 12, 2026

---

# Real-time JS initialization after server-side blocking

 *  Resolved [andyt1980](https://wordpress.org/support/users/andyt1980/)
 * (@andyt1980)
 * [4 days, 15 hours ago](https://wordpress.org/support/topic/real-time-js-initialization-after-server-side-blocking/)
 * Hi PixelYourSite Team,
   We use your PHP filters to block tracking before consent:
 *     ```wp-block-code
       add_filter( 'pys_disable_by_gdpr', '__return_true' );
       add_filter( 'pys_disable_all_cookie', '__return_true' );
       ```
   
 * This successfully prevents `pys_*` and `_fbp` cookies on initial page load.
 * However, because PHP strips the PYS JavaScript files from the DOM entirely, calling`
   pys.init()` when a user clicks **“Accept All”** does nothing—the PYS scripts 
   aren’t present yet. Currently, cookies only fire if the user manually reloads
   or navigates to another page.
 * **Questions:**
    1. Is there an official way to dynamically load/initialize PYS via JavaScript upon
       consent without requiring a page refresh?
    2. Does PYS support native client-side consent management (e.g., loading the JS
       assets but keeping cookies/tracking dormant until a WP Consent API opt-in event
       fires)?
 * Thanks!

Viewing 2 replies - 1 through 2 (of 2 total)

 *  [ehamati](https://wordpress.org/support/users/ehamati/)
 * (@ehamati)
 * [2 days, 14 hours ago](https://wordpress.org/support/topic/real-time-js-initialization-after-server-side-blocking/#post-18993546)
 * [@andyt1980](https://wordpress.org/support/users/andyt1980/) First, a correction
   to the premise: PYS does not strip its JavaScript when those filters return `
   true`. `public.js` is enqueued unconditionally. The filters only set two flags
   inside the localized `pysOptions` object — `gdpr.all_disabled_by_api` and `cookie.
   disabled_all_cookie`. The script reads these flags and skips pixel initialization
   and cookie writing. The assets are already loaded on the page but remain dormant.
 * `pys.init()` does nothing because no such method exists. 
   Here is the supported
   flow:1. Make your filters consent-aware instead of hardcoding `true`
 *     ```wp-block-code
       function my_has_consent() {
           return isset( $_COOKIE['my_consent'] ) && $_COOKIE['my_consent'] === 'accepted';
       }
   
       add_filter( 'pys_disable_by_gdpr', fn() => ! my_has_consent() );
       add_filter( 'pys_disable_all_cookie', fn() => ! my_has_consent() );
       add_filter( 'pys_check_consent_by_gdpr', fn( $c, $pixel ) => my_has_consent(), 10, 2 );
       ```
   
 * 2. Enable the AJAX filter refresh
 * Go to **PYS → Settings → Consent → For Developers → “Enable AJAX filter values
   update”**, or enable it programmatically:
 *     ```wp-block-code
       add_filter( 'pys_gdpr_ajax_enabled', '__return_true' );
       ```
   
 * This makes PYS re-query the current filter values at runtime and also helps avoid
   issues caused by stale page-cache values.
   3. Re-initialize on “Accept All” — 
   no page reload is needed
 *     ```wp-block-code
       document.cookie = 'my_consent=accepted; path=/; max-age=31536000; SameSite=Lax';
   
       if ( window.pys && window.pys.Utils ) {
           window.pys.Utils.manageCookies();
           window.pys.Utils.loadPixels();
       }
       ```
   
 * `loadPixels()` re-reads the PHP filter values, initializes every allowed pixel,
   and fires the static events queued for the current page (such as PageView). The`
   _fbp` cookie is created at that point.
   **Native client-side consent management:**
 * There is no generic WP Consent API integration. PYS has native real-time integrations
   with **[Consent Magic](https://www.pixelyoursite.com/plugins/consentmagic?_gl=1*awn5cs*_up*MQ..*_ga*MTMzMjAwNzQ3MC4xNzg2NzA4NjQy*_ga_CVH62VM7BW*czE3ODY3MDg2NDIkbzEkZzAkdDE3ODY3MDg2NDIkajYwJGwxJGg1NTM0NjAzOQ..)**(
   recommended), Cookiebot, Cookie Notice, CookieYes, and Real Cookie Banner. With
   these integrations, the JavaScript loads, but the pixels remain dormant until
   the appropriate consent event occurs, without requiring a page reload.
 * For Google tags, see **Google Consent Mode** support in the GDPR tab. This is
   the recommended “load but keep denied” approach for GA4 and Google Ads.
 * One important point to flag: the `pys_disable_*_by_gdpr` filters control the 
   browser-side behavior. Server-side Conversions API events are gated separately
   and default to granted when no supported consent plugin is detected. Therefore,
   with a fully custom consent banner, CAPI events may still be sent.
 * The `pys_check_consent_by_gdpr` filter in step 1 addresses this by explicitly
   applying your custom consent state to the server-side events as well.
 *  Thread Starter [andyt1980](https://wordpress.org/support/users/andyt1980/)
 * (@andyt1980)
 * [2 days, 6 hours ago](https://wordpress.org/support/topic/real-time-js-initialization-after-server-side-blocking/#post-18993952)
 * Many thanks for the detailed and helpful response, this is now resolved.

Viewing 2 replies - 1 through 2 (of 2 total)

You must be [logged in](https://login.wordpress.org/?redirect_to=https%3A%2F%2Fwordpress.org%2Fsupport%2Ftopic%2Freal-time-js-initialization-after-server-side-blocking%2F%3Foutput_format%3Dmd&locale=en_US)
to reply to this topic.

 * ![](https://ps.w.org/pixelyoursite/assets/icon-256x256.jpg?rev=3178123)
 * [PixelYourSite - Your smart PIXEL (TAG) & API Manager](https://wordpress.org/plugins/pixelyoursite/)
 * [Frequently Asked Questions](https://wordpress.org/plugins/pixelyoursite/#faq)
 * [Support Threads](https://wordpress.org/support/plugin/pixelyoursite/)
 * [Active Topics](https://wordpress.org/support/plugin/pixelyoursite/active/)
 * [Unresolved Topics](https://wordpress.org/support/plugin/pixelyoursite/unresolved/)
 * [Reviews](https://wordpress.org/support/plugin/pixelyoursite/reviews/)

 * 2 replies
 * 2 participants
 * Last reply from: [andyt1980](https://wordpress.org/support/users/andyt1980/)
 * Last activity: [2 days, 6 hours ago](https://wordpress.org/support/topic/real-time-js-initialization-after-server-side-blocking/#post-18993952)
 * Status: resolved