Terms & Conditions Consent Log vs WP Consent API

WordPress stores consent as a yes. Nothing about when, from where, or which version of your terms was on screen. The day somebody disputes it, that yes is worth very little. Terms & Conditions Consent Log fills the gap on any acceptance checkbox of your site: WooCommerce checkout (classic and blocks), Contact Form 7, WPForms, Gravity Forms, Fluent Forms, comments, login and registration, or a stand-alone shortcode or block. Every accepted consent writes a row to a dedicated indexed table with the timestamp, the IP, the user agent, the document version in force and the exact text shown, sealed with a SHA-256 hash so any later change is detectable. Exactly what Article 7.1 of the GDPR requires you to be able to demonstrate. Filter, search, export to CSV, integrate with the native WordPress Privacy Tools and open a printable A4 certificate for any record, one click to save it as PDF. Works with or without WooCommerce The admin menu lives under Users → Consent log on every install, with or without WooCommerce. The WooCommerce-specific bits (checkout capture for both the classic and the block checkout, order metabox, “Consent” column on the orders list, optional consent line in the order emails) load only when WooCommerce is active; everything else (Records, Settings, CSV export, PDF certificate, Privacy Tools integration) works the same way on any WordPress site. Sources of consent WooCommerce classic checkout (auto when WC is active): captures the native terms checkbox. Stored as terms_and_privacy. WooCommerce block checkout (auto when WC is active): captures purchases made through the block checkout, which is what WooCommerce builds for new stores since version 8.3 and which the classic hooks never see. Stores the exact wording of the Terms and Conditions block. Recorded as terms_and_privacy when that block requires a checkbox, or as terms_notice when it only shows the informational paragraph WooCommerce ships by default, so acceptance by conduct is never logged as explicit consent. An opt-in toggle adds a required checkbox of the plugin’s own, validated server-side, for evidence that does not depend on browser-side validation. On by default. Contact Form 7 (auto): detects [acceptance] fields automatically and the first email field of the form. Stored as cf7_form_{ID}, one type per form. No snippets required. On by default; turn off in Settings if it does not apply. WPForms (auto): detects GDPR Agreement fields automatically and the first email field of the form. Stored as wpforms_form_{ID}, one type per form. Works with WPForms Lite and Pro. No snippets required. On by default; turn off in Settings if it does not apply. Gravity Forms (auto): detects Consent fields automatically and the first email field of the form. Stored as gravityforms_form_{ID}, one type per form. No snippets required. On by default; turn off in Settings if it does not apply. Fluent Forms (auto): detects GDPR Agreement and Terms & Conditions fields automatically and the first email field of the form. Stored as fluentforms_form_{ID}, one type per form. Works with Fluent Forms Lite and Pro. No snippets required. On by default; turn off in Settings if it does not apply. WordPress comments (auto): logs the native wp-comment-cookies-consent checkbox (introduced in WP 4.9.6) when the visitor opts in. Stored as comment_consent. On by default; turn off in Settings if your site uses Disqus, Jetpack or another third-party comments system. Note that this native checkbox is a cookie preference, not consent to store the commenter’s data. Privacy consent on comments and WooCommerce reviews (opt-in): adds a required privacy checkbox to the comment form, blocks the submission server-side if it is left unticked, and stores the acceptance as comment_privacy. This is the Article 7.1 consent to processing the name and email a commenter hands over, as opposed to the cookie preference above. WooCommerce product reviews share the comment form, so they are covered by the same option. Off by default. Membership, course and custom sign-up forms (opt-in): captures accounts created outside the standard WordPress and WooCommerce forms, such as those from MemberPress, LearnDash, Ultimate Member or Paid Memberships Pro, and multisite sign-ups. Stored as user_register. Accounts created from the admin Users screen are never recorded. Off by default. WordPress login and registration (auto): captures successful logins and registrations through wp-login.php when a consent checkbox is ticked on the form. Stored as wp_login and wp_register. Registration is on by default; login is off by default (a normal login form has no consent checkbox, so login only matters for re-consent flows). The “Remember me” checkbox is excluded by design (ePrivacy / cookie preference, not GDPR consent). WooCommerce login and registration (auto when WC is active): same idea for the My Account page. Stored as wc_login and wc_register. Registration is on by default; login is off by default, like the WordPress rows above. An opt-in toggle can inject the consent checkbox into the WC register form, since WooCommerce does not ship one natively. [tccl_consent_box] shortcode and Gutenberg block: drop a self-contained consent checkbox in any page, post or widget area as a stand-alone block. Submission posts to a REST endpoint and writes a record. Always available. For anything else (Elementor Forms, Forminator, custom flows), call tccl_save_consent() from the appropriate hook. Why a dedicated table Storing thousands of consent records in wp_postmeta is wasteful and slow. The plugin uses its own indexed table and exposes a public function (tccl_save_consent) that you can call from anywhere to log additional consents in the same place. Main features Records timestamp UTC, IP, user agent, document version, source URL and full consent text per acceptance. Custom database table with the right indexes (no wp_postmeta bloat). Tamper-evident: each record is sealed with a SHA-256 hash. Any later change to the stored text is detected and reported as TAMPERED in the records list. Printable A4 certificate per record, with a built-in “Print / Save as PDF” button — the browser exports the certificate to PDF natively, no external library bundled. Native Privacy Tools integration: Tools > Export Personal Data and Tools > Erase Personal Data both include consent records (erasure anonymises rather than deletes — the record itself is the lawful basis to keep it). WooCommerce checkout texts are optional — leave them empty and the WooCommerce native text is shown to the customer and stored verbatim. Automatic version bump when the text changes (suggests MAJOR.MINOR-YYYY-MM-DD). Optional opt-out of IP and/or user agent tracking. Configurable retention with a one-click anonymise button (records kept; PII scrubbed). Configurable access by role: grant the consent log to extra roles (for example a DPO) from Settings → Access, without making them administrators. One record per ticked box: a form with a required privacy checkbox and an optional marketing one produces two separate records, so the optional consent is evidenced on its own instead of being swallowed by the required one. Per-form consent wording: the WordPress login, WordPress registration, WooCommerce login and WooCommerce registration forms can each store their own text, falling back to a site-wide default. Live partial-match filters (email, order, date range, type, full-text search inside the accepted text) + filtered CSV export with UTF-8 BOM (opens cleanly in Excel). (When WooCommerce is active) Order metabox with the consent summary, integrity badge and outdated-version indicator. “Consent” column on the orders list (legacy and HPOS) with a quick visual status. Optional consent line in the New order email (admin) and the order confirmation email (customer) — both off by default. Optional delete_data_on_uninstall setting (off by default) — uninstalling does not destroy consent evidence unless you explicitly opt in. HPOS (custom order tables) compatible. Public tccl_save_consent() function to log consents from anywhere. Translation ready All strings use the terms-conditions-consent-log text domain. Translations are managed through translate.wordpress.org. Support Need private support or custom development? Do you need one-on-one help, priority troubleshooting, or a custom feature, integration, or tweak built specifically for your site? I offer private support and custom development. Just contact me and tell me what you need. Need help or have suggestions? Official website WordPress support forum YouTube channel Documentation and tutorials Love the plugin? Please leave us a 5-star review and help spread the word! About AyudaWP.com We are specialists in WordPress security, SEO, AI and performance optimization plugins. We create tools that solve real problems for WordPress site owners while maintaining the highest coding standards and accessibility requirements.

WP Consent API is a plugin that standardizes the communication of accepted consent categories between plugins. It requires a cookie banner plugin and, at least, one other plugin that supports the WP Consent API. With this plugin, all supporting plugins can use the same set of methods to read and register the current consent category, allowing consent management plugins and other plugins to work together, improving compliance with privacy laws. WARNING: the plugin itself will not handle consent. It will show you how many plugins you have without Consent API support and will improve compliance on your site by ensuring smooth communication between cookie banner plugins and plugins that set cookies or track user data. What problem does this plugin solve? Currently, it is possible for a consent management plugin to block third-party services like Facebook, Google Maps, Twitter, etc. But if a WordPress plugin places a PHP cookie, a consent management plugin cannot prevent this. Secondly, some plugins integrate the tracking code on the clientside in javascript files that, when blocked, break the site. Or, if such a plugin’s javascript is minified, causing the URL to be unrecognizable and won’t get detected by an automatic blocking script. Lastly, the blocking approach requires a list of all types of URL’s that tracks data. A generic API where plugins adhere to can greatly facilitate a webmaster in getting a site compliant. Does usage of this API prevent third-party services from tracking user data? Primary this API is aimed at compliant first-party cookies or tracking by WordPress plugins. If such a plugin triggers, for example, Facebook, usage of this API will be of help. If a user embeds a Facebook iframe, a blocking tool is needed that initially disables the iframe and or scripts. Third-party scripts have to blocked by blocking functionality in a consent management plugin. To do this in core would be to intrusive, and is also not applicable to all users: only users with visitors from opt-in regions such as the European Union require such a feature. Such a feature also has a risk of breaking things. Additionally, blocking these and showing a nice placeholder requires even more sophisticated code, all of which should in my opinion not be part of WordPress core, for the same reasons. How does it work? There are two indicators that together tell if consent is given for a specific consent category, e.g., “marketing”: 1) the region based consent_type, which can be opt-in, opt-out, or other possible consent_types; 2) and the visitor’s choice: not set, allow, or deny. The consent_type is a function that wraps a filter, “wp_get_consent_type”. If there’s no consent management plugin to set it, it will return false. This will cause all consent categories to return true, allowing cookies to be set on all categories. If opt-in is set using this filter, a category will only return true if the value of the visitor’s choice is “allow”. If the region based consent_type is opt-out, it will return true if the visitor’s choice is not set or is “allow”. Clientside, a consent management plugin can dynamically manipulate the consent type and set several cookie categories. A plugin can use a hook to listen for changes or check the value of a given category. Categories and most other stuff can be extended with a filter. Existing integrations Categorized, and sorted alphabetically Example plugin Example plugin. The plugin basically consists of a shortcode, with a div that shows a tracking or not tracking message. No actual tracking is done 🙂 Consent Management Providers Abconsent Sirdata CMP. Beautiful Cookie Consent Banner. Clickio Consent Cookie Consent CMP. Complianz GDPR/CCPA. Consent Studio. consentmanager. Conzent. Cookiebot. CookieFirst. CookieHub. CookieTractor. CookieYes – Cookie Banner for Cookie Consent. GDPR Cookie Compliance. GDPR Cookie Consent Plugin – CCPA Ready. GetTerms. iubenda | All-in-one Compliance. Lawwwing. Pressidium Cookie Consent. TrustArc Cookie Consent Manager Consent Requiring Plugins AddToAny. AFL UTM Tracker Plugin. Burst Statistics. Google Site Kit. Pixel Manager for WooCommerce. Woo. WP Statistics. Demo site wpconsentapi.org Below are the plugins used to set up the demo site: Complianz The example plugin javascript, consent management plugin //set consent type window.wp_consent_type = 'optin' //dispatch event when consent type is defined. This is useful if the region is detected server side, so the consent type is defined later during the pageload let event = new CustomEvent('wp_consent_type_defined'); document.dispatchEvent( event ); //consent management plugin sets cookie when consent category value changes wp_set_consent('marketing', 'allow'); javascript, tracking plugin //listen to consent change event document.addEventListener("wp_listen_for_consent_change", function (e) { var changedConsentCategory = e.detail; for (var key in changedConsentCategory) { if (changedConsentCategory.hasOwnProperty(key)) { if (key === 'marketing' && changedConsentCategory[key] === 'allow') { console.log("just given consent, track user") } } } }); //basic implementation of consent check: if (wp_has_consent('marketing')){ activateMarketing(); console.log("set marketing stuff now!"); } else { console.log("No marketing stuff please!"); } PHP //declare compliance with consent level API $plugin = plugin_basename( __FILE__ ); add_filter( "wp_consent_api_registered_{$plugin}", '__return_true' ); /** * Example how a plugin can register cookies with the consent API * These cookies can then be shown on the front-end, to the user, with wp_get_cookie_info() */ function my_wordpress_register_cookies(){ if ( function_exists( 'wp_add_cookie_info' ) ) { wp_add_cookie_info( 'AMP_token', 'AMP', 'marketing', __( 'Session' ), __( 'Store a unique User ID.' ) ); } } add_action('plugins_loaded', 'my_wordpress_register_cookies'); if (wp_has_consent('marketing')){ //do marketing stuff } Service-level consent In addition to category-based consent, the API supports service-level consent control. This allows consent management plugins to grant or deny consent for specific services (like ‘google-analytics’ or ‘facebook-pixel’) independently from their category. When checking service consent with wp_has_service_consent(), the API first checks if explicit consent exists for that service. If no explicit consent is set, it falls back to the consent status of the service’s category. This enables fine-grained control: a user might accept statistics cookies in general, but explicitly deny a specific analytics service. Service consent can be checked and set both server-side (PHP) and client-side (JavaScript): PHP: //check if a specific service has consent if ( wp_has_service_consent( 'google-analytics' ) ) { //activate google analytics } //check if a service is explicitly denied if ( wp_is_service_denied( 'facebook-pixel' ) ) { //service was explicitly denied by user } //set service consent wp_set_service_consent( 'google-analytics', true ); //grant consent wp_set_service_consent( 'facebook-pixel', false ); //deny consent //listen for service consent changes add_action( 'wp_consent_service_changed', function( $service, $consented ) { error_log( "Service {$service} consent changed to: " . ( $consented ? 'granted' : 'denied' ) ); }, 10, 2 ); JavaScript: //check service consent if ( wp_has_service_consent( 'youtube' ) ) { //activate tracking } //check if explicitly denied if ( wp_is_service_denied( 'facebook-pixel' ) ) { //service denied } //set service consent wp_set_service_consent( 'youtube', true ); //listen for service consent changes document.addEventListener( 'wp_consent_api_status_change_service', function( e ) { console.log( 'Service: ' + e.detail.service + ', consented: ' + e.detail.value ); }); Any code suggestions? We’re on GitHub as well!