Cookie Consent in the Block Editor: The Banner Has to Live in the Theme

The block editor changed where consent has to live. A banner that only covers the front end misses the editor, the customiser, and the checkout blocks, and a cookie set in the editor is still a cookie. The fix is to put consent in the theme, not in a page.

The banner lives in the theme, not the page

A cookie banner added to a page template covers that page. A banner added through a page builder widget covers the pages that use that widget. Neither covers the block editor, the customiser, or the checkout blocks, and all three can set cookies or make tracking requests. The banner has to be loaded in the theme, so it runs on every page the theme renders, and the scripts it gates have to be gated in the theme too, not in a single template.

The mechanism is wp_enqueue_scripts, the WordPress hook for loading scripts. A consent tool can conditionally load scripts through that hook, based on the stored consent choice, and it can set cookie attributes, Secure, HttpOnly, SameSite, on the server. A consent plugin can also leave a script out of the page entirely when the stored choice says no, which avoids any chance of a tracker running before JavaScript starts. That is the advantage WordPress has over a hosted platform: the store controls every script, every cookie, and every server setting, and the consent decision is theirs to configure.

The banner A/B test post showed how a reject button that is hard to find changes the consent rate. The editor problem is the same kind of failure at a different scale: the banner is easy to find on the front end and missing entirely in the editor, and the cookies set there are just as real.

Checkout blocks are the gap

WooCommerce checkout is a WordPress page in your own theme, on the same site as the rest of your store, and whatever consent tool you run on the storefront runs on checkout too, including on pages that hand over to a payment provider. But the checkout blocks are rendered in the block editor, and they load scripts that can set cookies before the visitor has chosen. The consent tool has to run on the checkout page, and the checkout blocks have to respect the consent state.

The test is to load the checkout page with the cache cleared and watch the network requests before answering the banner. If any tracking request fires, the gating has failed. Then answer the banner, reject, and watch again. If tracking still fires, the checkout blocks are not gated. The fix is to check that the consent plugin hooks into the checkout blocks, not just the front-end pages, and to test the journey from the cart to the checkout and back.

The consent without hooks post covered the same gap from the plugin side: a site that tries to manage consent without the API ends up with a banner and plugins that disagree. The block editor is where that disagreement shows up first, because the editor loads more scripts than the front end, and more of them are outside the banner's reach.

Test the editor journey

The test for consent in the block editor is a network trace, not a screenshot. Load the site, open the editor, and watch the network requests. If any tracking request fires before consent, the gating has failed, whatever the banner looks like. Then test the customiser, and then the checkout blocks. Each of these is a separate surface, and each one needs the banner and the gating to be in place.

The advantage of WordPress is control, and the disadvantage is responsibility. A hosted platform gates the scripts for you, and you cannot change how it works. WordPress lets you gate them yourself, and you have to. The banner in the theme, the scripts gated through wp_enqueue_scripts, and the test in the network tab are the three pieces, and all three have to be in place before the site is compliant.

Frequently asked questions

Why does the block editor need consent handling?

The block editor loads scripts and embeds, including oEmbed previews, that can set cookies or make tracking requests. A banner that only runs on the front end does not cover the editor, and a cookie set in the editor is still a cookie, even if no visitor ever sees it.

Where should the consent banner be loaded in WordPress?

The banner has to be loaded in the theme, not in a page template, so it runs on every page the theme renders, including the editor and the customiser. A banner added to a single page template will miss every other page, and a banner added through a page builder widget will miss the editor.

Does the checkout block need consent handling too?

Yes. WooCommerce checkout blocks are rendered in the block editor, and they load scripts that can set cookies. The consent tool has to run on the checkout page, and the checkout blocks have to respect the consent state, or the checkout will set cookies before the visitor has chosen.

How do I gate scripts by consent in WordPress?

Use wp_enqueue_scripts to conditionally load scripts based on the consent state, and set cookie attributes, Secure, HttpOnly, SameSite, on the server. A consent plugin can also leave a script out of the page entirely when the stored choice says no, which avoids any chance of a tracker running before JavaScript starts.

How do I test consent in the block editor?

Load the site with the cache cleared, open the editor, and watch the network requests. If any tracking request fires before consent, the gating has failed. Then test the checkout block, and check that the consent banner appears there too.