Headless WordPress

Hi @koalition,

Not as of now. We’re looking into the possibility, but I have no ETA. I made a feature request; https://complianz.io/feature-requests/headless-wordpress/

If you can elaborate what you would like to use, and how the implementation should look we can have a look at an ETA. As you’re more likely to know more about headless, we’d like to know:-)

regards Aert

With some manual work it should be possible, but I haven’t tested it myself:

– the html for the banner and manage consent button needs to be included, and hidden by default with display none. This html can be found in the templates folder. The banner id and consent type need to be replaced. You can compare with the result in a regular site.
– the complianz.min.js needs to be loaded.
– the localized data for the .js needs to be included above the js file, with the banner id etc.
– the rest api should provide the rest.

The css will be loaded automatically through the rest api, based on the consent type and banner id.

Let me know if you need any help with this.

• This reply was modified 2 years, 3 months ago by Rogier Lankhorst.

I just tried this on a testing environment, following these steps:

– on a website, set up a pure html file which was the “headless” website
– copied the localised vars, complianz.min.js, and banner html to the html file

The banner worked as expected.

One thing that doesn’t work yet: the cookieblocker works by parsing the generated html of the website (server side), and blocking scripts and iframes that track users.

A possible solution for this could be to pass the html from the headless framework through the cookieblocker:

$html = COMPLIANZ::$cookie_blocker->replace_tags($html);

Another approach could be to add this to a rest api call.

It all depends on how the headless framework generates the html I think.

As third option, you could choose to build the html “blocked” by default.

If you can provide me with some input as to what possibilities there are on headless, I can maybe offer more options.

We would be happy to assist with this. I think if it needs to be entirely client side, the replace_tags() function would need to be rebuilt in javascript.

This is not on the roadmap currently, but you can do a feature request on complianz.io. Alternatively, any pull requests are welcomed, and I would be happy to assist there as well.

As this thread has been silent for some days, I’ll mark it as closed. You can always reach us at complianz.io to discuss this in more detail.

Thanks for this thread – I’ve experimented with headlessWP and was also wondering about the GDPR compliance aspect – I suppose there’s two levels with headless as opposed to one level in standard templating: the wp-post/s and plugin/rest content and the headless site templating itself.

I suppose your filter parsing approach could work for the wp-posts / plugins aspect of the template, and I suppose it would also be possible to request the current consent status when rendering aspects of the site that aren’t handled by WP.

My first “real” decoupled/SPA WP-App won’t require compliance, but when I’m done with it I will try this to see if it works.