Le basi degli hook d’azione in WordPress

Ogni volta che si inizia ad entrare in una programmazione più avanzata, che si tratti di WordPress o di qualsiasi altro framework, libreria, fondamento o linguaggio di programmazione, ci sono momenti in cui i nuovi concetti possono spesso essere più difficili da capire di altri.

In genere ho scoperto che questo è vero ogni volta che una persona ha appreso le basi, ad esempio, della programmazione orientata agli oggetti ma non è stata esposta alle sfumature di alcune cose come i modelli di progettazione.

Caso in questione: ho scritto del modello di progettazione guidato dagli eventi (o del publish-subscribe o Pub/Sub come alcuni amano definirlo) in altri post.

Sì, ci sono alcune differenze in ciascuno di essi, ma l’idea generale è che qualcosa accade e viene generato un evento e qualsiasi cosa che ascolti quell’evento, o sia iscritto a quell’evento, risponderà.

Foto di Claus Grünstäudl su Unsplash

Questo è il modello principale utilizzato da WordPress che ci consente di agganciarci letteralmente a determinati punti di esecuzione. Possiamo generalmente concettualizzare questi come action hook in WordPress.

Ad ogni modo, l’applicazione ci mette a disposizione alcuni punti per aggiungere la nostra funzionalità. Una volta registrata quella funzionalità, WordPress lascerà la sua base di codice, per così dire, salta nella nostra, quindi tornerà alla nostra.

È abbastanza facile da capire, ma cosa succede se si desidera esporre aree nel codice che consentono ad altri di collegarsi al codice?

Action Hook in WordPress

Prima di vedere come WordPress implementa questi modelli, è importante comprendere le basi di questo modello. Sebbene questo non sia affatto completo, ha lo scopo di aiutare a fornire una comprensione di base del modello in modo che sia possibile leggere e scrivere codice incentrato su WordPress.

Allora, qual è un buon modo di pensare al modello Pub/Sub? Wikipedia lo definisce come:

Nell’architettura software, publish–subscribe è un modello di messaggistica in cui i mittenti di messaggi, chiamati editori, non programmano i messaggi da inviare direttamente a destinatari specifici, chiamati abbonati, ma classificano invece i messaggi pubblicati in classi senza sapere quali abbonati, se presenti, ci potrebbe essere. Allo stesso modo, gli abbonati esprimono interesse per una o più classi e ricevono solo messaggi di interesse, senza sapere quali editori, se presenti, ci sono.

Capire il modello

Questo potrebbe essere molto da accettare all’inizio. Non lo so, ma analizziamolo:

1. C’è un servizio, nel nostro caso WordPress, che è responsabile della pubblicazione di messaggi a chiunque si abboni (non sa necessariamente chi sta ascoltando).
2. Quando un abbonato è in ascolto, interverrà ogni volta che sente quell’azione.
3. Al termine dell’esecuzione del codice dell’abbonato, il programma tornerà al punto di esecuzione originale (che è il punto in cui l’editore ha inviato il messaggio).

Ci sono sfumature in questo come la funzionalità asincrona e cose del genere, ma è più avanzato di quanto preferirei ottenere in questo particolare post. Dopotutto, lo scopo è gettare le basi per la comprensione e l’implementazione della funzionalità.

La funzionalità asincrona può entrare nel threading o Ajax e attraverso questi sono argomenti importanti, questo non è quel post.

Com’è questo aspetto in WordPress?

Forse il modo più semplice per descrivere questo particolare modello in WordPress è attraverso l’uso delle chiamate di funzione:

• fare_azione
• aggiungi_azione

A volte, la nomenclatura può essere fonte di confusione, ma in parole povere, do_action pubblica e un evento e aggiungi abbonati a un evento. O forse un modo migliore di pensarci è:

do_action dice a WordPress di eseguire qualsiasi azione sia stata aggiunta.

A volte è utile avere frasi semplici per ricordare come funzionano le cose. Non so se quanto sopra sia la frase più accattivante o più memorabile, ma è qualcosa, giusto?

Inoltre, tieni presente che do_action e add_action sono elementi fondamentali di WordPress e sono disponibili anche per il nostro sviluppo. Prima di andare oltre, diamo un’occhiata a cosa significa ciascuno:

Per fare_azione :

Questa funzione richiama tutte le funzioni associate all’action hook $tag. E’ possibile creare nuovi action hook semplicemente richiamando questa funzione, specificando il nome del nuovo hook tramite il $tagparametro.

O ancora più semplicemente:

Esegui funzioni agganciate a un hook di azione specifico.

Quando si fa riferimento agli hook, possono essere hook definiti da WordPress o hook personalizzati specificati nel tema o nel plug-in.

Per quanto riguarda add_action :

Le azioni sono gli hook che il core di WordPress lancia in punti specifici durante l’esecuzione o quando si verificano eventi specifici. I plugin possono specificare che una o più delle sue funzioni PHP vengono eseguite in questi punti, utilizzando l’API Action.

E, allo stesso modo, più semplicemente:

Aggancia una funzione a un’azione specifica.

L’impostazione pratica è leggermente diversa perché generalmente utilizziamo add_action per aggiungere il nostro codice a WordPress.

Un esempio pratico

Ad esempio, forse hai scritto qualcosa del genere:

<?php
add_action('wp_insert_post_data', __NAMESPACE__. 'processPermalink');
/**
 * Processes the permalink so we can remove any characters that may cause a problem when communicating
 * with the API.
 *
 * @param  array $data The array of information about the post.
 * @return array $data The data without the malformed information in the post name for the URL.
 */
public function processPermalink($data)
{
    if (!in_array($data['post_status'], array('draft', 'pending', 'auto-draft'))) {
        $data['post_name'] =
            preg_replace(
                '/(%ef%b8%8f|™|®|©|™|®|©|™|®|©)/',
                '',
                $data['post_name']
            );
    }
    return $data;
}

In questo caso, da qualche parte nella codebase di WordPress c’è una chiamata do_action per l’ hook wp_insert_post_data e accetta una funzione e le passerà almeno un singolo parametro.

Aggiungere i tuoi ganci

Ma cosa succede se vuoi dare ad altri sviluppatori la possibilità di agganciarsi al tuo plugin o tema? In tal caso, dovresti preoccuparti di usare do_action e la pagina collegata in precedenza in questo documento fornisce tutto ciò di cui hai bisogno per configurarlo.

In realtà è molto più semplice, secondo me, che lavorare con add_action perché add_action prevede che non solo ci colleghiamo a un editore esistente, ma che aggiungiamo la nostra logica personalizzata.

do_action invece richiede di fornire un nome della funzione da eseguire e quindi l’elenco di argomenti da passare alla funzione che verrà eseguita.

Questo è tutto?

Nel modo più semplice possibile, sì. Ci sono alcune sfumature riguardo alla priorità, al numero di argomenti e al lavoro con gli spazi dei nomi e la programmazione orientata agli oggetti. Ma, ancora una volta, questo è al di fuori dello scopo di questo particolare post. Forse ne parlerò più approfonditamente in un altro post.

Per ora, però, se non hai familiarità con le basi di:

• il modello Pub/Sub,
• fare_azione,
• e aggiungi_azione

Ora sei abbastanza a tuo agio da leggere il codice con cui stai lavorando, capire come funziona il codice e persino implementare le tue soluzioni quando necessario.

Attualmente sto scrivendo un eBook (insieme a una varietà di altri contenuti premium). Se sei interessato, controlla cosa ottieni.