Qualche giorno fa ho affrontato un’altra sfida di programmazione relativa al mio nuovo progetto, Ideomatica. Volevo collegare il formulario di contatto con il nostro sistema di mail marketing, Brevo.

Alcuni campi del modulo (nome, cognome, email e telefono) vengono trasmessi a Brevo senza necessità di intervenire sul codice. Tuttavia, volevo andare un passo più in là e sincronizzare anche le altre informazioni che riceviamo, come il consenso (opt-in), l’autorizzazione a inviare la newsletter e la lingua del contatto.

Sembrava un’operazione semplice.

Inizialmente avevo trovato online un tutorial di un’agenzia di marketing con il codice da inserire in functions.php per inviare i dati tramite l’API di Brevo.

Il file functions.php è il cuore della personalizzazione di un tema WordPress. Serve a definire funzioni personalizzate, aggiungere o modificare funzionalità del tema e interagire con i plugin e le API di WordPress.

In pratica, è il posto giusto per aggiungere codice PHP che estenda il comportamento standard di WordPress, come:

• registrare nuove funzioni e shortcode;
• modificare il comportamento di hook e filtri;
• includere script e stili personalizzati;
• interagire con plugin come Contact Form 7 o WooCommerce.

Ogni tema WordPress ha un suo functions.php, e quando viene attivato il tema, WordPress esegue il codice contenuto in quel file.

Nel mio caso, il codice intercettava l’invio del modulo tramite l’hook wpcf7_mail_sent e poi, con una richiesta API via cURL, registrava i contatti in Brevo.

Tutto perfetto sulla carta, ma nella pratica il sistema non funzionava. Si bloccava proprio l’esecuzione e invio del modulo.

A questo punto ho deciso di cambiare strategia.

Dopo aver consultato la documentazione di Contact Form 7, il sistema che usiamo su WordPress per creare i moduli, ho proposto a ChatGPT di usare un altro hook, wpcf7_sendinblue_collect_parameters, più adatto perché agisce direttamente sulla logica di integrazione tra Contact Form 7 e Brevo. Questa scelta avrebbe reso il codice più pulito, eliminando la necessità di eseguire chiamate API manuali.

Passare a questo approccio sembrava la soluzione definitiva, ma mi sono subito imbattuto in una serie di problemi che ho dovuto risolvere uno per uno.

Il primo errore: il codice non si eseguiva

Anche dopo aver implementato il filtro wpcf7_sendinblue_collect_parameters, non succedeva nulla.

Zero.

Nessun errore visibile, nessun dato inviato a Brevo.

Il primo dubbio è stato: il file functions.php viene effettivamente letto da WordPress?

Per verificarlo, ho attivato il debug di WordPress aggiungendo nel file wp-config.php queste righe:

define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);
@ini_set('display_errors', 0);

A questo punto avrei dovuto poter consultare il file wp-content/debug.log, ma il file non veniva creato.

Dopo un po’ di indagini, ho scoperto che il problema era in una riga di codice già presente in wp-config.php:

if ( ! defined( 'WP_DEBUG' ) ) {
    define( 'WP_DEBUG', false );
}

Questa condizione impediva di attivare il debug, perché WP_DEBUG veniva bloccato su false. La soluzione è stata decommentare la riga, assicurandomi che WP_DEBUG fosse attivo.

Una volta risolto questo problema, ho aggiunto un test nel file functions.php per verificare che venisse effettivamente eseguito:

error_log("functions.php caricato correttamente");

Dopo aver visto finalmente questa riga nel file debug.log, sono potuto passare al problema successivo.

L’ID del modulo: una questione più complicata del previsto

Nel codice avevo scritto questa condizione:

if ($form_id == 'c496770') { ... }

Perché quel valore? Perché era quello che vedevo nella configurazione del modulo, accanto al nome.

Tuttavia, Contact Form 7 utilizza solo ID numerici e non include lettere. Il codice quindi non stava mai trovando una corrispondenza. Per essere sicuro dell’ID esatto, ho aggiunto questo debug:

error_log("CF7 Form ID ricevuto: " . print_r($contact_form->id(), true));

Dopo aver inviato un modulo di prova e controllato debug.log, ho scoperto che l’ID corretto era 125. Una volta corretto questo errore, il codice ha iniziato a eseguire l’hook correttamente, ma i problemi non erano finiti.

I dati del modulo non venivano passati correttamente

Il filtro wpcf7_sendinblue_collect_parameters teoricamente accetta due argomenti: $parameters e $contact_form. Ma quando ho controllato il log, ho visto che veniva passato solo $parameters.

Per aggirare il problema, ChatGPT mi ha consigliato di usare un metodo alternativo per ottenere il form attivo:

$contact_form = WPCF7_ContactForm::get_current();

Con questa modifica, sono finalmente potuto accedere ai dati del modulo per poterli manipolare.

Il numero di telefono nel formato sbagliato

Una volta risolti i problemi di base, ho notato un altro errore. Brevo rifiutava il numero di telefono con un messaggio di «Invalid phone number».

Il problema era il formato. Gli utenti potevano inserire il numero con spazi, trattini o senza prefisso internazionale. Brevo invece si aspettava il numero in uno di questi formati:

• +34XXXXXXXXX
• 0034XXXXXXXXX

La soluzione è stata ripulire il numero e forzare il formato corretto:

$phone_number = preg_replace('/\D/', '', $posted_data['your-phone'] ?? ''); // Rimuove caratteri non numerici

if (!empty($phone_number) && preg_match('/^\d{9,15}$/', $phone_number)) {
    if (!preg_match('/^(34|0034|\+34)/', $phone_number)) {
        $phone_number = "34" . $phone_number;
    }
    $parameters['SMS'] = "+" . $phone_number;
}

Ora, se l’utente inserisce "612345678", il codice lo trasforma automaticamente in +34612345678, evitando errori.

L’ultimo tocco: la lingua

Visto che il sito al momento è solo in spagnolo e il modulo 125 sarà sempre in quella lingua, ho deciso di hardcodare il valore LANGUAGE = 3. Infatti nella nostra installazione di Brevo abbiamo un attributo aggiuntivo dei contatti con la lingua preferita per le comunicazioni. Poiché si tratta di un attributo a scelta singola da un elenco, è meglio indicare l’ID. Quello corrispondente allo spagnolo è il 3.

Per inviare questo dato a Brevo è bastato aggiungere una riga:

$parameters['LANGUAGE'] = 3;
error_log("Lingua assegnata a LANGUAGE: " . $parameters['LANGUAGE']);

Ora, ogni contatto che si iscrive tramite il form 125 ha automaticamente la lingua impostata su spagnolo (ES).

Divide et impera

Dopo aver sistemato

• il file functions.php non letto
• il file di debug non scritto
• l’ID del modulo sbagliato
• i dati del modulo non ricevuti
• il numero di telefono nel formato errato
• l’attributo LANGUAGE aggiuntivo

finalmente tutto funziona come dovuto.

Lezioni apprese

Innanzi tutto, avendo conoscenze di PHP limitatissime, per non dire nulle, tutto quello che ho ottenuto sarebbe stato impossibile senza il ricorso a ChatGPT.

Poi ci sono alcune lezioni molto chiare:

1. Non dare per scontato che Contact Form 7 faccia esattamente quello che pensi.
2. Abilita sempre il debug e controlla debug.log per evitare di perdere tempo.
3. Verifica la documentazione per capire quali sono i formati
4. Inserire LANGUAGE come hardcoded è un trucco utile per segmentare i contatti automaticamente.

Alla fine, anche le sfide più frustranti diventano lezioni preziose. Se stai cercando di fare qualcosa di simile, il mio consiglio è: testa ogni passaggio e non sottovalutare il debug.

Se ti serve una mano con qualche integrazione simile, sarò felice di aiutarti.