Share
Parliamo molto su questo sito di consigli e trucchi per ottenere ciò che vuoi da WordPress ... ma oggi faremo un passo indietro rispetto alle cose tecniche per esaminare alcune pratiche, cattive abitudini e errori di codifica che sarebbero meglio lasciato nel nostro passato. Quindi, perdona il titolo post pesante (haha!), Parliamo di parlare di 5 pratiche sorprendentemente comuni che sono difetti sulla piattaforma.
Due delle cose più belle su come lavorare su WordPress Themes è il fatto che arriviamo a destinazione in un ambiente incredibilmente flessibile (cioè, il web) e abbiamo solida documentazione per aiutarci a guidarci attraverso il processo (cioè il Codice WordPress).
Dopo tutto, se il tema funziona, il codice pulito e gestibile è importante?
Ma esiste anche un pericolo nello sviluppo del tema: possiamo completamente rinunciare alle migliori pratiche per lavorare con il web e ignorare completamente la documentazione. Nello specifico, non c'è nulla che ci costringa a scrivere codice pulito e manutenibile. Dopotutto, se il tema funziona, il codice pulito e gestibile è importante? Inoltre, perché seguire lo sforzo di seguire le migliori pratiche di WordPress se il tema sembra funzionare correttamente?
Argomenti deboli, giusto? Non lo so - più ho lavorato nello spazio WordPress, più mi sono sorpreso di quanto il codice cattivo esista realmente. Come tale, ho pensato che sarebbe stato divertente delineare cinque peccati cardinali dello sviluppo di temi WordPress.
Come con la maggior parte dei linguaggi di programmazione, dei framework o delle librerie, WordPress include un'enorme quantità di documentazione. Il codice WordPress è probabilmente la migliore risorsa che gli sviluppatori hanno per lavorare con WordPress. Dopo tutto, fornisce la documentazione per la maggior parte dell'applicazione.
Ma il Codice WordPress spesso va ben oltre la documentazione standard - oltre a fornire nomi e parametri di funzioni, il Codex fornisce ricchi esempi su come utilizzare molte delle funzioni API. Dopo aver letto un determinato articolo, ti sarebbe difficile non trovare un chiaro esempio di come la funzione in questione.
Oltre all'API, il Codex presenta anche una varietà di altri articoli relativi allo sviluppo:
Ogni volta che sto lavorando su un tema o su un plugin e raggiungo un punto in cui penso di dover scrivere una funzione personalizzata per ottenere qualcosa, cercherò prima il codice. La maggior parte delle volte è già disponibile una funzione che aiuta con quello di cui ho bisogno.
Ogni serio sviluppatore WordPress dovrebbe utilizzare regolarmente il Codex quando si lavora su qualsiasi progetto di sviluppo relativo a WordPress. Ignorarlo può spesso portare a soluzioni creative, non testate e instabili che possono causare più danni in negativo che benefici.
Qualche anno fa, se mi chiedessi le mie idee su come localizzare un tema WordPress, avrei detto che sarebbe dipeso dal marketing che scegli come target. Cioè, se pensi che il pubblico userà una lingua diversa dalla tua, sicuramente lo farà; altrimenti, non c'è niente di sbagliato nel lasciare il tema tradotto nella tua lingua.
Avanzano di pochi anni e WordPress 'alimenta milioni di siti su Internet. I siti di tutto il mondo utilizzano l'applicazione per gestire i contenuti del proprio sito. Inoltre, sta diventando sempre più comune per gli sviluppatori integrare i loro guadagni o persino guadagnarsi da vivere lavorando con WordPress.
Poiché WordPress è stato adottato così ampiamente e perché Internet ha reso il mondo così piatto, il mercato per ogni tema non è limitato a una sola lingua. Inoltre, WordPress rende così incredibilmente facile localizzare il tuo tema e richiede un piccolo sforzo in più, che ora sostengo che localizzare il tuo tema non sia più opzionale.
Per la maggior parte, devi capire tre cose:
Oltre a questo, c'è un piccolo overhead in più che viene fornito con la localizzazione di un tema; tuttavia, ti consiglio di dare un'occhiata all'articolo di WordPress di traduzione nel Codex. Delinea le tre cose sopra e approfondisce ciascuna.
Gli sviluppatori parlano molto dell'organizzazione del codice e della manutenibilità. Personalmente, penso che sia molto più semplice dare un servizio a questi principi piuttosto che seguirli, ma sono importanti.
Il fatto è che sembrano diversi per ogni tipo di progetto. Alcune applicazioni sono scritte in una sola lingua e girano su un desktop, alcune applicazioni usano due lingue e girano su un dispositivo mobile, altri progetti, come i temi WordPress, possono essere utilizzati ovunque da tre (HTML, CSS e PHP) a quattro ( attraverso JavaScript) lingue. Inoltre, alcuni componenti del tema vengono eseguiti sul lato client, alcuni vengono eseguiti sul lato server, alcune comunità direttamente con WordPress e altri comunicano direttamente con il database.
Dire che c'è possibilità di sacrificare la manutenibilità è un eufemismo.
Ma non deve essere problematico in quanto vi sono determinati standard suggeriti da WordPress per l'organizzazione dei file del tema. Nello specifico, il Codex descrive in dettaglio come organizzare i file modello PHP, i fogli di stile, i sorgenti JavaScript e le immagini.
Certo, ci vuole un po 'di più per organizzare i tuoi file piuttosto che fare abbastanza per "farlo funzionare", ma i dividendi pagano nel tempo mentre inizi a lavorare sulla prossima versione del tuo tema o quando più sviluppatori iniziano a lavorare sullo stesso codebase.
Ovviamente, l'organizzazione dei file è solo una parte del processo di sviluppo che riguarda l'organizzazione e la manutenibilità. Successivamente, dobbiamo concentrarci su come effettivamente scriviamo il codice che risiede nei nostri file.
Dopotutto, non solo dovremmo voler fornire anche file ben organizzati, ma anche codice conforme allo standard facile da seguire. Ancora una volta, il codice WordPress fornisce un set standard per le principali lingue che contribuiscono alla base di codice di un tema:
Molto da elaborare, eh? Il fatto è che passare del tempo a familiarizzare con tutto quanto sopra paga i dividendi nel tempo. L'applicazione di questi standard all'inizio dello sviluppo è esponenzialmente più economica rispetto al dover rifattorizzare un tema o un plug-in esistente.
Inoltre, risulta contribuire a rendere il codice migliore alla comunità.
Dopo che un tema è stato sviluppato ed è pronto per il rilascio, dovresti fare almeno una prova. Cioè, dovresti verificare che i vari stili dei dati dei post siano formattati correttamente, che il tuo tema non stia usando funzioni deprecate, o che stia usando in modo errato alcune funzioni.
Fortunatamente, il Codice fornisce una serie di suggerimenti e strumenti per aiutare a rendere questo processo molto più semplice.
Naturalmente, è possibile eseguire ulteriori test, ad esempio test su più browser, conformità agli standard HTML / CSS e così via. Il Codex delinea ancora più suggerimenti di test nell'articolo sul processo di test tematico.
Dicono che spesso impari dai tuoi errori e sarò il primo ad ammettere che durante il mio tempo con WordPress, ho rotto ognuno di questi. Ma, come il resto della comunità di sviluppo, impari e inizi a costruire progetti migliori con esperienza.
Questo è il primo di questo tipo di articoli di "cultura WordPress" che pubblicheremo sul sito ... quindi condividi le tue esperienze qui sotto - o meglio ancora, scrivici a lungo e noi lo pubblicheremo se è fantastico!
Detto questo, questo non è certo l'elenco definitivo e sono sicuro che c'è altro da aggiungere (non abbiamo nemmeno toccato l'hacking del nucleo, molestando il database, o elementi di hard coding che dovrebbero avere opzioni). Lascia i tuoi animaletti nei commenti!
Quali sono alcune delle pratiche più fastidiose, dannose o insostenibili che hai incontrato?
Accentsconagua