Remove legacy Cookie Notice runtime module (hard cutover to FrontConsent) - #317
Merged
Merged
Conversation
…ent) Cookie consent now lives entirely in the standalone FrontConsent plugin. FrontBlocks no longer ships its own banner, AJAX consent endpoints, or GTM/GA4/tracking integrations — only the FrontConsent promo/migration panel added in #314 remains. - Delete includes/Frontend/CookieNotice.php and its assets (assets/cookie-notice/frontblocks-cookie-notice.{js,css}). - Stop instantiating Frontend\CookieNotice from Plugin_Main::load_modules(). - Drop the now-inaccurate 'cookie-notice' entry from Admin\RedundantPlugins::get_default_entries() — FrontBlocks no longer makes GDPR Cookie Compliance/CookieYes redundant. - Remove the orphaned .frbl-cookie-notice-preview* CSS left over from the pre-promo-panel settings preview. - Delete tests exercising the removed class (CookieNoticeLinkTest.php); trim CookieNoticeTransitionTest.php down to its CookieNoticeDeprecationNotice coverage and rename it CookieNoticeDeprecationNoticeTest.php, adding regression tests that the legacy class is gone and that the promo tab still renders without it. - Update RedundantPluginsTest.php, AGENTS.md, readme.txt/readme.md, and docs/COOKIE-NOTICE.md to describe this as a hard cutover rather than a transition, and fix a stale test comment referencing a cookie-notice JS test file that no longer exists. Admin\CookieNoticeDeprecationNotice and Settings::render_cookie_notice_promo_tab() are untouched — both only ever depended on each other, never on the removed runtime class. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
|
Codex usage limits have been reached for code reviews. Please check with the admins of this repo to increase the limits by adding credits. |
… removal Removing the 'cookie-notice' entry left 'svg-upload' and 'login-google' misaligned per WordPress.Arrays.MultipleStatementAlignment, which composer lint's phpcs run flagged. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Contributor
|
@codex review |
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
![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: c933ac1185
ℹ️ 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".
Comment on lines
+13
to
+14
| had it enabled will show no cookie banner at all until FrontConsent is | ||
| installed — this is intentional, to push migration forward. |
There was a problem hiding this comment.
On sites where an administrator previously clicked “Dismiss for now,” CookieNoticeDeprecationNotice::render_notice() still returns when the existing frbl_cookie_notice_deprecation_dismissed user meta is set. After this hard cutover removes the active banner, those administrators therefore receive no warning that consent collection has stopped; bump or reset the dismissal state for the cutover so affected sites see the now-urgent migration notice.
AGENTS.md reference: AGENTS.md:L9-L9
Useful? React with 👍 / 👎.
Comment on lines
+1868
to
+1870
| * Cookie Notice's runtime module has been removed from FrontBlocks | ||
| * entirely — a hard cutover, not a transition — leaving only this promo | ||
| * panel and `includes/Admin/CookieNoticeDeprecationNotice.php`. This tab |
There was a problem hiding this comment.
For an existing site with enable_cookie_notice set and no prior dismissal, the retained admin notice still says Cookie Notice “is moving,” “is being extracted,” and that the module turns itself off only after FrontConsent is installed. That is now false because this change removes the runtime immediately, so the notice can leave owners believing their banner remains active; change the retained user-facing copy to state explicitly that FrontBlocks no longer displays a banner and FrontConsent must be installed.
AGENTS.md reference: AGENTS.md:L9-L9
Useful? React with 👍 / 👎.
- Bump CookieNoticeDeprecationNotice::DISMISSED_META_KEY to a new name so an admin who dismissed the old, lower-stakes transition notice still sees this one — the site now has no consent banner at all until FrontConsent is installed, which the old dismissal predates. - Rewrite the notice's copy (and its class docblock) to state plainly that the banner is already gone, instead of the stale "is moving" / "is being extracted" / "turns itself off" transition-period wording. - Gate the Settings promo tab's install CTA on current_user_can( 'install_plugins' ): a user with only edit_theme_options (e.g. a multisite subsite admin) could see the tab but would hit a failed nonce authorization on the install URL; they now get a message pointing at a site/network administrator instead. - Drop cookie-consent claims from readme.txt's short description, opening paragraph, and Tags line, and point to FrontConsent instead — those are the first things a WordPress.org visitor sees, ahead of the (already-accurate) detailed changelog section. - Correct readme.md and docs/REDUNDANT-PLUGINS.md, both still documenting Cookie Notice as one of the two core redundant-plugin defaults; the actual defaults are SVG Upload and Google Login. - Clarify docs/COOKIE-NOTICE.md: the promo panel's link only installs FrontConsent when it isn't present yet — WordPress still requires a separate activation step, so "one-click install/activation" overstated what actually happens in one click. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Castellon-ACM
added a commit
that referenced
this pull request
Oct 2, 2026
Registers frontblocks/maintenance-mode via WordPress's Abilities API (wp_register_ability(), guarded with function_exists() for sites where it isn't available). It's read/write, manage_options-gated, and idempotent, so an MCP client can check and flip maintenance mode as part of a site go-live checklist instead of requiring a manual toggle in the FrontBlocks settings screen. It also reports WooCommerce's own "Coming soon" site-visibility state independently, since the checklist treats the two as separate things to verify. Maintenance::is_enabled() becomes a public static method (plus a new set_enabled() setter) so the ability can read and flip it without instantiating the class and re-triggering its constructor's hook registrations. The cookie-consent half of #299 is dropped from this PR: trunk's Cookie Notice hard cutover (#317) removed FrontBlocks' own banner entirely in favor of the standalone FrontConsent plugin while this was in progress, so an ability for it belongs in FrontConsent's own codebase instead — left as a follow-up there. Closes #299 Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
davidperezgar
pushed a commit
that referenced
this pull request
Oct 2, 2026
* Add an MCP ability for maintenance mode Registers frontblocks/maintenance-mode via WordPress's Abilities API (wp_register_ability(), guarded with function_exists() for sites where it isn't available). It's read/write, manage_options-gated, and idempotent, so an MCP client can check and flip maintenance mode as part of a site go-live checklist instead of requiring a manual toggle in the FrontBlocks settings screen. It also reports WooCommerce's own "Coming soon" site-visibility state independently, since the checklist treats the two as separate things to verify. Maintenance::is_enabled() becomes a public static method (plus a new set_enabled() setter) so the ability can read and flip it without instantiating the class and re-triggering its constructor's hook registrations. The cookie-consent half of #299 is dropped from this PR: trunk's Cookie Notice hard cutover (#317) removed FrontBlocks' own banner entirely in favor of the standalone FrontConsent plugin while this was in progress, so an ability for it belongs in FrontConsent's own codebase instead — left as a follow-up there. Closes #299 Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> * fix: avoid duplicate Abilities API registration in the integration test The Abilities API's registries are a lazy, process-wide singleton: wp_abilities_api_init/wp_abilities_api_categories_init fire at most once per process, the first time anything calls into wp_has_ability() et al. This test's own set_up() hooks a second McpAbilities instance on top of the one Plugin_Main::load_modules() creates at bootstrap, so if that one-time firing happened during this test, both instances tried to register the same ability name and WordPress's "already registered" guard called _doing_it_wrong() — which this suite's strict PHPUnit settings (convertWarningsToExceptions/convertNoticesToExceptions) turn into a thrown exception, failing the test on every PHP version in the matrix (it depends on the WordPress version, not the PHP version). Reduce to exactly one hooked instance before the first call that can trigger the singleton, and stop firing the hooks directly with do_action() (which bypassed the registries' own one-time guard entirely and triggered the exact same problem deterministically). Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> --------- Co-authored-by: Claude Sonnet 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Deliberate, authorized hard cutover: FrontBlocks no longer renders any cookie banner of its own. Cookie consent now lives entirely in the standalone FrontConsent plugin, which is feature-complete and ahead of FrontBlocks' own retired copy (icon-only reopen trigger, WCAG-compliant policy link, accessibility fixes, asset minification). Sites that haven't installed FrontConsent yet will simply have no banner until they do — accepted as an intentional forcing function for migration. PR #314 already turned the Settings "Cookie Notice" tab into a pure FrontConsent promo panel; this PR removes the runtime code that PR deliberately left in place "to keep working during the transition."
What was removed
includes/Frontend/CookieNotice.php— the banner, its twowp_ajax_frbl_*consent endpoints, GTM/GA4/Clientify/Brevo/OpenAI tracking bootstrap, and aggregate accept/reject stat counters.assets/cookie-notice/frontblocks-cookie-notice.{js,css}— its frontend assets.new Frontend\CookieNotice();instantiation inPlugin_Main::load_modules().'cookie-notice'entry inAdmin\RedundantPlugins::get_default_entries()— with no runtime banner left, FrontBlocks no longer makes GDPR Cookie Compliance/CookieYes redundant..frbl-cookie-notice-preview*CSS inassets/admin/settings-src.css/settings.css, left over from the pre-promo-panel settings preview (no markup has referenced these classes since Turn Cookie Notice tab into a FrontConsent promo panel #314).tests/Unit/CookieNoticeLinkTest.php(deleted) and theFrontend\CookieNotice-specific tests insideCookieNoticeTransitionTest.php.assets/cookie-notice/**path filter in.github/workflows/phpunit.yml.What was kept, unchanged
includes/Admin/CookieNoticeDeprecationNotice.php— the "install FrontConsent" admin nudge. It never called intoFrontend\CookieNotice(verified by grep), so no adaptation was needed.includes/Admin/Settings.php'srender_cookie_notice_promo_tab()— UI/copy untouched; it only depends onCookieNoticeDeprecationNotice, which is kept. Only its docblock comment (pointing at the now-deleted file) was corrected.CookieNoticeTransitionTest.php'sCookieNoticeDeprecationNoticecoverage — trimmed and renamed totests/Unit/CookieNoticeDeprecationNoticeTest.php, with two new regression tests added:class_exists( 'FrontBlocks\Frontend\CookieNotice' )is now false.Settings::render_cookie_notice_promo_tab()still renders without a fatal now that the class is gone.tests/Unit/RedundantPluginsTest.phpupdated to assert thecookie-noticeentry is now absent, rather than testing its removed behavior.Docs updated to describe this as a hard cutover (not a transition)
AGENTS.md,readme.md,readme.txt(+ an= Unreleased =changelog entry), anddocs/COOKIE-NOTICE.md.Third-party breaking-change note
FrontBlocks previously exposed these action/filter hooks from the now-removed runtime, which a third party (including FrontBlocks PRO's Advanced Cookie Management) could have hooked into — flagging for visibility, since FrontBlocks PRO's own migration off these is being handled by another agent:
frbl_cookie_notice_settings_updated(action)frbl_cookie_notice_before_actions/frbl_cookie_notice_after_banner(actions, banner markup extension points)frbl_cookie_notice_default_accept_label/frbl_cookie_notice_default_reject_label(filters)frbl_cookie_notice_has_tracking_consent/frbl_cookie_notice_allowed_tracking_categories(filters)frbl_cookie_notice_tracking_types/frbl_cookie_notice_detect_tracking_snippet/frbl_cookie_notice_integration_category(filters)window.frblCookieNoticeConsentModeState(),window.frblCookieNoticeIsConsentStale(),window.frblCookieNoticeInjectIntegration(),window.frblCookieNoticeInject,window.frblCookieNoticeBootstrapped,window.frblCookieNoticePendingIntegrationsfrbl_log_cookie_consent,frbl_get_cookie_notice_config,frbl_get_cookie_notice_log_nonceCookieNotice::get_tracking_integrations(),::get_tracking_types(),::detect_tracking_snippet(),::get_integration_default_category(),::get_cookie_icon_svg(),::get_radius_value(),::get_readable_text_color(),::get_readable_on_white_color()None of these are used elsewhere in this repo (verified by repo-wide grep) —
CookieNoticeDeprecationNotice(kept) uses none of them.Test plan
CookieNotice.phpregistered or read, confirmed nothing else in the repo (block patterns, redundant-plugins registration aside, other frontend features) depends on it.includes/Admin/CookieNoticeDeprecationNotice.phpbehavior/purpose untouched.includes/Admin/Settings.php's promo tab UI/copy untouched.composer lint/composer phpstan/composer test— PHP/Composer aren't available in this sandbox; relying on CI (.github/workflows/phpunit.yml, runs on PHP 7.4/8.1/8.2/8.3) to confirm.npm run test:js— Node isn't available in this sandbox either; notest:cookie-notice-style script existed inpackage.jsonto begin with, so nothing needed removing there, but CI should confirm no JS tests reference the deleted files.🤖 Generated with Claude Code