TL;DR: un test di un form WordPress non deve mai usare la posta reale come banco di prova. Sposta il sito in staging, intercetta l’SMTP con una inbox locale e applica una allowlist ai destinatari prima di far generare casi di test all’AI.

Il problema sembra banale: modifichi un form, chiedi all’AI di preparare dieci casi di prova e li esegui. Se lo staging conserva l’SMTP di produzione, però, quei messaggi possono arrivare a clienti, collaboratori o indirizzi presenti nella configurazione del sito. Il test funziona tecnicamente, ma crea un incidente operativo.

La soluzione: separare test e consegna

La regola è semplice: l’AI può generare dati, scenari e controlli; non deve decidere dove recapitare le email. Il destinatario è un vincolo dell’ambiente, non del prompt.

WordPress espone wp_get_environment_type() e riconosce quattro ambienti: local, development, staging e production. Questo permette di applicare una policy diversa fuori dalla produzione. Sullo staging, tutte le email devono finire in una casella di cattura come Mailpit oppure essere riscritte verso un indirizzo di test autorizzato.

Tre passaggi essenziali

  1. Dichiara l’ambiente. Imposta WP_ENVIRONMENT_TYPE su staging e verifica il valore dal pannello diagnostico o con WP-CLI. Se il valore non è valido o manca, WordPress usa production: non dare per scontato che lo staging sia riconosciuto.
  2. Intercetta l’uscita SMTP. Collega WordPress a Mailpit o a un servizio equivalente che catturi i messaggi. Mailpit espone un server SMTP e una UI per controllare destinatari, oggetto, HTML, allegati e link senza consegnare la posta all’esterno.
  3. Applica una allowlist. Prima dell’invio, riscrivi o blocca ogni destinatario che non appartiene all’elenco di test. La regola deve coprire To, Cc e Bcc. Conserva nel log il destinatario originale, ma evita dati personali nel contenuto di prova.

A questo punto l’AI può creare casi utili: campi obbligatori mancanti, email malformate, messaggi lunghi, allegati non ammessi e invii ripetuti. Usa dati sintetici e controlla il messaggio catturato, non soltanto il messaggio di conferma mostrato dal form.

L’errore da evitare

Non considerare true restituito da wp_mail() come prova di consegna. La documentazione WordPress chiarisce che indica solo che il metodo ha elaborato la richiesta senza errori. Il test deve verificare almeno destinatario riscritto, oggetto, corpo, header e presenza del messaggio nella inbox di cattura.

Prima di intervenire su plugin, tema o configurazione SMTP, conviene anche seguire una procedura di aggiornamento con backup e verifica separata: questa checklist per aggiornare WordPress senza fermare il sito offre una base pratica.

Take finale

Il controllo più efficace non è un prompt più prudente. È un’infrastruttura che rende impossibile spedire fuori dal perimetro di test. Se la sicurezza dipende dal fatto che qualcuno si ricordi di cambiare un indirizzo, il processo è già fragile.

Fonti