Alla scoperta degli Hook di inizializzazione

Proprio come qualsiasi applicazione, anche la nostra WordPress ha la necessità di lanciare diversi processi e di fare in modo che questi si susseguono in un ordine ben preciso perché, se così non fosse, ci troveremmo di fronte a problemi di esecuzione.

Proprio come una macchina, che ha bisogno di carburante inviato ai cilindri grazie ad un carburatore che risponde agli stimoli dell’acceleratore, anche la nostra piattaforma preferita deve seguire un ritmo ben preciso per funzionare correttamente.

In questo articolo andremo ad analizzare da vicino quali Hook potrai utilizzare per gestire questa sequenza e come fare per inserire il tuo codice al loro interno.

Oltre a questo andremo anche a vedere quali sono i più comuni errori evitandoti di commetterli di prima mano o aiutarti nella risoluzione del problema scatenato.

Se non ti è ben chiaro il termine Hook ti consiglio di leggere un articolo che abbiamo precedentemente pubblicato e che ti sarà sicuramente utile per comprendere meglio i concetti presentati qua sotto.

Se stai continuando a leggere, presumo che tu conosca bene gli Hook WordPress e che li abbia già usati diverse volte per la creazione di temi e plugin. Quindi, mettiamo da parte tutti i preamboli e le parole di avvertimento ed entriamo subito nel vivo della questione.

Perché tanto interesse per gli Hook di inizializzazione?

Se hai già sviluppato diversi plugin ti sarà capitato di combattere con questi tipi di Hook ma per gli scopi formativi di questo sito desidero fare una breve introduzione.

Gli Hook di WordPress che vengono utilizzati in fase di inizializzazione (init) di tutta la piattaforma permettono di agganciarsi a punti ben precisi, per andare ad eseguire il proprio codice.

Data la loro importanza, ne sono stati creati diversi tipi:

• init – viene eseguito successivamente al caricamento di WordPress ma prima che qualsiasi header sia inviato, tendenzialmente viene utilizzato nei processi di inizializzazione dei propri plugin;
• widgets_init – usato per registrare le widget della nostra applicazione, non è quindi un caso se ti sarai trovato molto spesso ad utilizzare la funzione register_sidebar collegata a questa azione;
• admin_init – questo viene eseguito quando un utente accede alla parte amministrativa di WordPress ed è la prima azione ad essere eseguita. Generalmente si utilizza per inizializzare le opzioni ed i settaggi della admin area stessa.

Come puoi notare dalla descrizione, la stessa piattaforma lancia ciascun hook in momenti diversi del caricamento ed è per questo motivo che per migliorare le conoscenze WordPress ti consiglio di fare qualche esperimento.

Cerchiamo di capirci meglio

Anche se le definizioni sembrano abbastanza chiare voglio fare un paio di esempi che ci aiutano a chiarire la situazione.

Diciamo che voglio vedere come si comporta admin_init se lo inseriamo all’interno del lancio di init e viceversa. Entrambi i casi funzioneranno correttamente o si presenterà qualche problema?

Andiamo a scoprirlo insieme:

//Funzione richiamata da add_action(admin_init) 
function sam_admin_init() { 
  echo "Io sono admin_init eseguito da init"; 
} 

//Funzione richiamata da add_action(init) 
function sam_init(){ 
  add_action( 'admin_init', 'sam_admin_init' ); 
} 

add_action( 'init', 'sam_init' );

Quello che stiamo provando è testare con mano l’effettiva esecuzione dei correnti Hook.

Sappiamo che, sulla carta, init viene eseguito prima di admin_init e per avere una prova ulteriore facciamo in modo che la funzione sam_admin_init() venga richiamata soltanto all’interno della funzione sam_init(), in questo modo ci stiamo assicurando che sia stato utilizzata l’azione init prima ancora di eseguire qualsiasi codice.

Se hai provato questo codice e lo hai testato sulla tua piattaforma di test ti sarai accorto che tutto funziona correttamente.

Il messaggio “Io sono admin_init eseguito da init” è presente all’interno delle pagine di amministrazione e questo conferma che admin_init viene eseguito dopo init.

Andiamo adesso a vedere se è vero anche il contrario…

//Funzione richiamata da add_action(init) 
function sam_admin_init() { 
  echo "Io sono init eseguito da admin_init"; 
} 

//Funzione richiamata da add_action(admin_init) 
function sam_init() { 
  add_action( 'init', 'sam_admin_init' ); 
} 

add_action( 'admin_init', 'wpam_init' );

Anche in questo caso i commenti ci mostrano che cosa sta succedendo.

Il codice è molto simile a quello precedente ma se noti abbiamo invertito le posizioni delle azioni; adesso è admin_init a richiamare il codice che dovrà essere agganciato durante il classico init di WordPress.

Se hai provato questo codice, ti sarai accorto che questa volta il messaggio “Io sono init eseguito da admin_init” non è presente…

Questo ci dà conferma della teoria perché, come c’era da aspettarci, un Hook init viene eseguito prima di uno admin_init e quando andiamo a richiamare il codice contenuto nella funzione wpam_init() l’azione init non è disponibile.

Con questo primo esempio spero di averti fatto capire l’importanza che questi Hook hanno all’interno dello sviluppo WordPress ma, se così non fosse, spero che con le prossime spiegazioni la situazione si possa migliorare.

Alla Scoperta di init e admin_init

Precedentemente ti ho parlato di questi due Hook e abbiamo detto che moltissimi sviluppatori di plugin li utilizzano per eseguire il proprio codice.

Anche se esistono altri Hook che prendono ispirazione da questi, questi due sono i più gettonati e, una volta che li conoscerai da vicino, molto probabilmente anch’essi entreranno nelle tue grazie.

Proprio per conoscerli da vicino, andiamo ancora più nel dettaglio e cerchiamo di capire quando questi Hook vengono richiamati da WordPress.

init oltre ad essere la prima azione di inizializzazione questo hook viene richiamato per qualsiasi pagina, sia lato frontend che backend.

admin_init, molto simile al precedente, ma con la caratteristica di essere richiamato soltanto nella parte amministrativa del sito, questo significa che l’utente dovrà essere loggato per vederne i risultati.

Dato che entrambi gli Hook vengono richiamati ad ogni richiesta che viene fatta al sito, ti suggerisco di riflettere bene su che cosa andrai ad eseguire perché questo andrà a colpire le prestazioni della tua piattaforma.

Come usare init

Abbiamo visto che questo Hook viene richiamato ad ogni richiesta ed ho cercato di farti riflettere su che cosa sarebbe meglio eseguire in questo contesto e cosa no.

Per facilitarti il compito ho deciso di fornirti qualche suggerimento su quali siano le migliori pratiche di utilizzo, guardiamo intanto i primi su init:

• registra Custom Post Type – questo è un suggerimento che proviene dalla stessa WordPress;
• inizializza le configurazioni e opzioni del tuo plugin – questi dati sono necessari per il corretto funzionamento del plugin dato che, se attivo, anch’esso verra eseguito ad ogni richiesta;
• aggiungere regole di rewrite – se abbiamo bisogno di generare le nostre URL non c’è posto migliore se non l’azione `init`, in questo caso le regole verranno applicate soltanto quando verranno svuotate le precedenti;
• caricare il file di traduzione – dato che WordPress permette di essere tradotto in varie lingue è bene specificarle il prima possibile.

Quindi con init possiamo aggancarci ad un sistema che permette di applicare le modifiche a qualsiasi richiesta del sito, molte di quelle che abbiamo visto, se trascurate, potrebbero anche comprometterne il corretto funzionamento.

Come ad esempio quando non viene richiamato il giusto file di traduzione o non sono presenti le impostazione per il tuo plugin…

Con admin_init il discorso si fa leggermente differente, vogliamo richiamare il nostro codice in tutte le richieste rivolte alla bacheca ma ci sono comunque alcune buone pratiche che mi sento di condividere:

• controlla gli accessi – questo hook è il primo che viene eseguito durante una richiesta nella bacheca di amministrazione, data questa peculiarità, è bene agganciarci a questo per controllare che l’utente che sta chiedendo di fare una modifica abbia effettivamente i permessi per farla;
• aggiunta di pagine opzioni – se il tuo plugin ha bisogno di alcune opzioni, questo hook può essere usato per creare pagine opzioni dedicate oppure sfruttare alcune di quelle già presenti, ma esistono soluzioni migliori.

Occhio agli errori!

Abbiamo visto alcuni consigli su quali tipi di azioni sviluppare, e benché queste siano soltanto una minima parte di quelle applicabili, credo proprio che una carrellata sugli errori da evitare:

• generare la riscrittura delle URL – questa è una delle azioni più complesse che possiamo chiedere di fare a WordPress. Andare a fare operazioni così onerose in fase di inizializzazione è una cosa che andrà a colpire negativamente le prestazioni del tuo sito, sopratutto se ti appoggi a init. Per risolvere questo problema potresti aggiungere un bottone o la possibilità di programmare questa azione, in questo modo non verranno generate ad ogni richiesta ma soltanto quando desiderato;
• accedere al database – questa sembra una cosa veramente naturale, in fin dei conti già WordPress stesso si appoggia al database ad ogni richiesta, perché non farlo anche noi? Può anche sembrare una domanda corretta e più che logica, ma non è assolutamente performante. Il codice che viene aggiunto deve essere eseguito in altre porzioni del processo diverse dalla fase di inizializzazione, altrimenti ci stiamo complicando soltanto la vita;
• usare init al posto degli Hook specifici – questo è uno degli errori più comuni. Ad esempio, prima ti ho detto che admin_init può essere utilizzato per creare pagine opzioni e voci di menu o, in aggiunta, potrebbere essere utilizzato per richiamare file JavaScript che ti servono appositamente per la parte amministrativa del sito.
  Ecco che, in questo contesto, Hook più specifici possono aiutarci meglio a definire quando eseguire il proprio codice:   
  • admin_menu – grazie a questo hook verremo posizionati nel momento preciso in cui WordPress va a creare le pagine opzioni, molto utili quindi per andare a creare quelle del proprio plugin;
  • wp_enqueue_scripts – anche per il caricamento dei file JavaScript WordPress segue una procedura specifica ed è per questo che, utilizzando questa azione, potremmo intrufolarci in questo momento e caricare i nostri file, rispettando al tempo stesso la gerarchia in WordPress ed evitando inutili problemi già discussi.

Questi sono soltanto alcuni dei più comuni errori che si possono fare quando si sviluppa per le prime (e successive) volte con WordPress, è impossibile andare a coprirle tutte ma spero che adesso sia chiara l’importanza di usare i corretti Hook, sopratutto se abbiamo a cuore le prestazioni del sito che stiamo sviluppando.

Conclusioni

Con questa semplice articolo spero di averti aiutato ad approfondire le tue conoscenze della piattaforma WordPress perché, come avrai notato, sono moltissimi i piccoli errori che possiamo fare.

Saper programmare con una piattaforma come WordPress non significa soltanto sapere quali funzioni e caratteristiche ci vengono messe a disposizione ma significa anche sapere quando usarle.

Sbagliare l’esecuzione del proprio codice si può tradurre facilmente in diversi secondi di rallentamento e come è stato dimostrato più volte, questi rallentamenti non colpiscono soltanto il posizionamento sui risultati di ricerca ma fanno perdere denaro.