Errore 'Headers already sent': come fixarlo

Strettamente legato al precedente, l’errore 'Headers already sent by ...' compare quando WordPress prova a settare cookie o redirect dopo che gli header sono partiti. La differenza rispetto al 'Cannot modify' è che qui il messaggio include la posizione esatta dell’output, semplificando il debug.

Differenza rispetto a Cannot modify header

I due messaggi sono spesso correlati ma il 'Headers already sent' indica esplicitamente file:riga dove è partito l’output. Su PHP moderni il messaggio è un'E_WARNING e non interrompe l’esecuzione, ma le funzioni che modificano header (setcookie, wp_redirect) falliscono silenziosamente.

Impatto sui plugin di sicurezza

Plugin tipo Wordfence o iThemes Security usano cookie per autenticazione: se gli header sono già inviati, l’utente non riesce più a loggarsi. WP Error Monitor segnala questo come pattern critico anche se il messaggio originale è solo E_WARNING, perchè l’impatto utente è bloccante.

Cleanup automatico

Tramite l’opzione 'auto_cleanup_bom' nelle impostazioni del sito, WP Error Monitor può offrire un cleanup automatico via WP-CLI: scansiona la cartella wp-content/plugins e themes, individua file PHP con BOM o whitespace iniziale e crea un report. Non modifica nulla automaticamente, ti permette di rivedere prima di applicare.

Esempio scan-bom output

Il comando wp wpem scan-bom produce output del tipo: 'Found 3 files with BOM/whitespace: wp-content/plugins/foo/foo.php (BOM at line 1), wp-content/themes/bar/functions.php (whitespace before php tag at line 1), wp-content/plugins/baz/init.php (trailing whitespace after closing tag)'. Ogni record include path, tipo di problema, riga, severità. L’output JSON è processabile da CI/CD: blocca deploy se trovi BOM in file modificati. Configura come pre-commit hook con husky o gitlab-ci.

Plugin terze parti con BOM

Molti plugin distribuiti hanno BOM perché autori usano IDE Windows non configurati. Lo scopri solo dopo l’installazione. Strategia: 1) installa il plugin, 2) lancia wp wpem scan-bom, 3) se trovi BOM apri issue al plugin author, 4) intanto crea patch locale rimuovendo BOM, 5) documenta la patch (es. in file PATCHES.md) per non perderla con update. Alternativa: usa plugin manager che applica patch in fase di install (Composer + WPackagist).

CI/CD enforcement encoding

Per progetti gestiti con Git, configura .gitattributes per enforcere encoding: '*.php text eol=lf working-tree-encoding=UTF-8'. Git rifiuta commit con encoding sbagliato. In CI/CD aggiungi step 'check encoding': script bash che valida ogni .php in fullchain UTF-8 senza BOM. Esempio script: 'find . -name *.php -exec file -bi {} ; | grep -v UTF-8 && exit 1'. Così' impossibile mergiare codice con BOM. Su monorepo grande, lo script gira solo sui file modificati per velocità. Beneficio collaterale: encoding uniforme aiuta anche tools come grep, sed, awk.

Linter PHP integrato in editor

Configurare il linter PHP nell’editor previene errori a digitazione, non solo a commit. PHPStan, Psalm, php-cs-fixer integrati con VSCode/PhpStorm marcano in tempo reale: BOM in file (con plugin EditorConfig), trailing whitespace, codifica errata. Lo sviluppatore vede l’errore mentre scrive e fixa subito. Setup: .editorconfig nella root del progetto con 'charset=utf-8' e 'insert_final_newline=true', plus plugin EditorConfig in IDE. Tempo di setup: 10 minuti. Risparmio tempo nel lungo periodo: ore.

Audit periodico anti-BOM

L’audit periodico anti-BOM dovrebbe essere parte della manutenzione preventiva di ogni sito WordPress gestito: schedula 'wp wpem scan-bom' settimanale via cron, salva l’output JSON in archivio, alerta se trova nuovi file con BOM (segnale di plugin/tema aggiornato male). In aggiunta, dopo ogni installazione/aggiornamento di plugin non da repository ufficiale, lancia manualmente lo scan per intercettare BOM introdotti. Il tempo di esecuzione è breve (5-30 secondi tipici) e il valore preventivo molto alto: evita ore di debug futuro.

Procedura passo-passo

1. Apri WP Error Monitor e filtra 'severity >= WARNING' + 'message contains Headers already sent'.
2. Apri l’evento e annota il file colpevole.
3. Lancia WP-CLI: wp eval 'wpem_scan_bom();' (richiede plugin WP Error Monitor companion installato).
4. Esamina il report e correggi i file segnalati uno alla volta.
5. Per ogni file: scarica, rimuovi BOM e whitespace, ricarica.
6. Svuota OPcache e prova nuovamente login/redirect.
7. Configura editor IDE per salvare sempre senza BOM.
8. Aggiungi wp wpem scan-bom come pre-commit hook.
9. Documenta patch BOM applicate a plugin terze parti.

Errori comuni e come risolverli

• Errore in wp-config.php: Apri wp-config.php e verifica che non ci sia output prima di
• Errore intermittente: Plugin di backup o cache che generano output: disattiva uno alla volta per isolare.
• Errore in tema custom: functions.php spesso include file .php senza controllo: usa require_once con path assoluto.
• Scan-bom segnala falsi positivi: Whitelist con WPEM_BOM_WHITELIST per file noti accettabili.
• Patch persa dopo update: Usa Composer + WPackagist e configura patches in composer.json.

Domande frequenti

D: Posso disabilitare la cattura di questo warning?
R: Sì, aggiungi al filtro WPEM_IGNORE_PATTERNS: 'Headers already sent', ma sconsigliamo perchè indica problemi reali.

D: Cosa fa wpem_scan_bom?
R: Comando WP-CLI fornito dall’agent che scansiona tutti i file PHP e segnala BOM/whitespace iniziali.

D: Posso lanciarlo in CI/CD?
R: Sì, l’output è JSON e il comando ritorna exit code != 0 se trova problemi.

D: Quanto è veloce scan-bom su sito grande?
R: Tipicamente 5-30 secondi per 50k file: usa SSD per migliori performance.

D: Posso eseguire scan-bom in cron?
R: Sì, schedula settimanale e ricevi report email.

Hai bisogno di aiuto?

Se vuoi affidare il monitoraggio WordPress al team di G Tech Group, scrivici tramite il modulo di contatto.