Hacking di WordPress per developer: guida passo-passo

Argomenti trattati:
Pubblicato il: 9 Dicembre 2020

Vi siete mai chiesti cosa succeda “dietro le quinte” ogni volta che si apre la pagina di un sito in WP? Le operazioni eseguite dal server in background sono moltissime, ed il livello di complessità raggiunto dal core passa per chiamate a funzioni sempre più complesse ed “intrecciate” tra loro, rendendo obiettivamente difficile la comprensione di tutti i dettagli. La cosa essenziale è che il core funziona, è arrivato da oggi alla versione 5.6 ed è sempre più veloce e sicuro, ricco di funzionalità che vengono via via aggiunte e che, il più delle volte, secondo me gli sviluppatori non sfruttano nemmeno al 100%.

Leggi anche: come usare le RESTful API di WordPress

Parliamo quindi della fase di startup di WordPress, che viene eseguita ciclicamente ogni volta che aggiorniamo una qualsiasi pagina di WP. Questo meccanismo è anche alla base della sua profonda versatilità, grazie a variabili di sessione e di ambiente (per così dire) attea garantire la resa perfetta di qualsiasi tipo di pagine. Quando parliamo di tipo di pagina intendiamo:

  • la home page;
  • le pagine del sito;
  • gli articoli del sito;
  • le pagine dei media (immagini e video);
  • le categorie, i tag;
  • i tipi di tassonomia e post personalizzati, se abilitati da qualche plugin.

Qualcuno potrebbe anche chiedersi a cosa possa servire sapere qualcosa sull’argomento: il punto è che, di fatto, l’avvio di WordPress può influire sui tempi di rendering delle pagine HTML, influenzando ad esempio il TTFB (Time-To First Byte), cioè l’attesa tra la prima richiesta del client e l’inizio dell’invio del markup HTML.

Il blog theme.fm in proposito aveva fatto un lavoro molto dettagliato sui cosiddetti WordPress internals, è stato l’unico a farlo da questa particolare angolazione, ed è ai due post di Gennady Kovshenin che mi sono ispirato per spiegare questo complicato ed affascinante processo.

Se avrete la pazienza di seguirmi, infatti, sarà interessante scoprire alcuni aspetti “segreti” di WordPress, specie nel caso in cui vogliate ottimizzare l’overhead iniziale, cioè ridurre il tempo di caricamento delle pagine (quello che precede ogni altra operazione), evidente quando testate il vostro sito con strumenti come tools.pingdom.com.

Per la cronaca: è opinione diffusa sui vari forum per sviluppatori che molte cose non siano per nulla chiare o non troppo documentate, rendendo difficile – tanto per fare un esempio – mettere mano a WordPress lato back-end o back-office amministrativo. Quando descritto di seguito è soggetto a possibili errori o modifiche nel frattempo, per cui è sconsigliato di testare queste funzioni su server che non siano di sviluppo.

La fase di startup di WordPress: index.php

Se apriamo una qualsiasi pagina di WordPress, tutto parte dal file index.php, il file che avvia il processo di preparazione per il caricamento di una pagina qualsiasi: come forse già saprete, la chiamata può essere secca (home page) oppure contenere dei parametri di pagina (index.php?p=123) oppure di post o altri contenuti (quelli che abbiamo elencato: pagine, post, tassonomie ecc.). Cosa troviamo dentro questo file? In realtà quasi nulla: semplicemente delle include dinamiche ad altri file.

Inizialmente WordPress, nel momento in cui riceve la richiesta di una chiamata, include il file wp-blog-header.php: questo dovrebbe essere familiare a chiunque abbia provato a fare delle chiamate a WP in modalità asincrona, per accedere ai dati del database di WP “al volo”, fuori dal contesto di WP, mediante una funzione asincrona (le chiamate Ajax in Javascript).

Il frammento di codice in esame dovrebbe essere già familiare agli sviluppatori, ed è il seguente:

/* Loads the WordPress Environment and Template */
require('./wp-blog-header.php'); 

Se avete avuto necessità di richiamare funzioni WP in modo asincrono, fuori dal contesto globale di WP, questo è – per inciso – il frammento di codice utile al caso, che dovrebbe precedere qualsiasi altra istruzione. Qui dentro potete forzare qualsiasi istruzione specie in fase di debug o di siti che hanno smesso di funzionare, ma in genere le modifiche che fate qui saranno sovrascritte al successivo aggiornamento di WP.

Nota: non è una buona norma modificare i file del core, ma a scopo sperimentativo potrete farlo in locale su siti in sviluppo non pubblici.

La fase di SHORTINIT

Si passa, dopo aver incluso i contenuti del file wp-config.php (che ho descritto sul sito qui e qui) al cosiddetto SHORTINIT, che è un insieme iniziale di chiamate e definizioni di funzioni, file di traduzione, helpers, wrapper, editor TinyMCE, regex, chiamate di sistema ed un’ulteriore infinità di dettagli troppo complessi da riassumere in un post. In breve, questa fase carica le API essenziali di WordPress, in modo da permettere un coding essenziale o, se preferite, di sfruttare WP come framework.

C’è da dire, come notato nei commenti al post originale, che i plugin che abusano un po’ dell’overhead iniziale si innestano senza complimenti nello SHORTINIT, e – nonostante le mie speranze favorevoli – non c’è un modo per individuare tutti i plugin critici sotto questo punto di vista (il sito plugins.svn.wordpress.org non sembra indicizzato a dovere su Google).

È un dato di fatto, comunque, che se usate parecchi plugin per WordPress ci sia una buona probabilità che tendano a rallentare la fase di pre-avvio delle vostre pagine (ed un modo banale per provarlo esiste: basta misurare i tempi di caricamento della pagina con tutti i plugin attivi e subito dopo averli disattivati).

WPEngineer nota, a questo punto, che esiste pure una variabile SHORTINIT, che spezza il flusso di codice a questo punto e permette, quindi, di risparmiarsi l’overhead di chiamate inutili. Si attiva così, nel wp-config.php:

define( ‘SHORTINIT’, TRUE );

ma attenzione: a parte che imposterà a null le variabili globali $wp e compagnia, questo approccio va bene per funzioni AJAX che usino WordPress (quindi vostre API, ad esempio), per l’uso ordinario di WP non vanno, ovviamente, bene.

Per il resto c’è poco su cui poter mettere mano, anche perchè si tratta di chiamate piuttosto complesse che, peraltro, hanno quasi certamente subìto parecchie modifiche ed ottimizzazioni con gli ultimi aggiornamenti.

Cenni all’ uso degli hook

Per intervenire nei processi di WP su una pagina specifica, in genere è opportuno fare uso degli hook: ne esistono unquantità incredibile, e permettono di intervenire sul sito a livello di eventi. Cosa vuol dire? Che non vale lottica classica di programmazione procedurale, ma che gli eventi sono scatenati dalla pagina che stiamo aprendo, dal filtro che stiamo applicando e così via.

Gli hook sono in genere filtri che si possono attivare all’occorrenza, sapendo quali utilizzare. Un esempio facile da capire è quello che permette di aggiungere le ads a qualsiasi nostro articolo, quello che fanno in automatico i plugin di ads, insomma. Il modello di codice è su questa falsariga:

add_filter( 'the_content', 'trovalost_content_filter' );
function trovalost_content_filter( $content ) {
    if ( in_category('blog') )
        $ads = "Clicca qui (ads)";
    return $ads . $content;
}

ovvero una funzione richiamata mediante add_filter (funzione standard di WP) usando il nome della funzione personalizzata come secondo parametro in formato stringa. Quel codice aggiunge semplicemente la stringa di prova “Clicca qui (ads)” se il post corrente appartiene alla categoria “blog”.

Possono essere anche action, cioè azioni che si attivano in casi molto specifici. Gli hook possono, infine, essere hook, ovvero azioni associate sia all’uno che all’altro caso appena visti.

Il caricamento di WordPress continua

Passiamo quindi alla definizione delle funzionalità di core vere e proprie, quindi Main API, Error API, Plugin API, Object Cache e tutto quando definisce un’istanza di WP vera propria, sia essa ordinaria o estesa mediante framework. In questo processo, beninteso, la mia sintesi estrema deriva ancora una volta da un mix di oggettiva difficoltà nel separare le varie operazioni “atomiche” ed elencarle ordinatamente.

Quello che succede è presto detto: si caricano i file di internazionalizzazione, i walker per i menù, i vari hook e le funzioni per utenti, query, theme e parecchi template. Dopo è la volta di widget, altre classi helper, le informazioni aggiornate su data ed ora del server e qualche altra cosa su cui, di norma, non è ordinario nè consigliabile intervenire. La descrizione del processo, poi, non finirebbe neanche qui: quanto visto finora interessa solo i file wp-setting.php e wp-config.php, il wp-blog-header.php non è ancora terminato poichè dovrà, a seconda dei casi, richiamare il template backend oppure frontend.

Photo by alexbrn

Nessun voto disponibile

Che te ne pare?

Grazie per aver letto Hacking di WordPress per developer: guida passo-passo di Salvatore Capolupo su Trovalost.it
Hacking di WordPress per developer: guida passo-passo (Guide, Guide per la configurazione di WordPress)

Articoli più letti su questi argomenti: