In questo momento, uno dei modelli di progettazione più comuni - se non lo è il Il modello di progettazione più comune, utilizzato nello sviluppo web, è quello di MVC (o Model / View / Controller), ma per quanto sia popolare, non è l'unico modo in cui framework, fondazioni e altre librerie sono costruiti.
Caso in questione: WordPress utilizza il modello di progettazione event-driven per alimentare il suo sistema di aggancio. E anche se gli schemi di progettazione non si escludono a vicenda, è più probabile che tu riconosca quello modello particolare perché è ciò che rende WordPress flessibile come è.
Per essere chiari, questo non significa che altri pattern non siano in uso in tutto il suo codebase (o in qualsiasi altra base di codice dell'applicazione), semplicemente potrebbero non essere facilmente riconoscibili.
Inoltre, una delle cose che gli sviluppatori professionisti si sforzano è scrivere codice gestibile. Ma con l'invecchiamento della codebase e sempre più persone lavorano nella base di codice, diventa sempre più difficile mantenere lo stesso livello di organizzazione, chiarezza e manutenibilità coerenti con l'invecchiamento di un progetto.
Tutte le idee di cui sopra si applicano a WordPress sia che tu stia lavorando su temi, plugin, estensioni, o qualche altro tipo di progetto. Il fatto è che è importante assicurarsi di seguire gli standard di codifica e le convenzioni stabilite per la creazione di questi progetti.
Diciamo che stai lavorando su un plugin che introduce una meta-box personalizzata; tuttavia, non è sufficiente introdurre una meta-box. Invece, stanno per essere creati gruppi di opzioni correlate.
Questo è dove inizia a diventare un po 'più impegnativo. In questa serie, prenderemo in un modo che possiamo scrivere codice mantenibile in WordPress attraverso un plugin di esempio che introduce meta box, varie opzioni e navigazione a schede nel dashboard di WordPress.
Quando sei in procinto di pianificare come pianificare le opzioni per i tuoi metadati, hai un paio di opzioni che sono disponibili:
Per coloro che hanno utilizzato WordPress per un lungo periodo di tempo, è probabile che si abbia familiarità con la visualizzazione della navigazione a schede nel dashboard, almeno in una certa misura. Per coloro che sono curiosi su come implementarlo non solo a livello di programmazione, ma in a mantenibile modo, stiamo andando a vedere come farlo attraverso questa serie.
Nello specifico, scriveremo un piccolo plug-in per WordPress che introduce alcuni campi, opzioni correlate raggruppate in schede, e quindi introdurremo alcuni altri elementi per mostrare come salvare e disinfettare in modo corretto e sicuro, e recuperare i dati.
Come per la maggior parte dei post in serie che scrivo, mi piace provare a delineare quello che faremo ad un livello superiore prima di passare effettivamente al codice. Questo aiuta a fornire una base concettuale su dove siamo diretti e aiuta a delineare la prossima serie di articoli e cosa faremo a livello di codice.
Se non altro, fornisce un posto a cui fare riferimento mentre continuiamo a progredire per tutta la serie.
Prima di guardare la bozza, la cosa che voglio menzionare è che il take-away più importante di questo articolo specifico sarà notare la separazione delle preoccupazioni così come perché abbiamo scelto di fare le cose nel modo in cui lo abbiamo fatto, quindi comprendiamo come può essere d'aiuto con la manutenibilità.
A tal fine, ecco cosa stiamo guardando nei prossimi articoli:
Come per qualsiasi cosa in fase di sviluppo, suddividere le cose in componenti più piccoli è assolutamente fondamentale, quindi per il resto di questo post vedremo i passaggi necessari per iniziare a lavorare su un plug-in che introduce una meta-box nel tipo di post "Post" standard.
Prima di proseguire, imposta la directory dei nostri plugin. Questo dovrebbe includere quanto segue:
LEGGIMI
E, ovviamente, dovremmo assicurarci che le directory siano ben organizzate e che il codice sia chiaro.
Per renderlo almeno in qualche modo pratico, chiameremo questo plugin "Author's Commentary" che ci permette di condividere alcune note candide su ciò che pensavamo, usavamo e annotavamo mentre scrivevamo il post.
Possiamo scegliere di renderlo pubblico in un post futuro in base al tuo feedback, ma per ora penseremo di lasciarlo nel back-end.
Detto ciò, iniziamo.
La cosa che dobbiamo fare è eliminare la struttura delle directory che useremo per il progetto. Vedrai uno screenshot per questo di seguito, dopo di che descriverò lo scopo di ciascuna directory.
La radice della directory include due file:
README.md
qual è lo standard LEGGIMI
che viene fornito con un plugin per WordPress.autori-commentary.php
che è responsabile per l'avvio effettivo del plugin. Questo è il file di bootstrap.Successivamente, abbiamo la directory di amministrazione. Questa directory include:
risorse
che include sottodirectory per i nostri file JavaScript e CSS (utilizzeremo i CSS vanilla in questa serie.class-autori-commentary.php
che sarà la classe principale di quella che racchiude molte delle nostre funzionalità.visualizzazioni
che include una sottodirectory di nome parziali
. Il visualizzazioni
directory sarà responsabile per il rendering delle schede e includendo tutto il contenuto per ogni scheda in base al parziale. Questo è il parziali
la directory include il contenuto per ogni scheda.Si noti che potremmo aggiungere ulteriori directory per il plugin man mano che la serie avanza. Cioè, questa struttura è soggetta a modifiche in quanto probabilmente aggiungeremo o addirittura sposteremo un po 'di contenuto in base a come procede il plugin, ma questa è la struttura di base di cui abbiamo bisogno per iniziare.
Dato che abbiamo la struttura di directory di base strutturata e i file necessari, siamo pronti per iniziare a eliminare parte del codice. Nota che sebbene il plug-in sia funzionale dal punto di vista dell'attivazione, in realtà non farà nulla finché non inizieremo ad aggiungere codice nel prossimo set di articoli.
Detto questo, andremo avanti e compileremo i file necessari per installare e installare il plug-in nel dashboard di WordPress.
La prima cosa che dobbiamo fare è compilare l'intestazione del plug-in in modo che includa il blocco della documentazione necessaria per WordPress per visualizzare il plug-in nel dashboard:
Il condizionale finale si assicura che se qualcuno tenta di accedere direttamente al file, che lo script interrompa l'esecuzione.
Successivamente, dobbiamo assicurarci che il file del plugin principale che abbiamo iniziato sopra sia a conoscenza della classe primaria che abbiamo creato nel passaggio precedente. Per fare questo, abbiamo solo bisogno di un semplice
require_once
dichiarazione.Ma prima di chiamare
require_once
, abbiamo bisogno di un file da includere, giusto? A tal fine, saltiamo nelAdmin
sottodirectory e nelclass-autore-commentary.php
classe, aggiungeremo il seguente codice.I commenti sono auto-esplicativi, ma farò in modo di delineare tutto ciò che sta accadendo dopo che il blocco di codice è stato completato:
* / class Author_Commentary_Admin / ** * L'ID di questo plugin. * * @since 0.1.0 * @accesso privato * @var stringa $ nome L'ID di questo plugin. * / private $ name; / ** * La versione di questo plugin. * * @since 0.1.0 * @accesso privato * @var stringa $ versione La versione corrente di questo plugin. * / versione privata $; / ** * Inizializza la classe e imposta le sue proprietà. * * @since 0.1.0 * @var stringa $ nome Il nome di questo plugin. * @var string $ version La versione di questo plugin. * / funzione pubblica __construct ($ nome, $ versione) $ this-> nome = $ nome; $ this-> version = $ version;Si noti che nel codice sopra, tutto ciò che abbiamo veramente fatto - oltre a fornire documentazione per la nostra classe, proprietà e costruttore - è impostare un costruttore che accetta un
nome $
e a$ versione
parametro.Questi saranno utili in seguito quando importeremo dipendenze e fogli di stile JavaScript. Per ora, tuttavia, questo è tutto ciò di cui abbiamo bisogno per iniziare.
Fatto ciò, possiamo tornare a
autori-commentary.php
e scrivi il codice per l'avvio del plugin.Per prima cosa, useremo
require_once
per importare la classe che abbiamo appena creato:Quindi imposteremo una funzione semplice e una chiamata di funzione per avviare il processo:
Si noti che non definiamo alcun hook in questo file. Alla fine tutto risulterà nel subpackage - questo ci aiuta a separare le nostre preoccupazioni in modo più efficace rendendo il codice più gestibile, e ci consente di mantenere il nostro codice il più possibile orientato agli oggetti.
Si noti che questo definisce una funzione semplice che, quando viene chiamata non appena viene attivato il plugin, crea un'istanza di
Author_Commentary_Admin
classe dopo aver superato il necessarionome $
e$ versione
parametri.Posa del fondamento
A questo punto, sono state poste tutte le basi che ci aiuteranno ad andare avanti con il lavoro sul nostro plugin. Dovresti essere in grado di scaricare il file da GitHub, installarlo in WordPress e attivarlo.
Di nuovo, questo non mostrerà nulla, ma prepara la base di codice per il lavoro che inizieremo nel prossimo articolo.
Se hai domande sopra il codice sopra o dove è diretta la serie, non esitare a lasciare un commento; altrimenti, non vedo l'ora di vederti nella prossima puntata.