Share
Quando si tratta di scrivere plugin per WordPress, ci sono in genere due modi per farlo: la programmazione orientata agli oggetti e la programmazione funzionale (con i widget che fanno eccezione) lo tratteremo più avanti nell'articolo).
Sebbene in genere le persone garantiscano uno stile di programmazione rispetto all'altro, ognuno presenta il proprio insieme di vantaggi e svantaggi.
In questa serie in due parti, Stephen Harris e io analizzeremo i due modi in cui puoi scrivere plugin WordPress. Nello specifico, parlerò della programmazione orientata agli oggetti e parlerà della programmazione funzionale.
Poiché il livello di esperienza dei lettori varia, parleremo di programmazione ad alto livello, quindi se sei un principiante, non dovresti avere problemi a seguirlo. Se, tuttavia, sei uno sviluppatore più esperto, puoi trovare più informazioni utili più avanti nell'articolo.
Detto questo, iniziamo a considerare un approccio orientato agli oggetti allo sviluppo di plugin per WordPress.
Come accennato nell'introduzione, i plugin possono essere sviluppati per WordPress in due modi:
Il secondo articolo della serie riguarderà la programmazione funzionale, ma forniamo una definizione operativa della programmazione orientata agli oggetti in modo che siamo tutti sullo stesso livello in questo articolo.
Wikipedia afferma:
La programmazione orientata agli oggetti (OOP) è un paradigma di programmazione che utilizza "oggetti" - di solito istanze di una classe - costituiti da campi e metodi di dati insieme alle loro interazioni - per progettare applicazioni e programmi per computer.
Quelli che hanno più esperienza con la programmazione di computer, particolarmente coloro che usano tecniche di programmazione orientate agli oggetti, probabilmente apprezzeranno questa definizione.
Ma cerchiamo di semplificarlo per gli scopi di questo articolo:
La programmazione orientata agli oggetti è una tecnica di programmazione che utilizza una raccolta di metodi correlati per definire un programma per computer o parte di un programma per computer.
Abbastanza semplice, giusto? Nel nostro caso, i nostri plugin sono sicuramente parte di un programma per computer da quando si stanno collegando a WordPress.
Anche se guarderemo al codice nel resto di questo articolo, notiamo che i programmi orientati agli oggetti sono identificati dal raggruppamento dei loro metodi correlati e quello è fatto nel contesto di ciò che è chiamato una classe - che copriremo momentaneamente.
Anche se è vero che i plugin di WordPress possono essere sviluppati usando OOP o la programmazione funzionale, c'è un'eccezione quando si tratta di sviluppare widget.
Secondo l'articolo del Codex sullo sviluppo di widget, la seguente struttura deve essere utilizzata per scrivere un widget:
class My_Widget estende WP_Widget public function __construct () // widget actual processes public function form ($ istanza) // restituisce il modulo delle opzioni su admin aggiornamento della funzione pubblica ($ new_instance, $ old_instance) // elabora le opzioni del widget da salvare widget di funzioni pubbliche ($ args, $ istanza) // restituisce il contenuto del widget
Ciò significa che tutti I widget dovrebbero essere scritti usando OOP. Se non hai visto il codice come sopra, lo tratteremo nella prossima sezione e dovrebbe fornire tutto ciò che devi sapere per capire cosa sta succedendo.
Prima di iniziare a creare plugin basati su OOP per WordPress, diamo uno sguardo più da vicino alle basi di OOP per assicurarci di avere una terminologia chiara e come funziona il paradigma.
Come abbiamo già definito in precedenza, OOP utilizza "una raccolta di metodi correlati". Ma non possiamo fermarci qui. Dopotutto, la programmazione funzionale fa la stessa cosa.
In OOP, questi "metodi correlati" sono tutti correlati nel contesto di ciò che viene chiamato a classe. Nell'esempio Widget sopra, vedrai il classe parola chiave come prima parola del codice.
Inizia su una linea che termina con una parentesi aperta (molto simile alle funzioni), quindi incapsula - o avvolge - tutte le sue funzioni correlate prima di terminare con la parentesi di chiusura (per ora, ignora la si estende parola chiave nell'esempio del Widget - ne parleremo tra un momento).
Se hai appena iniziato a scrivere lezioni e ti stai chiedendo se una funzione appartiene a una determinata classe, chiediti se la funzione suona come qualcosa che una particolare classe farebbe.
Ad esempio, nell'esempio Widget sopra, il aggiornare il metodo è ovviamente qualcosa che un widget potrebbe fare. Ma diciamo che stai scrivendo un corso che sarà responsabile della lettura di un post sul blog nel database di WordPress. Avrebbe senso che quella particolare classe avesse una funzione chiamata leggere o read_by_id, ma dovrebbe avere una funzione chiamata Scrivi? Che dire Elimina?
A seconda di come hai progettato la tua classe, probabilmente. Ma se il suola Lo scopo della classe è quello di leggere i dati, quindi probabilmente no.
E questo è OOP: raggruppa logicamente le tue funzioni in una classe, ma detto raggruppamento logico dipende dalla responsabilità che stai dando alla tua classe.
OOP è un potente paradigma utilizzato in tutta l'applicazione WordPress. OOP consente operazioni avanzate come l'ereditarietà (che è rappresentata dal si estende parola chiave nella classe Widget), schemi di progettazione che sono essenzialmente soluzioni esistenti a problemi comuni.
Questo articolo non cerca di essere un tuffo nella programmazione orientata agli oggetti. Sta semplicemente cercando di fornire una base su cui esplorare i due modi di scrivere plugin per WordPress, ma li cito qui se dovessi essere interessato ad approfondire ulteriormente la programmazione orientata agli oggetti.
Ora che abbiamo definito la programmazione orientata agli oggetti e analizzato quanto basta per gettare le basi, è ora di iniziare a parlare dei componenti dello sviluppo basato su OOP nel contesto dei plugin di WordPress.
Nel resto di questo articolo, illustreremo le basi di ciò che è necessario per la scrittura di plugin basati su OOP e i vantaggi che esso offre.
Prima di te nulla nello sviluppo orientato agli oggetti, devi definire la tua classe. Supponendo che tu abbia già un'idea di ciò che la tua classe sta per fare, in genere si tratta di pensare a ciò che si desidera assegnare alla classe.
Per la maggior parte, penso che visualizzare codice di esempio sia sempre vantaggioso quando si insegna il codice, quindi daremo un'occhiata al WordPress Plugin Boilerplate.
Si noti che il Plugin Boilerplate è un progetto che ho originariamente creato per aiutare a far partire i plugin basati su OOP. Da allora è stato contribuito da un certo numero di persone diverse. Lo sto usando in questo articolo perché dimostra l'argomento in questione.
Detto questo, nota la definizione della classe per il Plugin Boilerplate:
class PluginName // More to come ...
Dato che il Plugin Boilerplate è un punto di partenza per lo sviluppo, ovviamente rinomineremo la classe. Per questo articolo, chiamiamolo DemoPlugin.
class DemoPlugin // More to come ...
A questo punto, siamo pronti per iniziare a definire le funzioni che vivono all'interno della classe.
In OOP, la prima funzione che è probabile vedere in una classe è una funzione chiamata "il costruttore" e PHP non è diverso.
Una definizione semplice e funzionante del costruttore è questa:
Il costruttore è dove si inizializzano i dati che verranno utilizzati in tutta la classe.
Il modo in cui questo funziona varia da progetto a progetto, ma ci sono due cose principali che possiamo fare nel contesto di un plugin WordPress:
Nel nostro DemoPlugin, faremo proprio questo Imposteremo un dominio di testo di demo-plugin e registreremo le azioni per la registrazione e l'accodamento di un foglio di stile di esempio e un file JavaScript di esempio.
Per essere completi nel nostro esempio, registreremo anche un hook per aggiungere del testo alla fine del contenuto visualizzato in un post.
Per prima cosa, definiamo il costruttore:
class DemoPlugin public function __construct ()
Nota che in PHP, un costruttore è definito da una funzione pubblica chiamata costruire che è preceduto da due underscore.
Successivamente, definiamo il nostro dominio di testo:
Accentsconagua
class DemoPlugin public function __construct () load_plugin_textdomain ('demo-plugin', false, dirname (plugin_basename (__FILE__)). '/ lang'); Nella riga di codice precedente, nota che abbiamo definito la chiave per il nostro dominio di testo demo-plugin e la linea si aspetta di trovare i file di localizzazione in una sottodirectory chiamata Lang nella directory del plugin.
Poiché la localizzazione non rientra negli scopi di questo articolo, non mi immergerò ulteriormente, ma puoi esaminare il codice sorgente per il Plugin Boilerplate per vedere come questo è configurato.
Successivamente, definiamo le azioni per la registrazione dei nostri fogli di stile e JavaScript, nonché il filtro che aggiungerà del testo alla fine del nostro contenuto:
class DemoPlugin public function __construct () load_plugin_textdomain ('demo-plugin', false, dirname (plugin_basename (__FILE__)). '/ lang'); add_action ('wp_enqueue_scripts', array ($ this, 'register_plugin_styles')); add_action ('wp_enqueue_scripts', array ($ this, 'register_plugin_scripts')); add_filter ('the_content', array ($ this, 'append_post_notification')); Se non hai familiarità con azioni e filtri, assicurati di leggere uno dei miei articoli recenti qui su Wptuts + in quanto spiega la differenza.
Ora, se hai familiarità con lo sviluppo del tema di WordPress o con la programmazione funzionale, probabilmente sarai abituato a vedere qualcosa di simile al seguente:
add_action ('wp_enqueue_scripts', 'register_plugin_styles'); Piuttosto che:
add_action ('wp_enqueue_scripts', array ($ this, 'register_plugin_styles')); Si noti che la differenza tra le due chiamate sopra è nel secondo parametro. Nello specifico, nel nostro plugin stiamo passando un array mentre la prima riga di codice passa semplicemente una stringa.
Poiché stiamo sviluppando questo plugin usando OOP, WordPress deve sapere dove chiamare il register_plugin_styles metodo. Dal momento che vive all'interno della nostra classe, dobbiamo dire a WordPress di chiamare il metodo su un'istanza della nostra classe.
Ha senso?
In sostanza, stiamo dicendo a WordPress: ho chiamato questo metodo register_plugin_styles, ma è necessario chiamarlo su un'istanza di questa classe (da cui il Questo parola chiave).
Se sei nuovo in WordPress, ma provieni da un background di programmazione, allora puoi immaginare che stai dicendo a WordPress di fare questo:
$ demo = new DemoPlugin (); $ Demo-> register_plugin_styles ();
In ogni caso, la linea di fondo è che se stai sviluppando i tuoi plugin usando OOP, allora tu dovere registra i tuoi ganci usando un array con due indici: il primo essere $ questo e il secondo è il nome della funzione.
Gli sviluppatori esperti avranno familiarità con la capacità di PHP di passare al referente e al pass-by-value. In WordPress Development, non è così raro vedere quanto segue:
add_action ('wp_enqueue_scripts', array (& $ this, 'register_plugin_styles')); Dove Questo è passato per riferimento; tuttavia, a partire da PHP 5.4, è stata rimossa la possibilità di passare variabili per riferimento al momento della chiamata. Ecco perché questo tutorial sta optando per passare per valore.
Nella programmazione, le funzioni sono le unità di codice che sono essenzialmente responsabili del "fare qualcosa". Nella programmazione orientata agli oggetti, è utile pensarli in modo leggermente diverso.
In OOP, le classi sono solitamente rappresentate da nomi. Nel nostro caso, abbiamo un DemoPlugin. Allo stesso modo, le funzioni sono spesso dei verbi. Cioè, sono azioni che il nostro nome può intraprendere. A questo punto, abbiamo già deciso di definire le seguenti funzioni:
register_plugin_stylesregister_plugin_scriptsappend_post_notificationSi noti come ciascun nome di funzione rappresenta un'azione che può essere intrapresa. Questa è una buona regola da usare quando si scrivono le funzioni.
Nella programmazione funzionale, c'è davvero solo l'idea delle funzioni; tuttavia, in OOP, ci sono diversi tipi di funzioni, due delle quali sono funzioni "pubbliche" e funzioni "private".
Le funzioni pubbliche sono funzioni accessibili al di fuori della classe. Ciò significa che sei in grado di chiamare questi metodi dopo aver istanziato la classe.
Questo è esattamente ciò che abbiamo fatto in precedenza nel seguente codice:
$ demo = new DemoPlugin (); $ Demo-> register_plugin_styles ();
Fondamentalmente, queste funzioni sono accessibili al pubblico (dove il pubblico può essere un programmatore o un altro oggetto).
Le funzioni che stiamo scrivendo per la registrazione dei nostri fogli di stile, il nostro JavaScript e che stiamo scrivendo per aggiungere del testo a un post avere essere contrassegnato come pubblico perché lì volontà essere una terza parte a chiamarli - WordPress.
Definiamo le due funzioni per wp_enqueue_scripts azione:
funzione pubblica register_plugin_styles () wp_register_style ('demo-plugin', plugins_url ('demo-plugin / css / plugin')); wp_enqueue_style ('demo-plugin'); public function register_plugin_scripts () wp_register_script ('demo-plugin', plugins_url ('demo-plugin / js / display.js')); wp_enqueue_script ('demo-plugin'); Ancora una volta, si noti che queste due funzioni si aspettano che i fogli di stile e JavaScript risiedano in css e js sottodirectory, rispettivamente. Per vedere questo in azione, ricorda di controllare il Plugin Boilerplate.
Infine, definiamo la funzione per il contenuto filtro:
funzione pubblica append_post_notification ($ content) $ notification = __ ('Questo messaggio è stato aggiunto con un plug-in demo', 'demo-plugin-locale'); restituire $ contenuti. $ Notifica; Nota che stiamo usando la funzione __ per assicurarci che il nostro script sia localizzato con il textdomain che abbiamo definito nel costruttore.
Se i metodi pubblici sono accessibili a chiunque, implicherebbe che le funzioni private non siano accessibili a nessuno, giusto? Per la maggior parte, è corretto: l'unica persona - o cosa - che può chiamare metodi privati sono la classe in cui sono definiti.
Ciò significa che WordPress, oggetti di terze parti o programmatori non possono chiamare a livello di programmazione le funzioni private. Le funzioni private possono essere richiamate solo all'interno della classe in cui sono utilizzate.
In generale, le funzioni private sono molto utili quando si scrivono metodi di supporto, ovvero sono utili per manipolare i dati internamente per aiutare un'altra funzione a svolgere il proprio lavoro.
Per dare un esempio funzionante, definiamo una funzione privata che restituirà una stringa localizzata che la nostra append_post_notification la funzione può usare:
funzione privata get_localized_notification () return __ ('Questo messaggio è stato aggiunto con un plugin Demo.', 'demo-plugin-locale'); Successivamente, facciamo il refactoring del append_post_notification funzione per chiamare questo nuovo helper:
funzione pubblica append_post_notification ($ content) return $ content. $ This-> get_localized_notification ();
Si noti che abbiamo semplificato la prima funzione aggiungendo una seconda funzione. Potresti anche sostenere che abbiamo aumentato la leggibilità della funzione iniziale aggiungendo una chiamata a una funzione con un nome che aiuta a chiarire cosa sta succedendo.
Forse la cosa più importante da notare è che per chiamare le funzioni private, è necessario anteporre la chiamata alla funzione con $ questo parola chiave e il ->. Questo sta dicendo a PHP: "Chiama il get_localized_notification funzione che vive dentro Questo classe."
In ogni caso, abbiamo assegnato a ciascun metodo una singola responsabilità, un'altra buona pratica nella programmazione orientata agli oggetti, e abbiamo dimostrato l'uso di funzioni pubbliche e private.
Nella programmazione orientata agli oggetti, ci sono anche altri tipi di funzioni che vanno oltre lo scopo di questo articolo.
Per essere completo, ho voluto riassumerli qui:
DemoPlugin :: use_this_static_method (). A questo punto, abbiamo raggiunto tutti gli high note per lo sviluppo WordPress orientato agli oggetti. Per riassumere i vantaggi:
Quando si utilizza la programmazione orientata agli oggetti, non è necessario precedere una funzione con il nome del tema o il nome del plug-in su cui si sta lavorando, né si deve preoccuparsi di nominare una funzione che potrebbe interferire con una funzione WordPress, un'altra funzione di un tema o un'altra funzione di un plugin.
Invece, tutte le funzioni vivono nel contesto di un'altra classe. L'unica cosa da accertare è che la classe non è nominata qualcosa che si interfaccia con un'altra classe esistente.
Utilizzando la programmazione orientata agli oggetti, è possibile chiamare a livello di codice il proprio plug-in al di fuori dell'API standard di WordPress.
Supponiamo che tu stia sviluppando un tema e desideri che qualcosa venga visualizzato nella barra laterale fornita dal tuo plug-in. Nel modello della barra laterale è possibile creare un'istanza del plug-in e quindi richiamare i metodi su di esso per fare in modo che le informazioni vengano scritte nella barra laterale.
Ciò è particolarmente utile quando si lavora su un modello e si desidera fornire alcuni dati predefiniti se l'utente non immette manualmente qualcosa.
Come abbiamo detto all'inizio dell'articolo: questo è solo un modo in cui puoi sviluppare i tuoi plugin WordPress. L'articolo di Stephen spiegherà come farlo usando la programmazione funzionale.
Dopo aver letto questo articolo, dovresti avere una migliore comprensione della programmazione orientata agli oggetti, i suoi vantaggi, e dovresti essere in grado di seguire il codice documentato nell'API Widget, nel mio relativo Widget Boilerplate e anche in tutte le posizioni nella base di codice di WordPress.
