Share
Nel primo post di questa serie, abbiamo esaminato alcune delle strategie disponibili in relazione all'organizzazione delle nostre directory tematiche di WordPress al fine di renderle più manutenibili.
Nello specifico, abbiamo toccato come organizzare:
In definitiva, l'obiettivo era quello di fornire uno schema di directory in cui poter organizzare i nostri file in modo da avere un livello di coesione, comprensione e manutenibilità per il lavoro che stiamo facendo.
Ma non è tutto quello che c'è da scrivere su temi WordPress mantenibili. Un altro è seguire le convenzioni stabilite dagli standard di codifica di WordPress; tuttavia, questo articolo non darà uno sguardo agli standard. Il Codice fa un ottimo lavoro e li abbiamo coperti in un'altra serie.
Invece, daremo un'occhiata un po 'più granulosa ad alcune delle strategie e degli strumenti che possiamo usare per assicurarci di rendere i nostri temi il più sostenibili possibile. In questo particolare post, esamineremo le strategie, quindi concluderemo la serie esaminando alcuni degli strumenti disponibili.
Come accennato in precedenza, una cosa è avere un modo logico di organizzare tutte le directory, i file e le librerie che costituiscono il tema; tuttavia, questa è solo la metà di ciò che viene impiegato per costruire un tema.
Dopo tutto, ci sono modelli, funzioni, convenzioni di denominazione e strumenti predefiniti che contribuiscono a creare il tema oa testare il tema per assicurarsi che non utilizzi alcuna chiamata API deprecata e che sia compatibile con la versione più recente di WordPress.
A tal fine, penso che sia importante comprendere ognuno di questi argomenti sia come qualcuno che sta appena iniziando a sviluppare temi WordPress, sia come qualcuno che lo sta facendo da tempo.
Dopotutto, non c'è mai un momento migliore per cercare di migliorare ciò che stai facendo. Inoltre, i commenti sono anche un ottimo posto per continuare la discussione per condividere idee alternative.
Ma prima di arrivare, parliamo di alcune cose pratiche che possiamo fare in relazione ai temi di WordPress, e questo aumenta la manutenibilità di ciò che stiamo facendo.
Innanzitutto, se non hai familiarità con la gerarchia dei modelli, ti consiglio vivamente di leggere la pagina del Codex corrispondente prima di continuare con questo articolo.
In breve, i modelli possono essere descritti come segue:
I modelli WordPress si adattano come i pezzi di un puzzle per generare le pagine Web sul tuo sito WordPress. Alcuni modelli (ad esempio i file modello di intestazione e piè di pagina) vengono utilizzati su tutte le pagine Web, mentre altri vengono utilizzati solo in determinate condizioni.
Un altro modo di pensarci è questo: quando si tratta di WordPress, tutto ciò che viene visualizzato all'utente proviene dal database. Questo include il titolo del post, i dati del post, le categorie dei post, i contenuti dei post, i commenti e così via.
I modelli sono i veicoli attraverso i quali le informazioni sono presentate all'utente. Sono composti da markup e PHP, in stile tramite CSS, e possono avere alcuni effetti applicati attraverso l'uso di JavaScript.
Ma, assumendo che tu non stia facendo nulla di avanzato con cose come tipi di post personalizzati e / o tassonomie personalizzate (un argomento per un altro post, in realtà), allora c'è una cosa unica nella gerarchia dei modelli WordPress che può servire sia come lusso che come un problema di manutenzione a seconda di come lo si guarda.
Si noti che nell'articolo Codex collegato, WordPress avrà impostazione predefinita index.php, header.php, e footer.php modelli. La verità è che puoi davvero farla franca creando un intero tema WordPress usando solo index.php.
Sembra interessante, vero? Voglio dire, chi ha bisogno di creare tanti file diversi quando puoi creare un tema simpatico, piccolo e snello che fa tutto ciò che ti serve.
Ma poi pensa a questo dal punto di vista di lavorare con una squadra di entrambi i tuoi pari, di coloro che potrebbero contribuire a un repository aperto o di quelli che potrebbero eventualmente riprendere da dove avevi lasciato..
Se tutto il codice richiesto per rendere le informazioni dal database è contenuto in un singolo file, le probabilità che la complessità di quel file aumenti dalla sua stessa creazione sono molto alte.
Al livello più elementare, stiamo esaminando un singolo file con un numero di condizionali, alcune dichiarazioni di switch e così via. E tutto questo viene fatto perché devi tenere conto delle pagine di archivio, delle singole pagine di post, dei singoli post, dell'elenco principale e così via.
Capito quello che intendo?
Ma poi, creando un file separato appena per attenuare quella complessità può essere una bestia tutta da sola. Ad esempio, diciamo che lo hai single.php per visualizzare un singolo post e tu hai page.php per visualizzare una pagina e entrambi i modelli hanno le stesse identiche informazioni tranne single.php ha post metadati e page.php non.
Questo è un esempio lampante di quando puoi estrarre i metadati dei post in una propria parte, come abbiamo discusso nel precedente articolo. O forse puoi estrarre il codice responsabile del rendering del contenuto suo proprio parziale.
Qualunque sia il caso, il punto che sto cercando di fare è che c'è un equilibrio da colpire quando si tratta di lavorare con i modelli di WordPress e la gerarchia dei modelli di WordPress.
Non penso che sia una buona idea utilizzare un numero minimo di modelli, ma non penso sia necessario utilizzare ogni singolo modello supportato Se porta a troppa duplicazione del codice. Là è un bilanciamento tra modelli e partial.
In definitiva, penso che l'esperienza su come usare ciò che viene con il tempo, ma avere questo stato d'animo fin dall'inizio può aiutare a fornire un livello di organizzazione e manutenibilità che fa passi da gigante avanti a dove tu potrebbe iniziare avendo non fatto solo un po 'di pre-pianificazione.
Quando si tratta di lavorare con le funzioni e le convenzioni di denominazione, di solito ci sono due regole da seguire:
Accentsconagua
ritorno dati e che cosa eco datiMa se sei una persona appena iniziata nello sviluppo del tema, o sei una persona che sta cercando di migliorare le proprie capacità nel fare ciò, che aspetto ha praticamente?
Quando si tratta di nominare le proprie funzioni in modo univoco, i motivi per farlo sono che non si scontrino accidentalmente con una funzione preesistente definita in WordPress o un plugin che potrebbe essere in esecuzione nel proprio ambiente.
Ad esempio, supponiamo che tu stia scrivendo la tua funzione che filtrerà il contenuto prima di renderlo alla pagina. Il modo corretto per farlo è ovviamente usare il add_filter funzione; tuttavia, chiameresti la tua funzione il contenuto?
No certo che no. Il motivo è perché WordPress già definisce il contenuto. Se rinomina una funzione con quel nome, otterrai degli errori. A tal fine, è sempre meglio anteporre le tue funzioni a una chiave univoca come il nome del tuo tema o qualcosa di simile.
Quindi diciamo che vogliamo anteporre una firma alla fine dei nostri contenuti, e diciamo che abbiamo un tema che chiamiamo Acme. Per fare ciò, consiglio di creare una funzione chiamata acme_the_content perché identifica il nome del tema e indica il nome della funzione a cui è agganciato.
Diciamo che vuoi terminare ogni post con il tuo nome e il tuo nickname. Per fare ciò, puoi definirlo nel tuo functions.php file:
'; $ signature. = 'Tom | @tommcfarlin'; $ firma. = ''; return $ content. = $ signature;
È relativamente semplice, no? In breve, cerco di utilizzare il formato seguente quando creo le mie funzioni collegate: theme_name-name_of_hook.
Questo lo rende molto facile da capire e da seguire non solo durante la navigazione del codice ma durante la visualizzazione delle funzioni che compongono il tema o il file attualmente attivo nel tuo IDE.
Come accennato in precedenza, WordPress ha un'altra convenzione che usa e che ha a che fare con se le informazioni saranno restituite dalla funzione chiamata o echeggiate dalla funzione chiamata.
Fortunatamente, questa particolare regola empirica è davvero facile da ricordare:
ottenere_ ottenere_ Puoi trovare alcuni anomalie, ma questo è il senso generale di come l'API di WordPress indica come restituirà i dati una volta che hai chiamato la funzione.
Nel mantenere coerente con il nostro esempio precedente, facciamo in modo che si vogliano echo i dati quando viene chiamata la funzione, quindi si dovrebbe semplicemente chiamare il contenuto(); tuttavia, se desideri recuperare il contenuto da un post, ad esempio all'interno di un ciclo personalizzato, chiamerai get_the_content () e memorizzalo nella tua variabile.
Forse qualcosa del genere: $ content_for_later = get_the_content (). Ora hai letto i dati per il contenuto che è attualmente correlato al post attivo in The Loop e lo hai archiviato in una variabile che puoi usare in seguito.
Ma sapere come WordPress chiama le sue funzioni per te è solo la metà. Dopo tutto, hai intenzione di creare un tema o un plug-in e vuoi essere sicuro che tu sia coerente con il "modo WordPress" di fare le cose, giusto?
Caso in questione: nell'esempio precedente, in cui abbiamo filtrato il contenuto, abbiamo aggiunto come prefisso la funzione in modo tale che fosse denominato acme_the_content, che indica che il Acme il tema restituirà il contenuto da qualsiasi punto all'interno del tema.
Cosa accadrebbe se dovessimo nominare la funzione acme_get_the_content () ?
Bene, tecnicamente parlando la funzione farebbe comunque eco ai dati ovunque sia stata chiamata; tuttavia, sarebbe incoerente con l'API di WordPress perché lo sviluppatore si aspetterebbe che i dati venissero restituiti in modo tale che sarebbero in grado di memorizzarli in una variabile o di passarli a un'altra funzione.
C'è una discrepanza tra ciò che l'utente si aspetta che accada e ciò che realmente accade.
Se stessimo parlando di qualcosa nel mondo reale, allora sarebbe come avere un interruttore sul muro per il quale l'utente aspetta che quando capovolgono l'interruttore, una luce o un ventilatore si accendono nella stessa stanza quando, in realtà, forse non accade nulla o una luce o una ventola in un'altra stanza si accende.
A tal fine, dobbiamo stare attenti con la denominazione delle nostre funzioni in modo che non stiamo solo scrivendo funzioni che non entrano in collisione con altre funzioni, ma che sono anche chiaramente nominate, e che indicano Come gestiranno le informazioni quando viene chiamata la funzione.
Come accennato all'inizio di questo articolo, ci sono anche una serie di strumenti e impostazioni che possiamo installare e configurare nel nostro ambiente di sviluppo che ci aiuterà a cogliere tutti i potenziali problemi prima che finiamo per lanciare il nostro tema.
Ciò significa che saremo in grado di identificare le funzioni che verranno definitivamente rimosse da WordPress in modo da non scrivere codice scaduto. Inoltre, ci sono modi per sapere se le variabili a cui stiamo tentando di accedere non hanno, per esempio, indici che sono definiti, o altre caratteristiche simili.
Nell'articolo finale della serie, daremo un'occhiata esattamente a quello. Nel frattempo, rivedi cosa è stato trattato qui, sentiti libero di condividere le tue domande e i tuoi commenti nel feed qui sotto, e poi cercheremo di concludere questa serie la prossima settimana.
