DB Form Builder

Plugin WordPress per la creazione di form con drag & drop, logica condizionale, upload file, multi-step e webhook.

Autore: Davide Bertolino
Sito: https://www.davidebertolino.it
Email: info@davidebertolino.it
Licenza: GPL v2 or later

Funzionalità

• Form Builder drag & drop — 14 tipi di elemento con riordino visuale
  • Input: Testo, Email, Textarea, Select, Checkbox, Radio, Telefono, Numero, Data, URL, Upload file
  • Contenuti: Testo/HTML statico, Immagine, Separatore
  • Struttura: Cambio pagina (multi-step)
• Logica condizionale — Mostra/nascondi campi in base alle risposte (8 operatori, AND/OR)
• Upload file — Drag & drop o click, estensioni configurabili, dimensione max per campo, file multipli, validazione client + server
• Form multi-step — Barra di progresso, navigazione avanti/indietro, validazione per step
• Webhook — POST JSON a URL esterno dopo ogni invio (compatibile Zapier, Make, n8n)
• Protezione anti-spam — Google reCAPTCHA v2/v3 (consent-gated 2.3.0+) + Honeypot invisibile
• Privacy by design (2.3.0+):
  • IP hashato SHA-256 di default (modalità configurabile: hash / nessuno / chiaro)
  • Retention automatica delle submission (cron giornaliero, default 365 giorni)
  • Right of erasure GDPR art. 17 (cancellazione singola/bulk/totale dalla UI)
  • Trust dei proxy header solo via filter esplicito (anti-spoofing)
  • Dichiarazione automatica dei trattamenti al DB SEO Manager
• GDPR / Privacy — Checkbox consenso obbligatorio con link alla Privacy Policy
• Limite invii per IP — Configurabile per form (max N invii in X minuti), funziona anche con IP hashato/non salvato
• Email personalizzabili — Conferma utente + notifica admin (più destinatari) con placeholder dinamici
• Gestione risposte — Dettaglio modale, elimina singole/bulk/tutte, export CSV, file come link scaricabili
• Duplica form — Copia campi e impostazioni con un click
• Anteprima — Visualizza il form nel builder prima di pubblicare
• Template predefiniti — 5 modelli pronti all'uso
• Integrazione WordPress — Shortcode, blocco Gutenberg, widget classico
• Accessibilità WCAG 2.1 AA — ARIA completo, focus management, contrasto, reduced motion, high contrast mode

Privacy by design (2.3.0+)

Il Form Builder gestisce dati personali (le submission contengono PII per definizione: nome, email, messaggi, allegati). La 2.3.0 introduce un set di funzionalità che riducono i rischi GDPR:

Modalità di salvataggio dell'IP

Form Builder → Impostazioni → Privacy → Modalità salvataggio IP. Tre opzioni:

• hashed (default raccomandato): SHA-256 con salt da wp_salt('auth'), irreversibile in pratica. Lo stesso visitatore produce sempre lo stesso hash → il rate limiting funziona correttamente. L'IP in chiaro non viene mai salvato a DB.
• none: nessun IP loggato. Il rate limiting continua a funzionare usando l'hash dell'IP come chiave del transient (mai persistito).
• full: IP in chiaro. Solo se hai un motivo legittimo e documentato. Sconsigliato.

Il cambio di modalità impatta solo le nuove submission. Quelle esistenti restano invariate.

Retention automatica

Form Builder → Impostazioni → Privacy → Retention submission. Default 365 giorni. Un cron giornaliero (dbfb_cleanup_submissions) cancella tutto ciò che è più vecchio della soglia. Cap di sicurezza: 10000 righe per esecuzione (le rimanenti vengono cancellate il giorno dopo). Valore 0 = retention illimitata, sconsigliato per art. 5.1.e GDPR.

Pulsante "Pulisci ora" per esecuzione manuale immediata. Action hook dbfb_cleanup_submissions_done($deleted, $days) per integrazioni (notifica admin, log esterno, ecc.).

Right of erasure (art. 17)

Pagina submissions di un form: tre meccanismi:

1. "Elimina" singola riga (già nella 2.2.0)
2. "Elimina selezionate" dopo bulk-select (già nella 2.2.0)
3. 🗑️ "Cancella TUTTE (N)" per cancellare in un click tutte le risposte del form (nuovo in 2.3.0). Conferma esplicita con il numero di righe.

In tutti e tre i casi, i file allegati vengono cancellati dal disco insieme alla riga DB (2.4.0+).

Right of access + erasure via email (DSAR — art. 15 + 17)

A partire dalla 2.5.0, il Form Builder è integrato con la macchina nativa di WordPress per le DSAR. L'admin trova in Strumenti → Esporta dati personali e Strumenti → Cancella dati personali un'interfaccia che permette, data un'email:

• Esporta dati: WP genera uno ZIP scaricabile contenente tutte le submission che hanno quell'email come valore di un campo di tipo email. Include nome del form, data invio, valori dei campi, nomi e URL degli allegati, IP (rispetta storage mode).
• Cancella dati: WP cancella tutte le stesse submission insieme ai loro file allegati. Output: numero di submission rimosse + numero di file cancellati.

Il matching è esatto e case-insensitive: l'email deve corrispondere al valore di un campo type=email del form (non l'email che appare casualmente nel testo di un campo Messaggio).

Per form legacy con campi di tipo text usati come email, estendi i match via filter:

add_filter('dbfb_dsar_email_field_ids', function($field_ids, $form_id, $form_fields) {
    foreach ($form_fields as $f) {
        if (($f['id'] ?? '') === 'mio_legacy_email_field') {
            $field_ids[] = 'mio_legacy_email_field';
        }
    }
    return $field_ids;
}, 10, 3);

Trust dei proxy header

Per default X-Forwarded-For, CF-Connecting-IP, X-Real-IP sono ignorati per evitare IP spoofing. Per siti dietro proxy/CDN affidabili (Cloudflare, Varnish):

add_filter('dbfb_trust_proxy_headers', '__return_true');

Stesso pattern di DB Cookie Manager.

Disinstallazione (2.3.1+)

WordPress non chiede conferma prima di chiamare uninstall.php, quindi il comportamento si decide in anticipo via Form Builder → Impostazioni → Privacy → Cancellazione dati alla disinstallazione.

Soft (default, checkbox OFF): alla disinstallazione vengono rimossi solo le option del plugin, i transient di rate limit, e lo scheduling del cron. Restano in DB la tabella delle submission, i form definiti (CPT dbfb_form) e gli allegati nella Media Library. Pensato per disinstallazioni temporanee — se reinstalli, ritrovi tutto.

Hard (checkbox ON): alla disinstallazione viene fatto DROP TABLE wp_dbfb_submissions, vengono cancellati tutti i post di tipo dbfb_form (con i relativi post meta), tutti i file allegati delle submission dal disco, le sottocartelle vuote in wp-content/uploads/dbfb/, i file di sicurezza (.htaccess, index.php) e le option del plugin. Operazione irreversibile. Quando attivi il checkbox, l'UI mostra un alert giallo che riepiloga cosa accadrà.

Integrazione con DB Cookie Manager, DB Privacy Hub, DB SEO Manager

Quando uno o più di questi plugin sono installati, il Form Builder li sfrutta automaticamente — senza configurazione.

Consent gate per reCAPTCHA

Lo script Google reCAPTCHA viene caricato solo se l'utente ha dato consenso marketing (o se il sito non ha alcun consent manager). Quando il consenso manca:

• Il widget reCAPTCHA è sostituito da un placeholder informativo che invita a modificare le preferenze cookie.
• Il submit-side resta protetto da rate limit + honeypot (sempre attivi).
• Quando l'utente accetta marketing, la pagina si ricarica automaticamente (listener su dbcm:consent) e il widget compare.

Compatibile con: DB Cookie Manager 3.0.0+, qualsiasi plugin che esponga wp_has_consent() (Cookiebot, Complianz, Real Cookie Banner via WP Consent API). Per siti senza consent manager, il comportamento è identico alla 2.2.0 (carica sempre).

Filter per casi avanzati:

// Disabilitare il consent gate (admin scelta esplicita)
add_filter('dbfb_recaptcha_consent_required', '__return_false');

// Cambiare la categoria di consenso richiesta (default: 'marketing')
add_filter('dbfb_recaptcha_category', function() { return 'functional'; });

Quando DB SEO Manager Hard Privacy è attivo, reCAPTCHA è disattivato in modo incondizionato (coerente con il significato di "Hard Privacy").

Dichiarazione trattamenti al registro privacy unificato

Quando DB Privacy Hub 1.0.0+ è installato, il Form Builder dichiara automaticamente fino a 4 trattamenti nel pannello "Privacy → Registro trattamenti" e li propaga nella Privacy Policy generata. Per retrocompatibilità, lo stesso aggancio funziona anche con il vecchio DB SEO Manager 1.2.x (dalla 1.3.0 il SEO Manager non gestisce più il registro privacy: la responsabilità è migrata nell'Hub).

ID	Quando appare
dbfb_submissions	almeno 1 form pubblicato
dbfb_email_notifications	almeno 1 form ha notifica admin o conferma utente
dbfb_recaptcha	reCAPTCHA configurato globalmente E almeno 1 form lo usa
dbfb_webhooks	almeno 1 form ha webhook attivo (con elenco host destinatari deduplicato)

Le voci sono dinamiche: riflettono in tempo reale ip_storage_mode, submissions_retention_days, host webhook configurati. L'admin può copiare i testi nelle proprie informative privacy.

DSAR routing via Privacy Hub

Quando il Privacy Hub è installato, le DSAR (richieste di accesso e cancellazione) del Form Builder vengono registrate via i filter dbph_user_data_exporters / dbph_user_data_erasers, non direttamente sui filter core di WordPress. Questo permette all'Hub di tracciare ogni richiesta nel suo "Storico DSAR" (tabella wp_dbph_dsar_log) con timestamp di richiesta, conferma e completamento.

Senza l'Hub, il Form Builder si registra direttamente sui filter core di WordPress (wp_privacy_personal_data_exporters/erasers), come faceva nella 2.8.0. Comportamento standalone identico, niente regressioni.

Marker DBFB_DSAR_AVAILABLE

Costante definita in db-form-builder.php (define('DBFB_DSAR_AVAILABLE', true)). Letta dal Privacy Hub per decidere se inserire la menzione "procedura DSAR semplificata via Strumenti → Esporta/Cancella dati personali" nella sezione "Diritti dell'interessato" della Privacy Policy generata.

Filter pubblici

Filter	Default	Uso
dbfb_trust_proxy_headers	false	Fidati di X-Forwarded-For/CF-Connecting-IP/X-Real-IP
dbfb_recaptcha_consent_required	true	Gate reCAPTCHA al consenso (false = scarica sempre)
dbfb_recaptcha_category	'marketing'	Categoria di consenso richiesta per reCAPTCHA
dbfb_dsar_email_field_ids	[] (auto)	Estende i campi considerati come "email" per il matching DSAR (2.5.0+)

Action: dbfb_cleanup_submissions_done($deleted, $days) — emessa dopo ogni esecuzione del cron retention.

Installazione

1. Carica la cartella db-form-builder in /wp-content/plugins/
2. Attiva il plugin dal menu Plugin
3. Vai su "Form Builder" nel menu admin

Configurazione

reCAPTCHA

1. Vai su Form Builder > Impostazioni
2. Inserisci Site Key e Secret Key da Google reCAPTCHA
3. Abilita il CAPTCHA singolarmente per ogni form

Honeypot

Attivabile per form. Campo nascosto + verifica tempo di compilazione. Nessun impatto visivo.

GDPR

Checkbox obbligatorio configurabile con testo e link alla Privacy Policy.

Limite invii per IP

Massimo N invii in X minuti dallo stesso IP, configurabile per form.

Logica condizionale

Per ogni campo, abilita "Logica condizionale" nelle impostazioni:

• Scegli Mostra/Nascondi
• Seleziona il campo trigger, l'operatore e il valore
• Aggiungi più regole con logica AND (tutte) o OR (almeno una)
• Operatori: uguale, diverso, contiene, non contiene, vuoto, non vuoto, maggiore di, minore di

Upload file

Trascina il campo "Upload file" nel builder e configura:

• Estensioni ammesse (default: jpg, jpeg, png, gif, pdf, doc, docx, xls, xlsx, zip)
• Dimensione massima per file (default: 5 MB)
• File multipli sì/no
• I file vengono salvati in wp-content/uploads/dbfb/{form_id}/

Multi-step

Trascina "Cambio pagina" tra i campi per dividere il form in step. Il frontend mostra automaticamente barra di progresso, bottoni Indietro/Avanti e validazione per step.

Webhook (2.7.0+: async, retry, HMAC)

Attivabile per form. Inserisci l'URL e ad ogni invio il plugin fa un POST JSON con form_id, form_title, submitted_at, ip, fields (array con id, label, type, value) e raw_data. Compatibile con Zapier, Make, n8n, endpoint custom.

Affidabilità. Le deliveries sono asincrone (via WP cron). In caso di errore transient (timeout di rete, HTTP 5xx, 408, 429) il plugin ritenta automaticamente fino a 5 volte con backoff esponenziale: 1 minuto → 5 minuti → 30 minuti → 2 ore → 12 ore. Errori 4xx permanenti (400, 401, 403, 404, ecc.) vengono registrati come failed senza retry. Le deliveries esaurite finiscono nello stato dead per ispezione manuale.

Diagnostica visibile in Form Builder → Webhook Deliveries: tabella con filtro per stato, ultimo errore, status code HTTP, prossimo retry, retry/cancellazione bulk.

Autenticazione del payload (HMAC SHA-256). Per ogni form puoi configurare un Webhook Secret. Quando presente, ogni POST include questi header:

X-DBFB-Timestamp: 1746201234
X-DBFB-Signature: sha256=8f7a3...
X-DBFB-Delivery-Id: 1234
X-DBFB-Attempt: 1

La signature è hmac_sha256(timestamp + "." + raw_body, secret). Verifica lato destinatario in pseudocode:

expected = "sha256=" + hmac_sha256(secret, timestamp_header + "." + raw_request_body)
if not constant_time_compare(expected, signature_header):
    return 401
if abs(now() - int(timestamp_header)) > 300:  # max 5 min
    return 401

Pattern industry-standard usato da Stripe e GitHub. Il timestamp protegge da replay attack.