Creazione di Meta box gestibili Meta Rifattorizzazione

In questa serie, ci siamo concentrati sulla creazione di meta box gestibili per WordPress. Con ciò intendo che abbiamo lavorato per creare un plugin per WordPress che sia ben organizzato, conforme agli standard di codifica di WordPress e che possa essere facilmente adattato e mantenuto man mano che il progetto avanza nel tempo.

Sebbene abbiamo implementato alcune buone pratiche, c'è ancora spazio per il refactoring. Per questa serie, questo è fatto dal design. Ogni volta che stai lavorando a un progetto per un cliente o per una società più grande, le probabilità che tu debba mantenere una base di codice esistente sono piuttosto alte. Come tale, volevo che potessimo tornare al nostro codebase per perfezionare parte del codice che abbiamo scritto.

Nota che questo articolo non sarà scritto nel formato che gli altri sono stati scritti - cioè, non ci sarà un approccio "First we do this, then we do this" allo sviluppo. Invece, metteremo in evidenza diverse aree che necessitano di refactoring e quindi gestirle indipendentemente dalle altre modifiche che stiamo apportando.

refactoring

Per essere chiari, l'atto di refactoring (come definito da Wikipedia) è:

Il refactoring migliora gli attributi non funzionali del software. I vantaggi includono una migliore leggibilità del codice e una minore complessità per migliorare la manutenibilità del codice sorgente e creare un'architettura interna o un modello di oggetto più espressivi per migliorare l'estensibilità.

In breve, rende il codice più leggibile, meno complesso, più facile da seguire e lo fa tutto senza modificare il comportamento del codice dal punto di vista degli utenti finali.

Questo può essere ottenuto in diversi modi ognuno dei quali è unico per il progetto dato. Nel nostro caso, esamineremo il refactoring dei nostri costruttori, alcuni dei nostri metodi di salvataggio, alcuni dei nostri metodi di supporto e altro ancora.

In definitiva, l'obiettivo è mostrare alcune strategie che possono essere utilizzate durante i tuoi futuri sforzi in WordPress. Cercherò di coprire il più possibile in questo articolo; tuttavia, si noti che potrebbero esserci opportunità per ulteriori refactoring che non sono coperti.

Se è così, bene! Sentiti libero di crearli sulla tua istanza del codice base. Detto ciò, iniziamo.

Il costruttore

Se dai un'occhiata al nostro costruttore: 

nome = $ nome; $ this-> version = $ version; $ this-> meta_box = new Authors_Commentary_Meta_Box (); add_action ('admin_enqueue_scripts', array ($ this, 'enqueue_admin_styles')); add_action ('admin_enqueue_scripts', array ($ this, 'enqueue_admin_scripts')); 

Nota che al momento sta facendo due cose:

1. Inizializzazione di proprietà come il nome e la versione
2. Registrazione degli hook con WordPress

È prassi comune vedere gli hook impostati nel contesto di un costruttore in un plug-in di WordPress, ma non è proprio il posto ideale per farlo.

Si dovrebbe usare un costruttore per inizializzare tutte le proprietà che sono rilevanti per la classe data in modo tale che quando un utente crea un'istanza di una classe, lui / lei ha tutto il necessario per lavorare con la classe. 

Dal momento che potrebbero non voler registrare hook nel momento in cui inizializzano la classe, è necessario estrapolarlo initialize_hooks metodo. Il nostro codice dovrebbe ora apparire come questo:

nome = $ nome; $ this-> version = $ version; $ this-> meta_box = new Authors_Commentary_Meta_Box ();  public function initialize_hooks () add_action ('admin_enqueue_scripts', array ($ this, 'enqueue_admin_styles')); add_action ('admin_enqueue_scripts', array ($ this, 'enqueue_admin_scripts'));  

Dopodiché, dobbiamo assicurarci di aggiornare il codice di base di authors-commentary.php in modo che esso instanzia correttamente e registri i ganci.

initialize_hooks ();  run_author_commentary ();

Qui, la differenza principale è che abbiamo aggiornato il numero di versione che stiamo passando alla classe principale e stiamo anche chiamando esplicitamente il initialize_hooks funzione nel contesto di run_author_commentary.

Se esegui il tuo codice adesso, tutto dovrebbe funzionare esattamente come prima di questo refactoring.

Vorrei anche aggiungere che è possibile stabilire un caso in cui una classe separata è responsabile del coordinamento di hook e callback in modo tale che la responsabilità risieda in una classe separata. Anche se sono un fan di questo approccio, è al di fuori dello scopo di questo particolare articolo.

Avanti, andiamo avanti e facciamo la stessa cosa CLASS-autori-commento-meta-box.php. Piuttosto che creare una nuova funzione, possiamo semplicemente rinominare il costruttore in quanto il costruttore non fa realmente nulla. Ciò significa che il nostro codice dovrebbe andare dal seguente aspetto:

A questo:
E il cambiamento finale che dobbiamo fare è aggiornare il costruttore nella classe principale in modo che ora legga all'interno del initialize_hooks funzione che abbiamo creato nella classe plugin principale.
meta_box-> initialize_hooks (); add_action ('admin_enqueue_scripts', array ($ this, 'enqueue_admin_styles')); add_action ('admin_enqueue_scripts', array ($ this, 'enqueue_admin_scripts')); 
Di nuovo, aggiorna la pagina e il tuo plugin dovrebbe funzionare come prima di questo refactoring.
Metodi di supporto
Nel Authors_Commentary_Meta_Box classe, abbiamo un numero di condizionali nel save_post funzione che è molto ridondante. Quando ciò accade, questo di solito significa che molte delle funzionalità possono essere astratte in una funzione di supporto e quindi richiamate all'interno della funzione in cui sono state posizionate inizialmente.
Diamo un'occhiata al codice così com'è adesso:
is_valid_post_type () || ! $ this-> user_can_save ($ post_id, 'authors_commentary_nonce', 'authors_commentary_save')) return;  // Se la textarea 'Bozze' è stata popolata, allora disinfettiamo le informazioni. if (! empty ($ _POST ['autori-commentary-drafts'])) // Rimuoviamo tutto lo spazio bianco, i tag HTML e codifichiamo le informazioni da salvare $ drafts = trim ($ _POST ['authors- commento-bozze ']); $ drafts = esc_textarea (strip_tags ($ drafts)); update_post_meta ($ post_id, 'authors-commentary-drafts', $ drafts);  else if ("! == get_post_meta ($ post_id, 'authors-commentary-drafts', true)) delete_post_meta ($ post_id, 'authors-commentary-drafts'); // Se gli input 'Risorse' esistono, eseguono l'iterazione e li disinfettano se (! empty ($ _POST ['autori-commenti-risorse'])) $ resources = $ _POST ['autori-commenti-risorse']; $ sanitized_resources = array (); foreach ($ risorse come $ risorsa) $ resource = esc_url (strip_tags ($ resource)); if (! empty ($ resource)) $ sanitized_resources [] = $ resource; update_post_meta ($ post_id, 'authors-commentary- resources ', $ sanitized_resources); else if ("! == get_post_meta ($ post_id,' authors-commentary-resources ', true)) delete_post_meta ($ post_id,' autori-commenti-risorse ');  // Se ci sono dei valori salvati nell'input "Pubblicato", salvali se (! Empty ($ _POST ['autori-commenti-commentari'])) update_post_meta ($ post_id, 'autori-commenti-commenti' $ _POST ['autori-commenti-commenti']);  else if ("! == get_post_meta ($ post_id, 'authors-commentary-comments', true)) delete_post_meta ($ post_id, 'autori-commenti-commenti');
A parte il fatto che il metodo è troppo lungo per cominciare, ci sono una serie di cose che possiamo pulire:
 
Il condizionale iniziale che utilizza logico non e logico O operatori
 
I condizionali che controllano la presenza di informazioni nel $ _POST schieramento
 
Le funzioni di disinfezione, aggiornamento e / o eliminazione per i meta dati associati
 
Diamo un'occhiata a ciascuno di questi individualmente e lavoriamo sul refactoring di questa funzione.
1. La condizione iniziale
Lo scopo del primo controllo condizionale è assicurarsi che l'utente corrente abbia la possibilità di salvare i dati nel post specificato. In questo momento, stiamo letteralmente controllando se il tipo di post corrente è un tipo di post valido e se l'utente ha il permesso di salvare dati i valori attuali nonce passati da WordPress.
In questo momento, il codice legge:
Se questo non è un tipo di post valido o l'utente non ha il permesso di salvare, quindi esci da questa funzione.
Non è tutto insieme terribile, ma potrebbe sicuramente essere migliorato. Invece di avere un O, consolidiamolo in un'unica valutazione in modo tale che legga:
Se l'utente non dispone dell'autorizzazione per il salvataggio, quindi esci da questa funzione.
Fortunatamente, questa è una soluzione relativamente facile. Poiché il tipo di post che si sta salvando aiuta a stabilire se l'utente ha o meno il permesso di salvare il post, possiamo spostare quella logica nel user_can_save funzione.
Quindi prendiamo il is_valid_post_type funzione e spostarlo nel user_can_save funzione:
is_valid_post_type () && $ is_valid_nonce; 
Ora tutta la logica che è responsabile per determinare se l'utente può salvare i metadati del post è incapsulata all'interno di una funzione specificamente progettata per valutare esattamente che.
Abbiamo iniziato con questo:
is_valid_post_type () || ! $ this-> user_can_save ($ post_id, 'authors_commentary_nonce', 'authors_commentary_save')) return; 
E ora abbiamo questo:
user_can_save ($ post_id, 'authors_commentary_nonce', 'authors_commentary_save')) return;  
Legge molto più facile, non è vero??
2. Verifica della matrice $ _POST
Quindi, prima di iniziare a disinfettare, convalidare e salvare (o eliminare) i metadati, stiamo controllando il $ _POST raccolta per assicurarsi che i dati effettivamente esistano. 
Possiamo scrivere una piccola funzione di supporto che si prenderà cura di questa valutazione per noi. Sebbene in pratica stiamo scrivendo un po 'di codice che rende la nostra valutazione più dettagliata, i condizionali leggeranno un po' più chiaramente di come se li avessimo appena lasciati.
Innanzitutto, introdurre la seguente funzione (e notare che accetta un parametro):
Successivamente, refactoring tutte le chiamate che inizialmente stavano chiamando il ! vuoto ($ _POST [...]) in modo che sfruttino questa funzione.
Ad esempio, le chiamate di funzione dovrebbero apparire così:
if ($ this-> value_exists ('authors-commentary-comments')) // ... else // ...
2. Eliminazione dei metadati
Si noti che in tutti i condizionali che sono posizionati in quella funzione, ogni valutazione per l'eliminazione dei metadati dei post se il valore non esiste sembra esattamente la stessa.
Ad esempio, ogni volta vediamo qualcosa di simile:
Questa è un'ovvia possibilità di refactoring del codice. Come tale, creiamo una nuova funzione chiamata delete_post_meta e incapsulare tutte queste informazioni:
Ora possiamo tornare indietro e sostituire tutte le altre valutazioni condizionali per effettuare una chiamata a questa singola funzione in modo che legga qualcosa come la seguente:
value_exists ('authirs-commentary-drafts')) // Rimuoveremo tutto lo spazio bianco, i tag HTML e codificheremo le informazioni da salvare $ drafts = trim ($ _POST ['authors-commentary-drafts']); $ drafts = esc_textarea (strip_tags ($ drafts)); update_post_meta ($ post_id, 'authors-commentary-drafts', $ drafts);  else $ this-> delete_post_meta ($ post_id, 'authors-commentary-drafts'); 
A questo punto, abbiamo solo un altro aspetto di questa parte del codice per il refactoring.
3. Sanificazione e risparmio
In questo momento, il modo in cui i metadati del post vengono salvati viene fatto attraverso un processo di valutazione della presenza dei dati nel $ _POST raccolta, disinfettandola in base al tipo di informazione e quindi salvandola nei metadati dei post.
Idealmente, vorremmo disinfettare i dati nella sua funzione e salvare i metadati dei post nella sua funzione. Quindi, dobbiamo introdurre nuove funzioni.
Per prima cosa, lavoriamo sull'igienizzazione. Perché abbiamo a che fare textarea e matrici, ci sono un paio di modi in cui dobbiamo gestire la chiamata di disinfezione. Dal momento che stiamo lavorando con un array o non lo siamo, possiamo creare una funzione che accetta un parametro opzionale che denota se stiamo lavorando o meno con un array.
Se non stiamo lavorando con un array, tratteremo i dati in arrivo come testo; altrimenti, lo tratteremo come un array:
Successivamente, è possibile aggiornare le chiamate di disinfezione per utilizzare questo metodo. Ma prima di farlo, scriviamo anche un piccolo aiuto che sarà responsabile dell'aggiornamento dei metadati dei post con gli input sterilizzati:
Ora possiamo aggiornare tutti i condizionali che stavamo usando in precedenza nella funzione per leggere in questo modo:
user_can_save ($ post_id, 'authors_commentary_nonce', 'authors_commentary_save')) return;  if ($ this-> value_exists ('authors-commentary-drafts')) $ this-> update_post_meta ($ post_id, 'authors-commentary-drafts', $ this-> sanitize_data ('authors-commentary-drafts') );  else $ this-> delete_post_meta ($ post_id, 'authors-commentary-drafts');  if ($ this-> value_exists ('authors-commentary-resources')) $ this-> update_post_meta ($ post_id, 'autori-commenti-risorse', $ this-> sanitize_data ('autori-commenti-risorse', vero ) );  else $ this-> delete_post_meta ($ post_id, 'autori-commenti-risorse');  if ($ this-> value_exists ('authors-commentary-comments')) $ this-> update_post_meta ($ post_id, 'autori-commenti-commenti', $ _POST ['autori-commenti-commenti']);  else $ this-> delete_post_meta ($ post_id, 'autori-commenti-commenti'); 
Nota che potremmo effettivamente refactoring questo particolare ancora di più così non ci sono tanti condizionali, ma per il bene della lunghezza dell'articolo, la durata del tempo, e anche cercando di introdurre altre strategie, questo verrà lasciato come un esercizio da fare nel tuo tempo libero.
Conclusione
Ormai, abbiamo completato il nostro plugin. Abbiamo scritto un plug-in che introduce una meta-box per fornire opzioni per gli autori che stanno scrivendo post sul blog. 
Inoltre, abbiamo utilizzato gli standard di codifica di WordPress, alcune solide strategie di organizzazione dei file e abbiamo creato una serie di metodi di supporto e astrazioni che ci aiuteranno a mantenere questo particolare plug-in in quanto sottoposto a sviluppo futuro.
Poiché non è facile evidenziare ogni singola opportunità di refactoring, ci sono probabilmente ulteriori modifiche che potrebbero essere apportate. Nel tuo tempo libero sentiti libero di provare a implementarne alcuni da solo.
Nel complesso, spero che ti sia piaciuta la serie e ne hai imparato molto, e spero che ti aiuterà a scrivere un codice migliore e più gestibile in futuri progetti basati su WordPress.



		
			
	   
	




Codice