Cosa cattura WP Error Monitor: tipi di errore

WP Error Monitor non si limita ai classici 500: cattura un’ampia gamma di eventi PHP e WordPress per darti visibilità completa sullo stato dei tuoi siti. In questa guida elenchiamo tutte le tipologie supportate, con esempi pratici e indicazioni su quando attivare o disattivare la raccolta.

Errori PHP classici

Sono i più frequenti: E_ERROR (fatal), E_PARSE (syntax error), E_WARNING (esecuzione continua), E_NOTICE (variabile non definita) e E_DEPRECATED (funzioni rimosse nelle nuove versioni). Il modulo li intercetta tramite set_error_handler() registrato all’avvio del runtime WordPress, prima del caricamento dei plugin, in modo da catturare anche errori di plugin must-use. Ogni evento viene normalizzato con codice numerico, stringa human-readable, file, riga e severità.

Eccezioni non gestite e fatal shutdown

Tramite set_exception_handler() vengono catturate le Throwable PHP non gestite (Error, TypeError, ValueError, custom exception). Inoltre register_shutdown_function() rileva i fatal di tipo out-of-memory o timeout che chiudono il processo senza dare time-out controllato. Lo stack trace viene serializzato e troncato a 50 frame per evitare payload eccessivi.

Errori WordPress specifici

Vengono intercettati: WP_Error restituiti da API core, errori del file db.php (database connection error), errori cron quando wp-cron.php fallisce, errori REST API con codice 5xx, errori XML-RPC e errori durante l’aggiornamento di plugin/temi/core. Anche le PHP_NOTICE generate da wpdb in query malformate vengono normalizzate.

Eventi infrastrutturali

Oltre agli errori applicativi, l’agent può inviare segnali infrastrutturali: spazio disco basso, memoria RAM sopra soglia, swap attivo, processi php-fpm killati dal OOM killer. Questi eventi richiedono accesso shell e vengono attivati solo per i clienti che sottoscrivono il piano 'Assistenza Sistemi'.

Errori specifici di WooCommerce

Per i siti ecommerce vengono catturate anche le eccezioni di WooCommerce: WC_Data_Exception su salvataggio prodotto, errori di gateway pagamento (Stripe, PayPal), errori durante la creazione ordine, fallimenti di webhook. Questi eventi sono particolarmente critici perché impattano direttamente fatturato. WP Error Monitor li marca con tag 'context=woocommerce' e severità elevata in automatico.

Errori di file system

Vengono catturati anche errori di scrittura/lettura file: permessi insufficienti su wp-content/uploads, disco pieno durante upload, file lock contesi tra processi. Il messaggio include il path e l’operazione tentata (read, write, unlink). Particolarmente utile per identificare problemi di permessi 'fantasma' su hosting condivisi dove il user PHP cambia in base al pool.

Granularità della categorizzazione

Ogni evento catturato viene categorizzato in più dimensioni: tipologia (php_error, exception, fatal, db_error, http_error), severità (NOTICE, WARNING, ERROR, CRITICAL, ALERT), contesto (frontend, admin, ajax, rest, cron, cli), source (core, plugin, theme, custom). Questa granularità permette filtri estremamente specifici: 'tutti i fatal in contesto checkout' o 'tutti gli errori plugin in admin negli ultimi 7 giorni'. La categorizzazione è deterministica (basata su file path e severity PHP) e non richiede ML, quindi è rapida e prevedibile. Per categorie custom, esponi tag aggiuntivi tramite hook wpem_event_tags filter.

Sampling per ridurre volume

Per siti ad altissimo traffico (>10M page view/mese) la cattura di TUTTI gli eventi può generare volume eccessivo. WP Error Monitor offre sampling configurabile: WPEM_SAMPLE_RATE=0.1 cattura solo il 10% degli eventi NOTICE/WARNING, mantenendo 100% degli ERROR/CRITICAL. Così' riduci payload mantenendo coverage sui critici. Il sampling è deterministico (hash su request_id) quindi eventi simili vengono o tutti catturati o tutti scartati: utile per debug. In dashboard una nota indica 'sampled at 10%' così sai che i contatori vanno moltiplicati per la stima reale.

Configurazione e tuning iniziale

La configurazione iniziale di WP Error Monitor per un sito WordPress richiede tipicamente 15-30 minuti: installazione del companion plugin, copia delle costanti in wp-config.php, test di un'evento sintetico per verificare arrivo in dashboard. Dopo il setup, lascia che l’agent osservi per 24-48 ore prima di tunare i filtri: così hai dati reali su cui calibrare WPEM_IGNORE_PATTERNS e le soglie di alert. Tuning fine si fa nel tempo, mentre il team familiarizza con i pattern di errori tipici di quel cliente specifico.

Procedura passo-passo

1. Apri il file wp-config.php del sito monitorato.
2. Verifica che la costante WPEM_CAPTURE_LEVEL sia impostata al livello desiderato (es. E_ALL per dev, E_ERROR|E_WARNING per prod).
3. Attiva o disattiva la cattura delle eccezioni con WPEM_CAPTURE_EXCEPTIONS (default true).
4. Imposta WPEM_CAPTURE_DEPRECATED a false in produzione per ridurre rumore.
5. Riavvia php-fpm o svuota la cache di OPcache per applicare le modifiche.
6. Simula un'errore noto (es. trigger_error) e verifica l’arrivo dell’evento in dashboard entro 60 secondi.
7. Verifica che la libreria companion sia caricata controllando wpem_loaded() in WP-CLI.
8. Su siti WooCommerce, abilita WPEM_CAPTURE_WC_HOOKS=true per maggior dettaglio.

Errori comuni e come risolverli

• Notice troppe in dashboard: Riduci il livello con WPEM_CAPTURE_LEVEL = E_ERROR | E_WARNING | E_PARSE.
• Eccezioni non catturate: Controlla che nessun plugin sovrascriva set_exception_handler() dopo l’avvio dell’agent.
• Mancano errori cron: Il cron WordPress potrebbe essere disabilitato (DISABLE_WP_CRON true): in tal caso usa wp-cron via system cron e abilita WPEM_CAPTURE_CLI.
• Errori filesystem mai catturati: L’agent non ha permessi di lettura su wp-content/uploads: verifica owner e gruppo.
• Errori WC duplicati: Sia WC che WP Error Monitor li catturano: configura WPEM_DEDUP_WC=true.

Domande frequenti

D: Vengono catturati anche errori JavaScript?
R: Sì, tramite snippet opzionale nel footer che invia gli errori al backend. Va attivato esplicitamente nelle impostazioni del sito.

D: Posso escludere un file specifico dalla cattura?
R: Sì, tramite la whitelist WPEM_IGNORE_FILES (array di pattern fnmatch).

D: Quanto pesa l’agent in termini di performance?
R: L’overhead medio rilevato è inferiore al 2% sul TTFB, perchè gli eventi vengono accodati e inviati in background tramite shutdown function.

D: WP Error Monitor supporta multisite?
R: Sì, con attribuzione per blog ID: ogni sito del network appare separato in dashboard.

D: Posso forzare un'evento da codice?
R: Sì, con wpem_capture_event($message, $severity, $context): utile per logging custom.

Hai bisogno di aiuto?

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