Heartbeat Manager v1.0.3

Documentazione Tecnica e Utente Ufficiale

Progettato e ottimizzato per configurazioni server ad alte prestazioni, alleggerimento del database ed efficienza del pannello di amministrazione.

1. Panoramica e Scopo

L'API Heartbeat di WordPress utilizza richieste AJAX continue e periodiche tramite il file admin-ajax.php per gestire attività quali il salvataggio automatico delle bozze, il blocco dei post durante la modifica multi-autore e il recupero in tempo reale delle notifiche della bacheca. Sebbene utili, queste attività avviano pesanti cicli di elaborazione lato server ogni 15-60 secondi.

Su siti web ad alto traffico, blog multi-autore o installazioni WooCommerce su larga scala, queste esecuzioni in background possono saturare la capacità della CPU del server, causando un aumento dei tempi di risposta della pagina o arresti anomali temporanei. Heartbeat Manager risolve questo collo di bottiglia sistemico offrendo un controllo completo sulle frequenze di esecuzione in aree specifiche del sito.

2. Impostazioni e Configurazione del Plugin

Una volta installato, naviga su Impostazioni > Heartbeat Manager. Troverai tre opzioni di configurazione principali:

Frequenza del Backend (Bacheca Amministrativa): Controlla l'intervallo dell'heartbeat durante la navigazione nelle pagine di amministrazione generali (Bacheca, Libreria Media, Plugin, ecc.).
- Intervallo: Da 30 a 300 secondi.
- Consigliato: 60 o 120 secondi per un alleggerimento ottimale del server.
Frequenza dell'Editor di Post/Pagine: Controlla l'intervallo specificamente all'interno dell'editor a blocchi Gutenberg, del Classic Editor o delle schermate di modifica dei prodotti WooCommerce. Gestisce attività critiche come i salvataggi automatici e il blocco dei post.
- Intervallo: Da 30 a 300 secondi.
- Consigliato: 30 o 60 secondi per preservare i backup automatici riducendo al contempo il carico del server.
Frequenza del Frontend: Gestisce l'API Heartbeat sulla parte pubblica (visibile agli utenti) del tuo sito web.
- Opzioni: Disabilitato (0), 60 secondi o 120 secondi.
- Consigliato: Disabilitato per la maggior parte dei siti vetrina e dei negozi e-commerce standard.

3. Test e Verifica (Vademecum)

1. Test del Backend e dell'Editor

Apri gli Strumenti per Sviluppatori del browser (F12), passa alla scheda Rete (Network) e filtra per admin-ajax. Se ti trovi nella Bacheca amministrativa generale, le richieste partiranno in base alla Frequenza del Backend impostata. Se apri una schermata di modifica di un articolo o di una pagina, le richieste passeranno dinamicamente alla tua Frequenza dell'Editor di Post/Pagine (es. ogni 30 o 60 secondi).

2. Verifica del Frontend

Visita il tuo sito pubblico. Se il Frontend è impostato su "Disabilitato", non dovresti vedere assolutamente alcuna chiamata a admin-ajax.php originata dallo script Heartbeat, a dimostrazione che gli accessi in background sono stati completamente interrotti.

3. Ispezione della Console

Apri la scheda Console (F12) sul tuo sito pubblico e digita wp.heartbeat.interval() o lnhm_frontend_settings. Nota: Se ricevi un errore di tipo Uncaught ReferenceError o undefined, è del tutto normale e previsto! Significa che WordPress non ha caricato lo script Heartbeat nel frontend poiché nessun componente attivo lo richiede, garantendo che le tue pagine pubbliche siano già naturalmente ottimizzate.

4. Domande Frequenti (FAQ)

La disattivazione dell'Heartbeat nel Frontend comprometterà le funzionalità del mio negozio?

No. Per i siti vetrina standard o i portfolio, la disattivazione dell'heartbeat nel frontend non ha alcun impatto negativo. Tuttavia, se utilizzi componenti esterni specifici come sistemi di messaggistica live in tempo reale, contatori dinamici o aggiornamenti immediati delle scorte di magazzino, è fortemente consigliabile impostare un intervallo di 60 o 120 secondi piuttosto che la disattivazione completa.

In che modo questo plugin migliora le metriche prestazionali del mio sito?

Dilatando o spegnendo del tutto le richieste ridondanti del server, ridurrai drasticamente il sovraccarico di esecuzioni in background che colpiscono il file admin-ajax.php, liberando immense risorse della CPU. Il metodo utilizzato preserva la stabilità dei plugin dipendenti (come WooCommerce).

Perché ricevo un errore "Uncaught ReferenceError" o "undefined" quando eseguo il test nel frontend?

Questo è un ottimo segno! WordPress non carica lo script Heartbeat sul frontend per impostazione predefinita. Se visualizzi questo errore, significa che né il tuo tema né i tuoi plugin attivi stanno eseguendo cicli AJAX in background sulle tue pagine pubbliche, lasciando il tuo frontend totalmente ottimizzato.

Un intervallo più alto nell'Editor influenzerà il mio Page Builder o i Salvataggi Automatici?

Impostare l'intervallo dell'Editor sul valore massimo (es. 300 secondi) significa che i backup automatici del layout verranno attivati solo ogni 5 minutes. Se stai creando attivamente pagine con Elementor, Divi o Gutenberg, ti consigliamo vivamente di mantenere questa impostazione specifica a 30 o 60 secondi, per bilanciare il risparmio di risorse del server con la sicurezza dei contenuti in caso di chiusura improvvisa del browser.

5. Note Tecniche per gli Sviluppatori

Principali Hook Utilizzati

add_filter( 'heartbeat_settings', ... ): Utilizzato per modificare dinamicamente l'intervallo tra la bacheca di amministrazione e la schermata dell'editor.
add_action( 'wp_enqueue_scripts', ... ): Utilizzato per annullare la registrazione o modificare in modo sicuro gli script pubblici per intercettare le richieste del frontend.

6. Registro delle Modifiche (Changelog)

Versione 1.0.3

Correzione: Aggiornato il Punto 1 del Vademecum nella documentazione per evitare confusione durante i test di rete tra gli intervalli di Amministrazione ed Editor.
Documentazione: Aggiunta una FAQ tecnica relativa all'impatto degli intervalli alti sui Page Builder (Elementor, Divi) e sui salvataggi automatici (autosave).

Versione 1.0.2

Perfezionamento: Innalzato l'intervallo minimo per il Backend e l'Editor a 30 secondi per prevenire interrogazioni troppo aggressive sul server.
Documentazione: Ottimizzate le guide di test integrate per chiarire il comportamento nativo degli script nel frontend.

Versione 1.0.1

Sicurezza: Implementate rigide procedure di escaping (esc_attr, esc_html) e sanificazione dei dati (intval).
i18n: Infrastruttura completamente internazionalizzata e pronta per la traduzione.
Primo rilascio pubblico stabile.