Share
Quando si tratta di creare temi WordPress - come con molti altri tipi di cose, in realtà - ci sono giusti modi e modi sbagliati per farlo. Per quelli di noi che vogliono essere sviluppatori professionisti di WordPress, per quelli di noi che si preoccupano veramente del lavoro che stiamo facendo, e per quelli di noi che vogliono che il nostro lavoro duri, allora dobbiamo essere lungimiranti pensando a come stiamo organizzando i file e il codice che entra nel nostro tema.
Sì, il Codice WordPress offre un fantastico articolo sullo sviluppo del tema, e credo che dovrebbe essere necessario leggere per chiunque stia iniziando a sviluppare temi - particolarmente temi premium - ma ci sono alcune strategie che non copre che ho trovato molto utili in relazione alla costruzione, al rilascio e al mantenimento di temi nel tempo.
Nei prossimi due articoli, daremo un'occhiata ad alcune strategie che vanno un po 'più in profondità nello sviluppo del tema che ci aiuterà a strutturare i nostri temi in modo tale che non solo seguiranno le linee guida di WordPress Codex, ma renderà anche molto più semplice mantenere, aggiornare e migliorare non solo con l'avanzamento di WordPress, ma anche con la maturazione del nostro tema.
La qualità dell'organizzazione dei file e del codice che introduce nella creazione di temi WordPress è in qualche modo un argomento scottante.
Per essere chiari, questa è una di quelle cose di cui gli sviluppatori e i designer amano parlare fino a un punto in cui si è trasformato in qualcosa che la gente ama odiare. Ciò vuol dire che gli altri commenteranno spesso temi di scarsa qualità disponibili per WordPress, e utilizzeranno tale argomento come motivo per cui WordPress è una piattaforma povera non solo per i blog, ma per altri motivi,.
Questo non è il punto o l'argomento di ciò di cui parleremo qui, né è inteso a ispirare questo tipo di discussione nei commenti. Invece, questa serie in due parti assume quanto segue:
Certo, noi tutti hanno i nostri modi di fare le cose in modo che i consigli condivisi in questa serie potrebbero non funzionare con il flusso di lavoro corrente. Forse non vuoi cambiare - e va bene! - o forse stai cercando un cambiamento.
Indipendentemente dal caso, tutto ciò che viene condiviso qui è basato sull'esperienza nella creazione e gestione di temi premium per WordPress e ha reso molto più facile mantenerli nel tempo sia da un punto di vista specifico del tema, ma da un punto di vista della compatibilità di WordPress, nonché.
Una delle parti più difficili del software di costruzione non è la versione iniziale di spedizione (anche se questo è dura di per sé), ma sta mantenendo il prodotto dopo il rilascio.
Ciò non significa solo che il codebase continui a essere compatibile con l'infrastruttura sottostante, di cui parleremo nella prossima sezione, ma che i file siano organizzati in modo tale da essere compresi dal team di sviluppo , che hanno un livello di coesione, e che hanno una filastrocca e una ragione per cui vengono chiamati e messi nel modo in cui sono.
Sappiamo dal Codice che ci sono un certo numero di file che costituiscono il nucleo del tema. Questo include modelli, un file di funzioni e almeno un foglio di stile.
Cosa succede, però, quando il tuo tema diventa più complicato? Dì che tu ...
Tutto quanto sopra può essere organizzato in modo pulito all'interno di una directory di temi WordPress. Daremo un'occhiata a ciascuno di questi dettagli un po 'più dettagliati e alla logica alla base della loro collocazione nella directory dei temi, nella speranza che ciò renda più pulito lo sviluppo del tema e che questo semplifica notevolmente la manutenibilità.
Sebbene in molti contesti, questi possono essere discussi indipendentemente l'uno dall'altro poiché sono responsabili di cose diverse, la loro struttura organizzativa all'interno di un tema è così simile che ha senso raggrupparli insieme.
Innanzitutto, supponendo che non si stia utilizzando alcun tipo di pre-processore CSS, allora dovrebbe esserci una directory per ognuno di questi tipi di file. Cioè, dovresti avere un css directory e a js directory (o forse li chiamerai stili e javascript).
In ogni caso, ogni tipo di file deve risiedere nella propria directory. Da lì, puoi quindi usarlo functions.php per registrare e accodare i file secondo necessità. Se si tratta di un file utilizzato in tutto il tema, lo registrerai incondizionatamente.
Ma se si tratta di uno stile o di uno script che viene utilizzato solo su un modello particolare, un particolare tipo di post o anche su una parte del dashboard, allora è possibile - e dovrebbe - accodare il file in modo condizionale.
Ma diciamo che tu siamo usando un preprocessore. A questo punto, rimarrai con il tuo file preelaborato e i tuoi file post-elaborati. A seconda della natura del tuo progetto, potresti avere o meno tutto ridotto a un singolo file.
io voluto fare raccomandazioni su come nominare i file; tuttavia, la variazione dei temi, il modo in cui le persone costruiscono il loro lavoro e il problema un determinato tema sta cercando di risolvere le questioni e questo ci porta oltre lo scopo di questa particolare strategia.
Ad ogni modo, se stai per utilizzare un pre-processore, ti consiglio di creare una sottodirectory nel css e js directory chiamate dev (o sviluppo o qualsiasi altra cosa tu scelga di chiamarlo). In questa directory, si scrivono tutti i file pre-elaborati, quindi si lascia il proprio strumento di scelta (sia CodeKit, Grunt, o qualcosa del genere) che emette i file elaborati nella root della css e js directory.
In questo modo, hai ancora codice elaborato, combinato e / o miniato e hai una directory che contiene la fonte di quei file. Quando arriva il momento di spedire il tema, non solo hai i file di chiamata functions.php nelle rispettive directory, ma puoi anche escludere il dev directory dalla build finale in modo che l'utente finale riceva un pacchetto di temi più piccolo e non ottenga altro che il necessario per eseguire il tema.
Le parti del modello sono spesso definite partial (più in altre lingue che in WordPress) e vengono spesso chiamate usando get_template_part in WordPress. In breve, il loro scopo è di estrarre il codice ripetitivo che può essere facilmente incorporato in più modelli.
Un esempio di ciò sarebbe, ad esempio, il post metadati. Questo di solito include le seguenti informazioni:
Poiché queste informazioni possono esistere in più modelli (pensa a post singoli, pagine, archivi e così via), allora avrebbe senso estrapolarlo in un singolo file e fare semplicemente riferimento a quel file quando ne hai bisogno.
Il fatto è che i metadati dei post non sono i solo tipo di informazioni riutilizzate in un tema. A tal fine, identifica gli elementi principali che vengono riutilizzati, li astraggono in un file, quindi crea un parziali elenco.
Da lì, denominare ogni parte del modello qualcosa che indica ciò che rappresenta (ad esempio post-meta.php, gravatar.php, navigation.php, pagination.php, e così via) e quindi effettuare una chiamata al parziale nel modello in cui è necessario.
Ad esempio, nei modelli di post, pagina e archivio, puoi chiamare get_template_part ('partials / post-meta');. Rende molto più facile la lettura e rende per a singolo posto per fare un cambiamento piuttosto che in ogni modello.
Se stai scrivendo un tema internazionalizzato che, se lo stai pubblicando pubblicamente, dovresti farlo, allora c'è un modo molto chiaro e pulito per farlo.
Innanzitutto, se questo è un argomento nuovo per te, allora ti consiglio di leggere l'articolo nel Codex. Ti dirà tutto ciò che devi sapere su come preparare le stringhe per la traduzione, gli strumenti disponibili e così via.
Quindi, ti consiglio di assicurarti di avere un posto dedicato nel tuo tema per le tue lingue. In generale, ti consiglio di creare una directory nel tuo tema chiamato Lang o le lingue e poi lasciando cadere il .Po e .momento file in detta directory. Questa è anche una pratica generalmente accettata e attesa all'interno della comunità di WordPress in generale.
Non solo relegano le traduzioni al loro posto all'interno della struttura del tema, ma indicano anche agli altri dove cercare traduzioni e dove cercare i file che offrono le stringhe che devono essere tradotte.
Ancora una volta, riguarda la coesione e assicurarsi che le cose di utilità simile siano raggruppate in un modo ragionevole.
A seconda del tuo background in fase di sviluppo, le funzioni che utilizzi per aiutare a svolgere il lavoro e per aiutare a separare la logica di business dalla logica di presentazione (o, in molti casi, direttamente da PHP da HTML), sono chiamate funzioni di supporto o funzioni di utilità.
Per lo scopo di questa serie, ci riferiremo a loro come funzioni di aiuto, anche se sappiamo che sono tutti nello stesso modo.
Ma questo solleva due domande:
Accentsconagua
functions.php?functions.php, dove vivono?In breve, sono della mente che dovrebbero essere aiutanti e utilità non vivere dentro functions.php. La mia regola generale è semplicemente questa: se il codice che sto scrivendo comunica direttamente con WordPress come add_theme_support, allora appartiene a functions.php. Ma se c'è un codice che sto scrivendo, eseguirà una query personalizzata per recuperare informazioni e restituirà il risultato processato al modello (o alla parte modello), quindi appartiene a una funzione di supporto.
Proprio come WordPress ha i tag dei modelli o le funzioni dei modelli che possono essere chiamati in tutto un modello, come ad esempio il contenuto(), tratta le funzioni di supporto in modo simile: puoi chiamarle nei tuoi modelli e nei tuoi partial, ma si trovano nel loro file.
Dal momento che queste funzioni di aiuto non vivono functions.php, allora dovrebbero vivere nel loro file e quel file dovrebbe essere referenziato da qualche parte nella codebase del tema, giusto? Inoltre, è anche possibile che tu possa ulteriormente suddividere i tuoi helper in più file in base alla complessità del tuo tema.
A tal fine, raccomando di introdurre un inc o un include directory nel nucleo del tuo tema. Da lì, posiziona i tuoi file di supporto in quella directory e semplice include_once il file di supporto nella parte superiore del file delle funzioni e le funzioni saranno prontamente e facilmente accessibili per il resto del tema.
Infine, ci sono momenti in cui includeremo le librerie di terze parti nei nostri temi. In parole povere, si tratta di strumenti sviluppati da altri che sono liberamente disponibili per l'uso e la distribuzione e che ci rendono anche facili da usare sul lavoro degli altri.
Quindi dove dovrebbero vivere? Onestamente, questo dipende dal tipo di libreria con cui stai lavorando. Ad esempio, le librerie possono venire sotto forma di CSS, JavaScript o PHP. Come tale, dovrebbe esserci un posto per questo:
lib directory all'interno del tuo js directory. Questo indica che la cartella contiene librerie JavaScript.lib directory all'interno del tuo css directory. Di nuovo, questo indica che hai una libreria CSS.lib directory nella radice della directory del tema. Ciò indica che non è JavaScript o CSS e che contribuisce alla funzionalità del tema principale (che è in gran parte costituito da chiamate di funzione PHP, tag modello e così via).Naturalmente, ho visto anche alcuni sviluppatori creare un lib directory e quindi creare js, css, e php sottodirectory all'interno del lib directory. È un po 'un'inversione dei suggerimenti forniti sopra.
Non è una cattiva strategia; tuttavia, la ragione per cui non apprezzo questo approccio è perché diffonde i file JavaScript, CSS e PHP in più directory nel tema.
La creazione di una struttura di directory organizzata è solo una parte di essa. WordPress ha una gerarchia di modelli che richiede una certa convenzione di denominazione. Non segue logicamente che i nostri file personalizzati dovrebbero fare lo stesso?
Inoltre, che dire delle convenzioni di denominazione delle funzioni? Fanno eco dati o ritorno dati? Oltre a ciò, sappiamo come stiamo facendo le giuste chiamate alle funzioni API e che non stiamo usando funzionalità deprecate di WordPress?
Nel prossimo articolo, parleremo di tutto questo e degli strumenti che possiamo installare per aiutarci a evitare queste insidie. Discuteremo anche del loro funzionamento e del motivo per cui le convenzioni sulla denominazione delle funzioni sono importanti quando si creano temi.
Per ora, tuttavia, abbiamo trattato le strategie per l'organizzazione dei file che dovrebbero essere sufficienti per tenerti occupato fino alla pubblicazione del prossimo articolo della serie.
Come al solito, se hai qualcosa da aggiungere, per favore fallo nei commenti!
