Page Builder Popups and Query Loops Stopped Working

Your page builder interactions stop responding. Popups never open, query loops render empty, and the console shows a JavaScript error such as queryLoopInstances is not defined alongside failed module imports. Turn resource blocking off and the site works again.

It is confusing because the script that broke belongs to your own theme, not to a third-party tracker.

Reported by: Alexander Pankart, who documented the symptom and a workaround for Bricks Builder in a WordPress community group.

What Happened

Alexander had Block Scripts Until Consent enabled on a Bricks Builder site. Bricks interactions, including Quick View popups, stopped working entirely, with a fatal error on queryLoopInstances and complaints about blocked WordPress module scripts.

He noted that allowing his site’s own domain changed nothing, but that a rule aimed at the Bricks theme folder cleared the symptom. That detail points straight at the cause.

Why It Happened

SureCookie never blocks a resource for being unfamiliar. A script is held back only when a stored pattern matches it, so when a first-party file gets blocked, a pattern matched something it should not have.

Matching is a plain text match against the whole script URL, not a hostname comparison. That matters on a site serving its assets from a CDN. SureCookie’s catalog lists Bunny CDN under the pattern b-cdn.net, classified as Functional, which is a consent category. On a site offloading /wp-content/ and /wp-includes/ through Bunny CDN, every core and theme asset URL contains that text, so the theme bundle and WordPress’s own script modules are held back until the visitor accepts Functional cookies.

That produces both errors:

• The theme bundle never ran, so anything it defines, including queryLoopInstances, was undefined and the code depending on it threw.
• WordPress prints an import map listing every module URL. Those URLs contain the matched text too, so the whole import map is neutralized and module imports stop resolving.

It also explains why allowing his own domain did nothing. The assets were not being served from his domain.

Important: A blocked import map does not recover when the visitor consents, because the browser has already finished resolving modules. Reload the page after granting consent or changing the setting.

Finding the Rule at Fault

The blocked tag names the pattern responsible, so you do not have to guess.

1. Open the broken page and view the page source, not the inspector’s live DOM.
2. Search for type="text/plain" data-surecookie-.
3. Read the data-surecookie-name value on that tag. It names the rule that matched.

How It Was Fixed

Release the host that serves your own files, rather than exempting a theme folder.

1. Go to SureCookie → Tracking Manager, then open Scripts and Embeds in the left sidebar.
2. Under Detected and Managed Resources, find the row for your CDN host, for example assets.example.b-cdn.net.
3. Open the row to bring up the Edit Resource drawer.
4. Set Behavior to Always load, then save the page.
5. Reload the broken page and confirm the interaction works.

A CDN host serving your own files was never a third party, so releasing it is correct.

If no row exists for the host, add a rule instead. Custom always-load rules are a SureCookie Pro feature. Click New Resource, set Behavior to Always load and Type to Script, then enter the host or path in Domain / Host, for example /wp-content/themes/bricks/. A value containing a slash is matched anywhere in the URL.

Note: Choosing Always load hides the Path / Pattern (advanced) and Category fields, because an always-loaded resource is not gated on a category. Put the path in Domain / Host.

Important: Never enter your bare site domain in an always-load rule. It matches every resource on your own host and exempts all of them from consent, including trackers you add later. A second rule for /wp-includes/ is not needed either.

What This Means for Your Site

• Nothing is blocked for being unfamiliar. If a first-party file is blocked, a pattern matched it. Find the pattern instead of adding broad exemptions.
• Check your CDN before enabling blocking. If your site serves core, theme or plugin assets from a CDN, confirm how that host is classified. This is the most common cause of a first-party script being held back.

Troubleshooting

• Interactions are still broken after accepting cookies – Reload the page. A blocked import map cannot be restored mid-page-view.
• Only Block until consent is offered on a new rule – Always-load custom rules are a Pro feature. On the free plugin, use the Behavior control on the detected row for that host instead.
• The page source shows no blocked tags – Nothing is blocked on that page, so the broken interaction has another cause.
• It works for you but not for visitors – You may have already consented. Clear your consent cookie or use a private window.

Next Steps

Review the rest of the Scripts and Embeds list so genuine third-party trackers stay gated. See Managing Scripts and Embeds.