Repository navigation
Integrate WP Consent API - #7
Closed
Castellon-ACM wants to merge 5 commits into
Closed
Castellon-ACM wants to merge 5 commits into
Castellon-ACM wants to merge 5 commits into
Conversation
Fan a visitor's binary accept/reject decision out into a per-category action so add-ons (e.g. a WP Consent API bridge) can react without duplicating the AJAX/no-JS form decision-recording logic. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Add FrontConsent\Frontend\WPConsentAPI, registered from Plugin_Main alongside CookieNotice. On init it registers FrontConsent as an 'optin' consent type (matching its own default-deny-until-accepted behavior), and it listens to the new frontconsent_consent_updated action to call wp_set_consent() for each affected category, mapping FrontConsent's own 'analytics'/'marketing' category slugs onto the WP Consent API's standard 'statistics'/'marketing' slugs. The WP Consent API is an optional soft dependency: every call is guarded by function_exists(), so FrontConsent behaves identically whether or not the WP Consent API plugin/library is installed. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Covers: no-op behavior when the WP Consent API's functions don't exist (the real default in this test environment, since the plugin isn't installed), the optin consent-type registration, the analytics->statistics / marketing->marketing category mapping in both directions, an unmapped category passing through unchanged, and the full AJAX decision path firing wp_set_consent() for every category via the frontconsent_consent_updated action. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
test_full_consent_decision_syncs_every_category went through the AJAX log_consent_callback(), which calls wp_send_json_success() -> wp_die(). Inside this test's own @runInSeparateProcess child process that just exits the process instead of raising a catchable exception, so the child "ends unexpectedly" and PHPUnit reports the test as failed even though the assertions themselves never ran. Switch to process_consent_form_submission() (the no-JS <form> fallback's own decision path) instead — it returns rather than exiting, and fires the same fire_consent_updated_action() this test cares about. 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
FrontConsent\Frontend\WPConsentAPIclass (registered inPlugin_Main) that bridges FrontConsent's own consent decisions onto the community-standard WP Consent API, so other plugins can read the visitor's consent viawp_has_consent( $category )instead of needing bespoke FrontConsent-specific integration code.init, ifwp_set_consent_type()exists, registers FrontConsent as anoptinconsent type — matching its actual default-deny-until-accepted behavior (CookieNotice::render_consent_mode_default()defaults Google Consent Mode todenieduntil the visitor accepts; there is no opt-out mode in this plugin).CookieNoticenow fires a newfrontconsent_consent_updated( $category, $status )action whenever a visitor's decision is recorded (both the AJAX path and the no-JS<form>fallback), once per category in the existingCONSENT_CATEGORIES(analytics,marketing— the same two categoriesget_integration_default_category()already sorts tracking integrations into).WPConsentAPIlistens to that action and callswp_set_consent( $category, 'allow' | 'deny' ), mapping FrontConsent'sanalyticscategory onto the WP Consent API's standardstatisticsslug (marketingpasses through unchanged).function_exists(), so FrontConsent behaves identically whether or not the WP Consent API plugin/library is installed. NoRequires Pluginsheader was added, intentionally.Closes #6
Test plan
composer lint— cleancomposer phpstan— clean (0 errors)tests/Unit/WPConsentAPITest.phpcovering: no-op behavior when the WP Consent API's functions genuinely don't exist (the real default in the test environment, since the plugin isn't installed), theoptinconsent-type registration, theanalytics→statistics/marketing→marketingmapping in both allow/deny directions, an unmapped category passing through unchanged, and the full AJAX decision path (log_consent_callback()) firingwp_set_consent()for every category via the new action.composer test -- --filter=WPConsentAPI— could not be run in the sandbox this PR was prepared in (no MySQL/MariaDB server available, and this repo's WP PHPUnit setup has no lightweight SQLite fallback wired in, sobin/install-wp-tests.shcan't provision a test database here). The repo's ownphpunit.ymlCI workflow does spin up a real MySQL service and should exercise this test class on the PR — please check CI results.🤖 Generated with Claude Code