Clear add-ons. Earlier signals.
A consistent integration pattern made add-ons easier to understand. Daily checks helped surface upstream changes before they became support issues.
WordPress · PHP · PHPUnit · GitHub
Third-party plugins
Dedicated add-on classes
Shared consent behavior
Daily PHPUnit checks
Earlier compatibility signals
In this case
I no longer maintain the plugin following a move to new roles. The repository remains public and open to contributions.
The challenge
Plugins add scripts in different ways.
Third-party plugins can load analytics, embeds and other scripts that set cookies. Cookiebot add-ons connect those plugins to consent handling, but each integration needs to account for the plugin’s own behavior.
The approach
A common base for each add-on.
I refactored integrations into separate add-on classes built on shared abstractions. Each add-on has a clear place to configure how its plugin’s scripts work with consent, including support for incompatible plugin versions.
For contributors
Documented for other developers.
I wrote a guide showing developers how to register an add-on, configure its consent behavior and add tests. The repository invited contributions for new integrations and fixes.
Proactive maintenance
Find upstream changes sooner.
I set up PHPUnit checks to run daily against plugins hosted on WordPress.org. They flagged upstream code changes that could affect an add-on, giving maintainers a chance to investigate before a user filed a ticket.
My involvement
Maintainer of a widely used plugin.
The WordPress.org plugin has more than 100,000 active installations. I led the add-on refactor, contributor documentation and daily compatibility checks. I later moved to new roles and stopped supporting the project.
WordPress · PHP · PHPUnit · GitHub · Plugin integrations
See the CookiebotWP GitHub repository or the Cookiebot plugin on WordPress.org.
Work together
Need help making integrations more dependable?
Tell me about the platform, plugin ecosystem or maintenance challenge.