Add extension hooks for advanced (per-category) cookie consent - #256
Conversation
Adds action/filter hooks to the Cookie Notice banner (before the Reject/Accept buttons, after the banner markup, the Consent Mode default signals, and the default button labels), plus a "Customize" action and a staleness check in the frontend JS, and settings fields for the advanced cookie categories feature. These are consumed by FrontBlocks PRO's new Advanced Cookie Management module to add per-category consent without forking this plugin's banner.
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 5d715cdb4a
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
- Remove the Advanced Cookie Management checkbox and integration ID fields from this plugin's Settings page — they now live entirely in FrontBlocks PRO's own settings (registered into this same section via the frontblocks_register_settings hook). This plugin now only shows a short upsell message pointing at that PRO feature. - Fix CI lint failures introduced by the removed fields (now moot). - Gate the wp_head bootstrap script and the JS fallback's tracking fetch by the same staleness check already used to keep the banner visible, so a per-category consent add-on invalidating old consent also stops tracking from starting on stale data, not just the banner from hiding.
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 1e4d6c1d10
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
render_consent_mode_default() read the visitor's cookie server-side and baked the resulting granted/denied values directly into the printed <script>, breaking the cache-safety this module otherwise guarantees: a full-page cache could serve one visitor's Consent Mode state to another. Move the cookie read (and, for an add-on, the per-category override) entirely client-side, mirroring the pattern already used by render_consent_bootstrap_script() — only the fixed cookie name is embedded server-side now, so the printed HTML is identical for every visitor of a URL again. Replaces the frbl_cookie_notice_consent_mode_state PHP filter (which had the same problem by construction — any per-visitor value it returned would get cached the same way) with a client-side override point, window.frblCookieNoticeConsentModeState().
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 04d31ea700
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
render_consent_mode_default()'s client-side cookie read didn't guard
decodeURIComponent() against malformed percent-encoding — a thrown
error there would abort before gtag('consent', 'default', ...) ever
ran, leaving independently loaded Google tags with no denied default.
Catch it the same way the bootstrap script below already does.
Also corrects the 1.6.0 changelog entry, which still named the removed
frbl_cookie_notice_consent_mode_state PHP filter instead of the
client-side window.frblCookieNoticeConsentModeState() override that
replaced it.
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 17ba473c65
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
render_consent_mode_default() fell back to this plugin's own (possibly still 'accepted') binary cookie whenever an add-on's per-category override returned null for staleness — meaning an independently loaded, Consent Mode-aware tag (e.g. Site Kit) could still get 'granted' before the visitor answers a re-shown banner, even though the GTM/GA4 fetch paths already correctly deny in that same situation. Reuse the existing window.frblCookieNoticeIsConsentStale() check here too and force denied when it reports stale, regardless of what the binary cookie says.
.frbl-cookie-notice__actions had flex-shrink: 0 but no flex-wrap, so once a third button (e.g. PRO's "Customize", added via the new frbl_cookie_notice_before_actions hook) joins Reject/Accept in the same row, the three no longer fit — especially in the popup layout's 420px panel — and the row overflows horizontally instead of wrapping, clipping button text and forcing a horizontal scrollbar inside the panel.
2 participants
Summary
frbl_cookie_notice_before_actions( $options )— fires inside the actions row, before Reject/Accept.frbl_cookie_notice_after_banner( $options )— fires right after the banner markup, inside the samewp_footeroutput.frbl_cookie_notice_default_accept_label/frbl_cookie_notice_default_reject_label— filters for the fallback button copy.frbl_cookie_notice_consent_mode_state( $state, $consent )— filter to override the four Consent Mode signals per category instead of a single binary decision.[data-frbl-cookie-action="customize"]handler in the frontend JS (dispatches afrblCookieNoticeCustomizeevent, doesn't decide/hide the banner) and awindow.frblCookieNoticeIsConsentStale()extension point so an add-on can force the banner to re-show when its own consent record goes stale.FRBL_VERSIONto 1.6.0 and updatesdocs/COOKIE-NOTICE.md/readme.txt.These hooks are consumed by FrontBlocks PRO's new Advanced Cookie Management module (see closemarketing/frontblocks-pro#54 and the companion PR on that repo) to add per-category consent (Necessary/Analytics/Marketing) on top of this banner. Nothing here changes the existing binary accept/reject behavior when the add-on isn't active — the new fields/hooks are all additive and no-ops if unused.
Test plan
composer lintclean on the touched files (JS/PHP syntax-checked withphp -l/node --check; fullphpcs/phpstancould not be run in this environment —composer installtimed out fetching dev dependencies).Generated by Claude Code