Terms & Conditions Consent Log

FAQ

Can I use the plugin without WooCommerce?

Yes. Activate it on any WordPress site and the menu appears under Users > Consent log. 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.

How do I capture consents from Contact Form 7?

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.

How does the [tccl_consent_box] shortcode work?

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 (CF7 is built in; for the rest, hook tccl_save_consent() from the relevant submission action — see the Gravity Forms / WPForms 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.

Are WordPress comment opt-ins logged automatically?

No, they are off by default. Enable them in Consent log > Settings > Integrations. Only comments where the visitor ticks the native “Save my name, email, and website…” checkbox are recorded.

Does it work with the new WooCommerce Block Checkout?

Not yet. The classic checkout is fully supported. Block Checkout support is on the roadmap.

Where is the data stored?

In a custom indexed table called wp_tccl_consents (with your site prefix). 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.

How do I bump the document version when I change my terms?

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.

How do I delete or anonymise data for a specific customer?

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.

How do I export a customer’s consent history?

Use Tools > Export Personal Data. The plugin registers an exporter that returns every consent record linked to the requested email.

Will an uninstall destroy my data?

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.

How do I capture consents from Gravity Forms, WPForms, or any other source?

Call the public tccl_save_consent() function from the relevant 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 here that differs from the one in Settings, every record will be flagged as “Outdated” forever.

Example for Gravity Forms:

add_action( 'gform_after_submission', function ( $entry, $form ) {
    if ( ! empty( $entry['1.1'] ) ) { // ID of your consent checkbox in the entry.
        tccl_save_consent( array(
            'email'           => sanitize_email( $entry['2'] ?? '' ),
            'consent_type'    => 'gravity_form_' . absint( $form['id'] ),
            'consent_version' => tccl_get_setting( 'consent_version', '1.0' ),
            'consent_text'    => 'I have read and agree to the privacy policy.',
            'consent_value'   => 1,
        ) );
    }
}, 10, 2 );

Example for WPForms (a few things differ from Gravity Forms — read the comments):

add_action( 'wpforms_process_complete', function ( $fields, $entry, $form_data, $entry_id ) {
    // 1) Only act on the form(s) you want. Use the WPForms map below if you have several.
    $forms = array(
        // form_id => array( 'email' => email_field_id, 'checkbox' => gdpr_field_id ),
        123 => array( 'email' => 5, 'checkbox' => 7 ),
    );
    $form_id = (int) $form_data['id'];
    if ( ! isset( $forms[ $form_id ] ) ) {
        return;
    }
    $map = $forms[ $form_id ];

    // 2) The GDPR Agreement checkbox must be ticked.
    if ( empty( $fields[ $map['checkbox'] ]['value'] ) ) {
        return;
    }

    tccl_save_consent( array(
        'email'           => sanitize_email( $fields[ $map['email'] ]['value'] ?? '' ),
        'consent_type'    => 'wpforms_form_' . $form_id,
        'consent_version' => tccl_get_setting( 'consent_version', '1.0' ),
        'consent_text'    => 'I have read and agree to the privacy policy.',
        'consent_value'   => 1,
    ) );
}, 20, 4 );

Two critical details specific to WPForms:

• accepted_args=4 is mandatory (the , 20, 4 at the end of add_action). Without it, the callback never receives $fields, the if ( empty( $fields[...] ) ) check evaluates to true on every submission and nothing is recorded. This is the most common copy-paste mistake when adapting a Gravity Forms snippet.
• You need both field IDs: the email field ID and the GDPR Agreement checkbox field ID. To find them, open the form in WPForms (the URL contains form_id=X — that is the form ID) and click each field in the builder; the right-hand sidebar shows the field ID under “Advanced”.

Same idea for fluentform/submission_inserted, user_register, forminator_custom_form_after_submission, elementor_pro/forms/new_record, etc. — adapt the callback signature to each plugin’s documented arguments.

Does the IP detection work behind Cloudflare or other reverse proxies?

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.

What does “Tamper-evident” mean here?

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.

Is the certificate a real PDF?

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.