how to bypass an inline script?

Hi @rwky!

FAZ blocks scripts by scanning the page HTML and matching script tags against a database of known trackers and cookie providers. If your inline script contains a string that matches a known provider pattern — for example a tracking variable like fbq( or gtag( — FAZ will block it even if the script itself is not a tracker.

Here is a typical example of the problem. Say you have a product configuration script like this:

FAZ might block this script because the text “facebook.com” or “youtube.com” appears inside it, even though the script is just passing data — it is not running any Facebook or YouTube tracker code at all.

There are two ways to resolve this.

OPTION A — WHITELIST THE SCRIPT BY ID (works right now)

Step 1 — Add an id to your inline script tag:

Step 2 — Add that id to the FAZ exception list.

Go to FAZ Cookie Manager → Settings → Script Blocking. You will see a textarea called “Script Blocking Exceptions”. Add the id you chose, one per line:

my-product-config

Save the settings.

How the field works: patterns without dots or slashes are matched against the script’s id and class attributes. Patterns with dots or slashes (e.g. googleapis.com/maps) are URL fragments matched against the src attribute instead. Since your script has no src, a bare id handle is the correct format.

Step 3 — Clear your cache.

If you are running a caching plugin (LiteSpeed Cache, WP Rocket, W3 Total Cache, etc.), clear the full page cache after saving. FAZ’s blocking runs in PHP during page generation — cached pages will not reflect the new exception until the cache is invalidated.

After clearing the cache, reload the page: the script should now execute normally.

OPTION B — WAIT FOR THE NEXT FAZ RELEASE (will fix the root cause automatically)

A fix for this class of false positives is already merged and will ship in the next FAZ release. The change: URL-fragment patterns (e.g. facebook.com, youtu.be) will only match against a script’s src attribute, never against inline text content. Code-level tracking signatures (fbq(, gtag(, _gaq) will still match inline content as before.

If your script is being blocked because it references a tracker domain inside data (not because it actually runs tracker code), updating FAZ when the next version is out will resolve the false positive automatically — no whitelist entry needed.

The same release will also rename the Settings field from “Whitelisted URL Patterns” to “Script Blocking Exceptions” with a clearer description explaining that script IDs and handles are accepted alongside URL fragments.

IF YOU CANNOT MODIFY THE SCRIPT TAG

If the script is rendered by a third-party plugin and you cannot add an id attribute, try injecting it via your theme’s functions.php:

add_filter( ‘script_loader_tag’, function( $tag, $handle ) {
if ( $handle === ‘your-plugin-handle’ ) {
return str_replace( ‘<script ‘, ‘<script id=”my-product-config” ‘, $tag );
}
return $tag;
}, 10, 2 );

Note: this filter only applies to scripts enqueued via wp_enqueue_script(). Truly raw inline scripts echoed directly in a template cannot be intercepted this way — in that case, look for a plugin hook or edit the template directly.

Let me know what your script looks like and I can confirm which approach applies to your case!

Glad you got it working — and thank you for the clear feedback. The field name “Whitelisted URL Patterns” only hints at URLs, so figuring out that a bare class name works there is not obvious at all.

Good news: the naming and description have already been updated in the next release. The field will be renamed “Script Blocking Exceptions” and the description will explicitly list the three types of values it accepts — URL fragments (with dots or slashes), script id attributes, and CSS class names — with a concrete example for each. No one should have to guess anymore.

On your suggestion for a faz-skip class: i like it and I’m going to implement it. The idea is that adding class=”faz-skip” to any script tag will always exclude it from blocking — no settings page required, no whitelist entry needed. Something like:

<script class=”faz-skip”>
// this script will never be blocked by FAZ, regardless of its content

This is a zero-configuration escape hatch for developers: add the class in your theme or plugin template, done. It also makes the intent explicit right in the HTML source — anyone reading the markup immediately knows the script is intentionally excluded.

I’ll document it in the Script Blocking section of the settings page so future users see it before they go looking for the whitelist.

Thanks again for the suggestion — this will save a lot of people the same confusion. 🙂

Just a quick follow-up: FAZ Cookie Manager 1.13.16 is now available in the WordPress plugin directory.

This version ships the native faz-skip class I mentioned in my previous reply. You no longer need the whitelist workaround — you can add class=”faz-skip” directly to any script tag and FAZ will leave it completely untouched.

If you want to switch, just add faz-skip to the script’s class attribute and remove it from the whitelist. Either approach works fine going forward, so there is no need to change anything if the whitelist is already working for you.

Thanks again for the patience and for helping me test this. Glad it is working!