Se ti avvicini molto allo sviluppo di plugin di WordPress da una prospettiva orientata agli oggetti, alla fine arriverai a un punto in cui non stai facendo molta interazione direttamente con il core di WordPress stesso.
E, nella mia mente, è una buona cosa. È un segno di un’architettura che stai strutturando correttamente il tuo codice. Questo è:
- Hai WordPress seduto al livello di base,
- Hai una serie di classi che si trovano appena sopra WordPress responsabili dell’invio di informazioni da e verso WordPress tra il plug-in,
- E hai il resto del tuo codice che comprende il resto delle funzionalità.
Il modo in cui viene implementato può variare, ma il modo in cui lo immagino è lo stesso in cui tendo a pensare all’applicazione standard di livello N in cui hai il livello dati, il livello applicazione e il front-end.
Fatta eccezione per questa volta, hai WordPress, un livello per comunicare con WordPress e il resto del tuo codice e, sai, il resto del tuo codice.
Come può essere organizzato un plugin.
Quindi cosa succede quando si desidera interrompere l’esecuzione del plug-in quando deve interagire con una dipendenza di terze parti e dovrebbe essere eseguito solo se tale dipendenza è presente?
Interrompi l’esecuzione del plug-in
A causa della natura di PHP e WordPress, ci sono alcuni modi in cui questo può essere fatto. Il codice che ho intenzione di condividere non prescrive il modo per farlo.
Invece, questo è un modo per farlo (che è stato estratto da qualcosa che è in fase di sviluppo). Inoltre, mostrerò come interagisce anche con alcuni altri componenti dei plugin.
1 Il costruttore
Se leggi abbastanza articoli su WordPress e sulla programmazione orientata agli oggetti, probabilmente scoprirai che i costruttori non dovrebbero essere usati per definire gli hook. E sono d’accordo.
Crea un livello di accoppiamento non necessario e rende più difficili le prove. Qual è, allora, lo scopo di un costruttore nel codice basato su WordPress?
Lo uso per gli stessi motivi che ti aspetteresti in qualsiasi altro linguaggio: per inizializzare le proprietà della classe. Nel codice qui sotto, vedrai tre cose:
- inizializzo una proprietà,
- Controllo per vedere se esiste una dipendenza di terze parti,
- In caso contrario, aggiungo un messaggio di errore,
- Aggiornerò la proprietà.
Certo, è dettagliato, ma non ricorre nemmeno a codice intelligente per inizializzare i valori.
(Più sono invecchiato, più mi sono affezionato al codice specifico in quanto rende più facile leggere, raccogliere e andare avanti a una velocità maggiore rispetto all’alternativa.)
2 Il metodo di inizializzazione
Dal momento che non stiamo usando un costruttore per lavorare con gli hook di WordPress, questa funzionalità dovrebbe esistere nel contesto di un altro metodo.
Questo ci dà un posto dedicato per inserire questo tipo di funzionalità, disaccoppiarlo dal resto della classe e farlo interagire con WordPress solo quando il metodo viene invocato esplicitamente.
Ma ricorda, l’intero punto di ciò a cui sto arrivando ha a che fare con l’arresto dell’esecuzione di un plug-in, non con dove posizionare gli hook.
Quindi diciamo che la dipendenza di terze parti non esiste, e allora? Ricordiamo nel costruttore, è stata impostata una proprietà che ci consentirà di determinare se dobbiamo andare avanti con l’impostazione degli hook o meno:
E quando è a posto, il resto del codice non verrà eseguito.
Molte parole, un piccolo codice
Sembra un sacco di spiegazione per così poco codice.
Ma una parte di questo serve anche a cercare di trasmettere il significato di avere parti di un progetto basato su WordPress separate dal resto del core in modo che le parti possano interagire con se stesse senza dover parlare esplicitamente con il core tutto il tempo.