Cookies, Terms & Conditions Consent Log

Yes. Activate it on any WordPress site and the Records, Settings, CSV export, PDF certificate and Privacy Tools integration all work the same way. The WooCommerce-specific bits (checkout capture, order metabox, order list column, order email line) only load when WooCommerce is active.

Nothing to set up. With Complianz active, the Cookies tab under Users > Consent log fills up on its own: one sealed row per decision, with the categories accepted, the version of the cookie policy on screen and the law that applied. Check it in a private window: choose something in your banner and the row appears. Complianz today, and other banners release by release. For any other, Settings > Cookie banner decisions has a custom source to switch on and feed from a snippet of your own.

One, tccl_cid, and only after a visitor decides something in your banner. Somebody who just reads your site is given nothing. It holds a random identifier your server mints, scripts cannot read it, and it ties one visitor's decisions together. Declare it as strictly necessary in your cookie policy.

Declare it with the tccl_cookie_sources filter, then send each decision from the browser: add_filter( 'tccl_cookie_sources', function ( $sources ) { $sources['my_banner'] = array( 'label' => 'My banner', 'active' => true, 'version' => '3', 'law' => 'optin' ); return $sources; } ); window.tcclCookieConsent.record( 'my_banner', { action: 'accept_all', categories: [ 'functional' ], raw: {}, user_action: 'yes' } ); action is accept_all, reject, custom or withdraw; your server signs the version and the law. If your banner fires one event per category, use queue( 'my_banner', fn ) and they collapse into one row. With no filter, tick "Let my own snippet record decisions" in Settings and use custom.

Look at Settings > Cookie banner connection: it says which banner is running, whether a decision has ever arrived and when the last one did. If it is running and nothing arrives, it has probably changed its script: say so in the support forum and it gets an updated adapter.

The ones taken by someone signed in: those carry the user, so WordPress finds them from an email. Exporting returns them, erasing deletes them. A decision taken without signing in has no email on it and cannot be found from one. Act on those by their identifier, in Users > Consent log > Cookies. Erasing deletes instead of anonymising, like the retention period does: scrubbing the address would leave a row that still points at the same browser and proves nothing.

That your site showed that version of that banner under that law, signed by your server, and that the row has not been touched since. Not that a named person clicked: a browser reports the decision, as in every cookie consent log, paid ones included. It is why no row is written at all for a visitor who has decided nothing.

Open Consent log > Settings > Integrations and tick "Log every CF7 form submission that ticks an [acceptance] field". Then make sure your CF7 forms include an [acceptance] field, e.g.: [acceptance privacy] I have read and agree to the privacy policy. [/acceptance] The plugin uses the form ID as part of the consent_type (cf7_form_{ID}), so each form is filterable separately. The first email field of the form is used as the subject email. No snippets, no functions.php edits.

Open Consent log > Settings > Integrations and tick "Log every WPForms submission that ticks a GDPR Agreement field". Then add a GDPR Agreement field to your form from the WPForms builder (Fancy Fields → GDPR Agreement) and edit its label to the exact wording you want recorded (e.g. "I have read and agree to the privacy policy."). The plugin uses the form ID as part of the consent_type (wpforms_form_{ID}), so each form is filterable separately. The first email field of the form is used as the subject email, and the GDPR Agreement field label is what gets stored as the accepted text. Works with WPForms Lite and Pro. No snippets, no functions.php edits.

Open Consent log > Settings > Integrations and tick "Log every Gravity Forms submission that ticks a Consent field". Then add a Consent field to your form from the Gravity Forms editor (Advanced Fields → Consent) and set its checkbox label to the exact wording you want recorded (e.g. "I have read and agree to the privacy policy."). The plugin uses the form ID as part of the consent_type (gravityforms_form_{ID}), so each form is filterable separately. The first email field of the form is used as the subject email, and the Consent field's checkbox label is what gets stored as the accepted text. No snippets, no functions.php edits.

Open Consent log > Settings > Integrations and tick "Log every Fluent Forms submission that ticks a GDPR Agreement or Terms & Conditions field". Then add a GDPR Agreement or a Terms & Conditions field to your form from the Fluent Forms editor. The plugin uses the form ID as part of the consent_type (fluentforms_form_{ID}), so each form is filterable separately. The first email field of the form is used as the subject email, and the field's agreement text is what gets stored as the accepted text. Works with Fluent Forms Lite and Pro. No snippets, no functions.php edits. One setting to check on the field itself: the Terms & Conditions field has a checkbox toggle, and it is what makes the field an act of consent. With it turned off, Fluent Forms shows your terms as plain text and renders no checkbox at all, so the visitor never accepts anything and there is nothing to record. Open the field in the Fluent Forms editor and make sure the checkbox is enabled.

The most common reason is that the form has no email field. The consent log identifies the subject of every record by their email address, and the form integrations take it from the first email field of the form. Without one, an anonymous visitor cannot be identified and the submission is skipped on purpose, because a record that cannot be attributed to anybody is not evidence of anything. If the person submitting the form is logged in, the plugin falls back to the email address on their WordPress profile, so forms behind a login (members areas, course enrolments) are recorded even with no email field on the form. For public forms, add an email field. The other thing to check is that the consent field is really a consent field of the form builder, ticked by the visitor: an [acceptance] tag in Contact Form 7, a GDPR Agreement field in WPForms, a Consent field in Gravity Forms, or a GDPR Agreement or Terms & Conditions field in Fluent Forms. A plain checkbox or an HTML block with your terms in it is not detected.

It renders a self-contained consent checkbox + submit button, with optional email field for visitors who are not logged in. Submission posts to a REST endpoint that records the consent through tccl_save_consent(). Drop it in any page, post or widget area as a stand-alone block, e.g.: [tccl_consent_box text="I have read and agree to the privacy policy." consent_type="newsletter_signup"] The same functionality is also available as a Gutenberg block called "Consent box". Important: the shortcode renders its own <form> with a submit button, so it should NOT be nested inside another form builder's form (Contact Form 7, WPForms, Gravity Forms, Fluent Forms, Elementor Forms, etc.). If you embed it inside another form you will end up with two submit buttons and conflicting submit flows. For form builders, use the dedicated integration (Contact Form 7, WPForms, Gravity Forms and Fluent Forms are built in; for the rest, hook tccl_save_consent() from the relevant submission action — see the FAQ below). Also: do NOT use this shortcode as a substitute for the cookie checkbox of a cookie/banner plugin (Complianz, CookieYes, Real Cookie Banner, etc.). The legal context is different — cookie banners cover ePrivacy/cookies, this consent log covers GDPR art. 7.1 specific consents to specific personal-data processing. Mixing them yields ambiguous evidence.

The plugin hooks into the standard wp_login event (which covers both wp-login.php and the WooCommerce My Account login) and into the public registration events (register_new_user for the WP form and woocommerce_created_customer for the WC form). For each event, it inspects the submission $_POST for a ticked consent checkbox and, if one is present, writes a record with consent_type set to wp_login, wp_register, wc_login or wc_register accordingly. A few specifics worth knowing:

• "Remember me" is excluded by design. It is an ePrivacy preference about extending the session cookie, not a GDPR Article 7.1 consent. Logging it would contaminate the audit trail with non-consent events. The exclusion is hard-coded.
• No checkbox in the form, no record. The plugin does not log "raw logins" — it only writes a row when there is something resembling an explicit consent checkbox to record. A login or registration without a consent field never produces a record.
• The detector is heuristic. Field names containing consent, gdpr, privacy, terms, acceptance, agreement, accept, rgpd, politica, privacidad or terminos (case-insensitive) are treated as the consent checkbox. If your GDPR / privacy plugin uses a different name, list it in Settings → Integrations → "Custom consent field names" (comma-separated, exact match).
• The injected checkbox option fills the WooCommerce gap. WooCommerce does not include a consent checkbox in its register form out of the box — only a privacy-policy paragraph. If your site does not run a separate GDPR plugin, enable "Add a required consent checkbox to the WooCommerce registration form" in Settings; the plugin will render the checkbox above the submit button and reject the registration if it is left unticked. The same option exists for the WP register form.
• Social logins are not captured on their own. Plugins like Nextend Social Login bypass the WP login form entirely (OAuth callback), so there is no submission $_POST for the detector to inspect. See the dedicated FAQ below for the two ways to cover them.
• Every ticked box is recorded, not just the first one. Registration forms often carry a required privacy checkbox plus an optional marketing or newsletter one. Both are written as separate records. The first one detected keeps the plain flow type (wp_register, wc_register…) so your existing records and saved filters stay comparable, and each additional one appends its field name, for example wp_register_newsletter_consent. That way an optional marketing consent, which is exactly the kind a regulator asks you to evidence separately, never gets swallowed by the required one.
• The stored consent_text comes from Settings. Paste in "Consent text for login / registration" the exact wording that the visitor sees on the form (whether it comes from your GDPR plugin or from the injected checkbox), so the record reflects what was actually shown. HTML is allowed in that field, so you can include a link to your privacy policy. If your forms do not all say the same thing, open "Use a different wording per form" underneath and fill in only the ones that differ; anything left empty falls back to the site-wide text.
• Creating an account at the WooCommerce checkout does not produce a registration record. The box ticked there is the order's terms checkbox, which is already recorded as terms_and_privacy for the order itself, so counting it again as a registration consent would put something in your log the shopper never agreed to. If your checkout carries a separate consent checkbox of its own, that one is still recorded normally.

Not automatically, and that is on purpose. A social login ends in an OAuth callback coming back from Google, Facebook or Apple: there is no form submission, so there is no ticked checkbox anywhere in the request. A record written there would be a record of something nobody saw the visitor do, which is the opposite of what a consent log is for. What you can do is hand the plugin the acceptance your social login plugin already collected. Enable "Also record sign-ups created by membership, course or custom registration forms" in Settings > Integrations (that is the option covering account creation outside the WP and WooCommerce forms) and use the tccl_consent_detection_payload filter, which lets you feed the detector a payload of your own for one specific flow: add_filter( 'tccl_consent_detection_payload', function ( $payload, $context ) { if ( 'user_register' !== $context ) { return $payload; // Never touch the other flows. } // Read the acceptance wherever your social login plugin left it before // sending the visitor to the provider: a transient, a cookie, a session. if ( get_transient( 'my_social_consent' ) ) { $payload['privacy_consent'] = '1'; } return $payload; }, 10, 2 ); Two things to respect. The key you add has to look like a consent field to the detector (any name containing consent, privacy, terms, gdpr…) or be listed in "Custom consent field names". And $payload must come back untouched for every other context, or you will contaminate the detection of logins, comments and everything else running in the same request. If your social login plugin fires its own "after register" hook and you would rather write the record yourself, call tccl_save_consent() from there instead, exactly like the custom-form example further down.

Yes, by default. Only comments where the visitor ticks the native "Save my name, email, and website..." checkbox are recorded. You can opt out in Consent log > Settings > Integrations if your site uses Disqus, Jetpack Comments or any other third-party comments system where the native checkbox is not rendered. Be aware of what that native checkbox actually is, though: it asks permission to leave a cookie so the browser remembers the commenter next time. That is an ePrivacy cookie preference, the same nature as the "Remember me" box on the login form, and it is not the GDPR Article 7.1 consent to processing the name and email the commenter is handing you. For that, use the separate option described in the next FAQ.

Open Consent log > Settings > Integrations and tick "Add a required privacy checkbox to the comment form and record who accepts it". From then on:

• A privacy checkbox is rendered on the comment form, for both logged-out and logged-in visitors.
• A comment submitted without ticking it is rejected on the server, not just in the browser, so it cannot be bypassed.
• Each acceptance is stored as consent_type = comment_privacy, which keeps it clearly separate from the comment_consent cookie opt-in. Both can coexist on the same comment.
• WooCommerce product reviews go through the very same comment form and hooks, so enabling the option covers them too. There is nothing extra to configure for a shop.

Only if you enable "Also record sign-ups created by membership, course or custom registration forms" in Consent log > Settings > Integrations. The WordPress and WooCommerce options above hook the events those two fire on their own forms. A membership, LMS or custom registration plugin creates the account through the generic WordPress user-creation path instead, which those options never see. This setting adds a safety net over that generic path and stores the record as consent_type = user_register. It still requires a ticked consent checkbox in the submission, exactly like every other flow, and it never records an account you create yourself from Users > Add New, because no consent is given there. It is off by default because most sites do not need it, and because the sign-up forms of those plugins vary enough that you will want to check the first record it produces before relying on it.

Yes, since 1.7.0. Both checkouts are supported, and the Settings screen tells you what your own checkout page will record. There is one difference worth understanding, because it is a limitation of WooCommerce and not of this plugin. The checkbox in the native "Terms and Conditions" block is validated in the browser only: its value is never sent to the server, so no plugin can read it. What the plugin records depends on how that block is configured:

• Block with "Require checkbox" enabled: recorded as terms_and_privacy, the same type the classic checkout uses. The order could not have been placed without ticking the box, so acceptance is certain, and the stored text is the exact wording of the block.
• Block without a checkbox (the WooCommerce default): the block only shows an informational paragraph, so the shopper accepted by proceeding rather than by an affirmative act. That is contractually meaningful but it is not the explicit consent of Article 7.1, so it is recorded as terms_notice to keep the two apart in your evidence trail.
• No Terms and Conditions block on the page: nothing is recorded for the purchase, because nothing was shown.

Because your Terms and Conditions block has no checkbox, which is how WooCommerce ships it. The customer was shown a sentence saying that continuing implies acceptance, and never ticked anything. The plugin could record that as ordinary consent, but it would be putting an affirmative act in your log that never happened, and a consent log that overstates its evidence is worse than one that does not. This is not the plugin telling you your shop is non-compliant, and the distinction is not a warning. Processing an order rests on performing the contract (GDPR Article 6.1.b), not on consent, and accepting the terms of sale by placing the order is contractually meaningful in its own right. Whether you need an affirmative act on top of that depends on what you ask your customers to agree to, and that is your call, not the plugin's. What the plugin does is refuse to file the two under the same name. If you do want the explicit tick, enable "Require checkbox" on that block in the editor, or turn on the injected checkbox in Settings. Records already stored as terms_notice keep that type: they are the accurate account of what those customers actually saw.

Only if you write your own wording into the Terms and Conditions block, which is what the Settings screen recommends when it detects this situation. The reason is a limitation of where WooCommerce keeps that text. The default wording of the block is assembled in JavaScript and its translations live in WooCommerce's script-translation files, which PHP cannot read, so no plugin can fetch the exact sentence your visitor was shown. This plugin therefore reproduces the same sentence under its own text domain. In English both are the same string. In any other language the stored text is this plugin's translation of that sentence, which may differ word for word from WooCommerce's. Anything you type into the block is stored verbatim, in any language, with no translation involved. For a consent log that is the difference between a transcription and a reconstruction, so it is worth the two minutes in the editor. The same applies to the injected checkbox: its text comes from your own setting.

That setting, and the pre-checkout informational text next to it, only apply to the classic checkout. In the block checkout the wording lives in the Terms and Conditions block, which you edit on the checkout page itself. This is deliberate. Those records store what the block shows, not what you type in Settings, because the point of the log is to prove what the customer read.

Yes, for records taken from now on. The plugin keeps a sealed copy of your legal pages every time they change, and each record points to the copies in force when the consent was given.

• Copied without any setup: the privacy policy page of the site, and the WooCommerce terms and refund pages.
• Anything else, such as a cookie policy or a legal notice: add it in Settings > Documents in force.
• Each copy holds the text as it is read, so pages built with a shortcode or a block are covered.
• The certificate of a record lists its documents and says whether they have changed since.
• Private pages and pages behind a password are not copied.

The page was rendered before the plugin was updated and is being served from a page cache. Purge the cache and it will work again. The form carries a payload signed by the server with the exact text it shows, and the plugin only records what that payload says. A form with no payload, or with one that has been altered, is rejected.

You are looking at it in a preview, a draft or the editor, and you cannot publish posts.

• Whoever edits a draft decides its wording, so the form there is not signed and its button is disabled.
• It works on the published page.
• Users who can publish see it working in previews too.

Something is closing the WordPress REST API to anonymous visitors, usually a security plugin set to allow it only for logged-in users. The consent box sends its form to /wp-json/tccl/v1/consent, so that route has to stay public. Allow the tccl/v1 namespace in that plugin, or switch it to a mode that only blocks the routes you choose.

In a custom indexed table called wp_tccl_consents (with your site prefix). The sealed copies of your legal pages live in a second table, wp_tccl_snapshots. When WooCommerce is active, each order also gets three meta entries (_tccl_terms_accepted, _tccl_terms_version, _tccl_recorded_at) so the order edit screen can show the summary without querying the table.

Edit the version field in Consent log > Settings, or simply check "Bump version on save". The plugin can also bump it automatically if it detects the checkbox text has changed but the version field has not. Three things to keep in mind:

1. The version string in Settings must match the version label of your terms document character by character (e.g. 1.1-2026-05-17). It is a free-text identifier and the plugin just compares strings, so a trailing space or a different separator will be treated as a different version.
2. Once you bump the version, every record stored under the previous version is automatically flagged as "Outdated" in the records list. This is on purpose — it is the GDPR audit trail showing which exact wording each subject accepted at that moment. "Outdated" is a feature, not a bug.
3. Do NOT delete or "clean up" Outdated records. They are the legal proof of consent for the version that was in force when the subject accepted it. If the user retires the terms and a regulator later asks for evidence, those rows are what you show them.

Use the WordPress native Tools > Erase Personal Data screen. The plugin registers an eraser that anonymises records linked to the requested email (it does not delete them, since the record itself is the lawful basis to keep the proof of consent). You can also anonymise filtered records from the Records tab.

Use Tools > Export Personal Data. The plugin registers an exporter that returns every consent record linked to the requested email, and the documents in force when each one was given, with their text.

Only if you explicitly opt in. The setting "Delete all data on uninstall" is off by default. Even if you uninstall accidentally, your consent evidence will survive. If you need to clean up a handful of test rows you generated while configuring the plugin (and you do not yet have the upcoming bulk-delete UI), you can remove them with a direct SQL statement against the consent table, e.g.: DELETE FROM wp_tccl_consents WHERE id IN (1, 2, 3); Replace wp_ with your site's actual table prefix. This is an escape hatch for legitimate clean-up after a misconfigured form; it is not a recommended day-to-day flow — to handle real subject requests, use Tools > Erase Personal Data (anonymises) instead.

Contact Form 7, WPForms, Gravity Forms and Fluent Forms are captured automatically once you enable their toggle in Settings > Integrations; no code is needed for those four. For any other source, call the public tccl_save_consent() function from that plugin's submission hook. Always read the document version from the plugin setting (tccl_get_setting( 'consent_version', '1.0' )) so all records line up with the current version in Settings — if you hardcode a date that differs from the one in Settings, every record will be flagged as "Outdated" forever. add_action( 'the_submission_hook_of_your_form_plugin', function ( $submission ) { tccl_save_consent( array( 'email' => sanitize_email( $submission['email'] ), // however your plugin exposes the email 'consent_type' => 'my_custom_form', 'consent_version' => tccl_get_setting( 'consent_version', '1.0' ), 'consent_text' => 'I have read and agree to the privacy policy.', 'consent_value' => 1, ) ); } ); Common hooks to adapt this to: elementor_pro/forms/new_record, forminator_custom_form_after_submission, user_register. Adjust the callback signature and how you read the email and the acceptance to each plugin's documented arguments.

The plugin reads REMOTE_ADDR only and does not trust forwarded headers, which can be spoofed without a verified proxy. If your hosting puts the proxy IP in REMOTE_ADDR instead of the real client IP, all entries will record the proxy IP. Most WordPress-friendly hostings pass the real IP correctly.

When a consent is written, the plugin computes a SHA-256 hash of the exact accepted text and stores it alongside the record. On every read, the stored hash is compared against a freshly computed one — any difference is reported as TAMPERED in the records list, the order metabox and the certificate view. This is a cryptographic integrity check, not an electronic signature.

The plugin renders a one-page A4 view with print-optimised CSS and a "Print / Save as PDF" button. Modern browsers (Chrome, Safari, Firefox, Edge) export that view to a real PDF natively — same fidelity as a server-side library would produce, with the added benefit that it respects your site's language and fonts. No external library bundled, so the plugin stays small. To be clear: the plugin does NOT store any PDFs on disk and does NOT create an uploads folder of its own. The certificate is generated on demand as HTML each time you open it, and only becomes a PDF if you (or the customer) clicks "Print / Save as PDF" in the browser. There is nothing to clean up on the server. If the site has a Site Icon defined in Settings > General (the same option block themes and classic themes share), it is shown in the certificate header next to the site name — including on certificates of consents recorded before this version, since the icon is added at render time, not at storage time.