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.

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.