Il costruttore è responsabile dell’impostazione di diverse proprietà sul widget, più comunemente il suo nome e la sua descrizione.
La funzione widget è responsabile del rendering del contenuto del widget.
La funzione modulo è responsabile della visualizzazione del modulo nell’area di amministrazione di WordPress quando si lavora con il widget.
La funzione di aggiornamento è responsabile dell’aggiornamento delle opzioni salvate nel database (o inizializzate e quindi del salvataggio delle opzioni che potrebbero non esistere ancora nel database).

La cosa bella è che questo particolare approccio si ottiene ereditando una funzionalità per la classe WP_Widget.

Il problema, però, è che è molto lavoro da fare per una singola classe.

Invece, dovremmo separare ciascuna delle funzioni nella propria area di funzionalità.

Come per qualsiasi cosa nella programmazione, ci saranno modi in cui alcune cose sono chiare su come possono essere fatte e poi ci saranno alcune cose che possono essere fatte in più modi.

Quello che ho intenzione di presentare è come mi sto avvicinando per ora. Questo potrebbe cambiare in futuro, o forse no, e altri potrebbero avere una visione diversa.

Indipendentemente da ciò, l’implementazione sarà molto più orientata agli oggetti e attribuirà a ciascuna classe il proprio insieme di responsabilità.

La prima domanda, tuttavia, è come possiamo dividere una classe con quattro funzioni e che eredita da una classe genitore?

Aggiornamento di Bootstrap

Innanzitutto, ci sono alcune cose che dobbiamo regolare nel bootstrap del plugin. Vale a dire, dobbiamo fare quanto segue:

istanziare il Registro e renderlo disponibile attraverso il progetto,
aggiorna la classe Plugin in modo che accetti un registro e carichi gli abbonati,
rivedere il bootstrap

Ecco uno sguardo a tutti e tre i precedenti.

1 Istanziare il Registro

Dal momento che ne abbiamo già parlato all’inizio della serie, dovrebbe essere chiaro come farlo.

Per prima cosa, vedere il seguente codice :

Successivamente, nota che stiamo creando un’istanza del registro (parleremo momentaneamente del suo spazio dei nomi) e quindi lo colleghiamo a un filtro personalizzato che ci consente di accedervi in tutto il plug-in ogni volta che lo desideriamo.

2 Aggiorna la classe del plugin

Successivamente, dobbiamo aggiornare la classe del plugin principale (che risiede nella directory src) in modo che faccia riferimento al registro e carichi tutti gli abbonati registrati :

Nota, tuttavia, che non abbiamo ancora impostato alcun abbonato. L’abbiamo iniziato all’inizio della serie e ora è il momento di tornare su di esso, ma lo faremo più tardi.

Tuttavia, è necessario aggiungere una funzione, anche se temporanea, in modo da poter aggiungere classi che non siano sottoscrittori di eventi espliciti:

Questo verrà rielaborato in seguito poiché trasformeremo le classi principali in abbonati in seguito.

3 Esamina Bootstrap

Prima di andare oltre, penso che sia importante rivedere il bootstrap. Sebbene l’intestazione e la documentazione possano variare, è importante notare che stiamo effettuando le seguenti operazioni:

namespace il bootstrap,
impedire l’accesso al file,
chiamando il caricatore automatico,
impostare il registro,
e avviare il plugin.

Sembra molto ma il codice è piuttosto breve :

A questo punto, però, è il momento di guardare a com’è dividere la classe figlia dall’API Widgets standard in qualcosa che si adatta al modello di codice con cui stiamo lavorando.

Dividere una classe bambino

È probabile che questa parte si estenda su alcuni post poiché c’è un po’ di lavoro da fare, ma inizieremo creando la nostra classe widget che erediterà dalla classe Widget di base.

Per prima cosa, vai avanti e crea una directory API nella directory src e aggiungi un file chiamato Widget.php. È qui che risiederanno le basi del widget. Nel prossimo post parleremo dei fogli di stile pubblici e amministrativi e dei file JavaScript.

A questo punto, le basi del file dovrebbero apparire così :

Si noti che richiede un singolo argomento. Ho usato widget-name ma puoi usare qualunque cosa desideri purché rappresenti il tuo widget.

Questo per mostrare che la classe viene istanziata e caricata correttamente quando il plugin viene attivato. Se non vedi questo, allora qualcosa non va (che esamineremo momentaneamente).

Successivamente, è importante assicurarsi che questa classe venga aggiunta al Registro di sistema. Quindi aggiungi le seguenti righe di codice nel bootstrap:

E ora, quando attivi il plugin, dovresti vedere quanto segue:

In caso contrario, assicurati di rivedere il codice nel ramo di sviluppo per assicurarti di avere tutto ciò che è descritto in questo post.

Abbonati implementanti

Nei prossimi post, vedremo come implementare gli abbonati per il lato pubblico del sito (ovvero, dove viene visualizzato il contenuto del widget). E faremo lo stesso per l’area di amministrazione del sito.

Infine, rivolgeremo la nostra attenzione al codice responsabile della protezione e della serializzazione dei dati (leggi: aggiornamento del nostro widget) e quindi vedremo come appare la versione finale di un boilerplate aggiornato.

In questo post, tuttavia, la strategia principale che stiamo impiegando è suddividere una classe figlia in modo che possa ancora essere utilizzata con altre classi utilizzando interfacce e classi base che sono già definite nella base di codice.

Fonte di registrazione: tommcfarlin.com