10 suggerimenti per semplificare la manutenzione di WordPress
Pubblicato: 2022-03-11In qualità di sviluppatore WordPress che ha lavorato su vari tipi di progetti, vorrei discutere alcuni dei punti deboli che ho riscontrato personalmente quando ho utilizzato un sito Web WordPress esistente per modifiche o correzioni di bug. I suggerimenti e i suggerimenti elencati in questo articolo hanno lo scopo di ridurre al minimo o addirittura eliminare questi dolori.
Perché è importante una corretta manutenzione di WordPress
La maggior parte delle volte, i siti Web non sono un affare "impostato una volta e da lasciare", e questo è vero per tutti i siti, non solo per quelli WordPress. Di tanto in tanto, dovrai occuparti di modifiche, aggiornamenti o correzioni di bug, di cui si occuperà il tuo sviluppatore preferito. Tuttavia, in alcuni casi, potresti dover fare affidamento su un numero di sviluppatori diversi per tutta la vita del tuo sito web.
In quest'ultimo caso, le cose spesso non vanno lisce per lo sviluppatore in arrivo, soprattutto se gli sviluppatori precedenti non hanno rispettato le migliori pratiche durante la gestione delle attività di manutenzione.
Vediamo alcuni dei punti più importanti da considerare nei tuoi futuri lavori di manutenzione sui progetti WordPress in modo da poter semplificare la vita del tuo prossimo sviluppatore e fargli amare lavorare sul tuo sito. Ovviamente, semplificare il lavoro del tuo sviluppatore è anche destinato a risparmiare alcune ore di lavoro e denaro nel processo, che è sempre un buon punto di forza per i tuoi potenziali clienti.
1. Esegui il backup!
Può sembrare troppo ovvio, ma la prima cosa è la prima! Devi eseguire il backup del tuo sito WordPress in modo corretto e regolare.
Questa è una delle cose più fondamentali da fare anche se al momento non stai apportando modifiche al tuo sito. Puoi farlo manualmente prendendo tutti i file più il dump del database e archiviandolo in un luogo sicuro, oppure puoi utilizzare un'opzione di backup automatico, per gentile concessione di un plug-in di backup di WordPress. Ci sono molti plugin gratuiti ea pagamento che puoi trovare nel repository dei plugin di WordPress. Puoi anche fare buon uso dell'opzione di backup a livello di server poiché la maggior parte dei provider di hosting offre opzioni di backup: questo è qualcosa che devi verificare con il tuo provider di hosting.
Con i backup regolari, hai la tranquillità che il tuo sito sarà di nuovo attivo e funzionante dopo un arresto anomalo o un errore. Potrebbe anche aiutare il tuo nuovo sviluppatore a risolvere i problemi senza troppi problemi, soprattutto se stai cercando di correggere un bug che sospetti possa essersi verificato durante la manutenzione in passato. I backup regolari dovrebbero aiutare i tuoi nuovi sviluppatori a identificare e risolvere i problemi persistenti, che si sono verificati mesi o anni prima che prendessero in carico il progetto.
2. Installa il tuo sito WordPress in locale
Non sono orgoglioso di ammettere di aver commesso questo errore io stesso nei miei primi giorni, e da allora ho notato che molti sviluppatori eseguono modifiche direttamente sul server remoto. A meno che tu non sia preoccupato di avere dati sensibili e tutti i file del sito alla mercé del tuo sviluppatore, dovresti evitare questo errore per sempre. È molto inefficiente andare avanti e indietro tra la macchina locale dello sviluppatore e il server dopo ogni modifica.
Anche se si tratta di una piccola modifica, come una piccola modifica per modificare un po' di testo sul tuo sito, lo sviluppatore deve passare al file/cartella corrispondente nel client FTP (se stai usando FTP per caricare i file), attendi i file da caricare e sperare che non ci siano occasionali errori di connessione FTP. Non dimentichiamo che alcuni siti WordPress hanno troppi dati per poterli spostare praticamente, senza sprecare troppo tempo e banda. E, dopo che tutto è stato caricato con successo, devono andare sul browser e aggiornare la pagina che, ancora una volta, dipende dalla velocità e dalle condizioni della rete/server in quel momento. Potrebbe sembrare che stiamo parlando di semplici minuti e secondi che possono essere salvati con ogni modifica, ma nel corso del tuo progetto, questi minuti potrebbero sommarsi a ore di lavoro non necessario.
Le modifiche sono molto più veloci se i tuoi sviluppatori hanno installato il sito sul loro computer locale: dovranno solo apportare le modifiche, aggiornare la pagina ed è fatta. Anche se vivono all'interno di una grotta senza alcuna connessione a Internet, possono comunque lavorare e caricare le modifiche in un secondo momento.
Cosa succede se hai dati sensibili di cui sei preoccupato o se ci sono motivi legali che ti impediscono di condividere tutti i tuoi dati con gli sviluppatori? In tal caso, puoi preparare alcuni dati fittizi appositamente per questo scopo. Puoi anche tenere da parte questi dati per la manutenzione futura.
3. Vai Git
Una delle cose migliori che accadono nel mondo dello sviluppo software è l'alba del controllo delle versioni online. Sollevo questo punto perché ci sono molti siti ancora in esecuzione con il tradizionale metodo cPanel/FTP per la gestione dei file. O non sanno quanto sia dolce il controllo della versione, oppure lo sanno ma sono riluttanti a implementarlo a causa dello sforzo di configurazione iniziale. Tuttavia, in realtà non è molto lavoro ed è tutt'altro che un compito difficile.
Il controllo della versione offre una serie di vantaggi quando si tratta di gestire i file, che include il monitoraggio delle modifiche di vari autori, il ripristino semplice delle modifiche, la possibilità di avere rami separati per ogni attività indipendente per assicurarsi che le modifiche di ciascuna attività non interferiscano con le altre.
Devi configurare Git su un server esterno, che il più delle volte è preinstallato dal tuo provider di hosting. Potrebbe essere necessario qualcuno con una certa esperienza sui server per avviare il repository e impostare il flusso di lavoro, di cui non parlerò qui perché va oltre lo scopo di questo articolo.
E per non parlare del fatto che in realtà non stai "git'ing" se non usi i rami! Crea almeno due rami per lo sviluppo e la produzione in modo che gli sviluppatori possano svolgere tutto il lavoro sul ramo di sviluppo, testare il sito e quindi, se tutto è a posto, inviare al ramo di produzione assicurandosi che nulla vada storto sul sito live.
4. Rimuovere file, codice e plug-in non necessari
È comune lasciare file e plugin che non sono più necessari. Questo diventa un problema una volta che i file si accumulano nel tempo durante il ciclo di vita del tuo sito web. Se il tuo sviluppatore non si è preoccupato di rimuovere i file indesiderati che sono stati aggiunti nel tempo, è difficile risalire alla provenienza e se è attualmente utilizzato da una parte del sito o meno. Ciò provoca un ulteriore mal di testa poiché il sito dovrebbe essere testato ancora una volta per assicurarsi che nulla si sia rotto dopo la rimozione di quegli elementi sospetti.
Questo può essere eliminato rimuovendo immediatamente i file indesiderati dallo sviluppatore corrispondente che ci ha lavorato. Puoi sottolineare questa pratica a tutti i tuoi sviluppatori.
Oltre ai file e ai plug-in PHP, i file multimediali inutilizzati possono anche riempire la cartella wp-content
nel tempo, il che potrebbe causare problemi ai tuoi sviluppatori quando lavorano con qualsiasi funzionalità relativa ai media. Puoi trovare vari plugin per semplificare questa attività. Un esempio è Media Cleaner.
Il plug-in presenta un cestino interno, che sposta temporaneamente i file lì per assicurarti che i file non siano effettivamente in uso; una volta controllati, puoi cestinarli in modo permanente. Assicurati di seguire il punto numero 1 in questo articolo, (es. backup) prima di pulire uno qualsiasi dei tuoi file.

5. Commentare
Probabilmente hai familiarità con il meme di programmazione che suona più o meno così: quando il codice è stato scritto, è stato compreso dall'autore che lo ha scritto, dai colleghi e da Dio. Dopo qualche tempo, solo l'autore e Dio sapevano cosa fa, e ora solo Dio sa cosa fa, a meno che l'autore non abbia aggiunto commenti appropriati!
Alcuni sviluppatori possono essere riluttanti o addirittura pigri quando si tratta di commentare, ma è una pratica indispensabile in un buon ambiente di sviluppo. Riduce i tempi di modifiche e correzioni di bug che altrimenti verranno spesi dai nuovi sviluppatori o anche dallo stesso sviluppatore per capire cosa fa un particolare blocco di codice.
I commenti devono essere aggiunti ogni volta che la funzione/classe o il blocco di codice non è qualcosa di ovvio, prendiamo ad esempio la seguente funzione:
function stripWhiteSapaces(str) { … Return str; }
Il nome della funzione sopra parla da sé e inoltre non è necessario che l'utente entri nella funzione per vedere come funziona, sta facendo solo un lavoro, eliminando gli spazi bianchi, il gioco è fatto! Quindi, in questo caso, i commenti potrebbero non essere necessari.
Ma, ad esempio, se esiste una funzione che accetta più parametri e restituisce un elenco filtrato di post, allora questo non è qualcosa di ovvio come quello precedente. Dovrebbero esserci commenti che descrivono i parametri e i loro tipi. Potrebbe anche essere necessario descrivere i blocchi di codice all'interno di questa funzione.
Per un rapido controllo, puoi prendere un file dal core di WordPress e vedere come lo hanno commentato gli esperti di WordPress. Oppure, per informazioni più dettagliate, puoi fare riferimento alla guida ufficiale di WordPress che lo illustra bene.
6. Linting
Linting è un'altra caratteristica interessante che applica le regole sul modo in cui scriviamo il codice e, a volte, corregge la formattazione del codice stesso, il che è sia interessante che utile. La maggior parte degli IDE in uso oggi sono dotati di opzioni di linting, che puoi ulteriormente migliorare o personalizzare aggiungendo varie configurazioni di linting.
Ad esempio, quando si usa Visual Studio Code come IDE, VS Code usa il linter PHP ufficiale ( php -l
) per la diagnostica del linguaggio PHP. Puoi configurare regole/restrizioni per ogni lingua separatamente (es. PHP, JavaScript, CSS ecc.). Puoi dare un'occhiata agli standard di codifica di WordPress per maggiori dettagli.
- https://make.wordpress.org/core/handbook/best-practices/coding-standards/php/
- https://make.wordpress.org/core/handbook/best-practices/coding-standards/javascript/
Una volta che hai una configurazione di linting, devi applicarla. Tutti i tuoi sviluppatori attuali e futuri devono integrare questa configurazione di linting nei loro IDE in modo che anche il loro codice aderisca alle stesse regole/restrizioni. Altrimenti, gran parte del tuo sforzo sarà vano.
7. Denominazione di variabili e file
Elaborare uno standard relativo al modo in cui le cose vengono denominate. Ciò include nomi di funzioni/classi, nomi di variabili, nomi di file e persino i nomi di supporti/immagini se fanno parte del modello perché aiuterà anche a capire a cosa servono.
Considera alcuni dei punti vitali:
- Evita nomi inequivocabili
- Tienilo corto quando possibile
- A volte è davvero utile aggiungere il "tipo" al nome del file. Ad esempio, se è un'icona, puoi avere qualcosa come BlackArrowIcon.png o se è una grande immagine di sfondo può essere qualcosa come FrontYellowBG.jpg. Oppure, se si tratta di un file di codice, a volte è davvero facile sapere cosa significa quel file quando si lavora con più file aperti in varie schede nell'IDE. Ad esempio, se esiste una classe con funzioni di supporto, sarà utile se si chiama HelperClass.php invece di Helper.php.
Per ulteriori informazioni, consulta la sezione Convenzioni di denominazione nella guida alle migliori pratiche di WordPress.
8. Debug di WordPress
Il debug può richiedere una notevole quantità di tempo e tende a richiedere una quota elevata della quantità totale di tempo di sviluppo, specialmente quando si tratta di modifiche o correzioni di bug. Ciò significa che devi notare se i tuoi sviluppatori lo stanno facendo nel modo più efficiente possibile. La maggior parte degli sviluppatori è incline a farlo var_dump
manualmente le variabili in qualche parte della pagina web che non è il metodo più efficiente. Ciò può anche causare mal di testa agli sviluppatori che si uniscono al progetto in un secondo momento, poiché finiranno con righe di codice spazzatura qua e là se il codice di debug non viene pulito correttamente al termine del lavoro.
Ci sono alcuni plugin per aiutare con questa attività di debug. Di seguito sono riportati alcuni esempi dei popolari plugin di debug per WordPress.
- Kint debugger
- Barra di debug
- Monitoraggio delle query
9. Avere un CSS migliore
Quando si tratta di sviluppo web, lo styling con CSS è una delle attività più basilari. Sfortunatamente, ciò significa che viene spesso trascurato e riceve meno attenzione di JS, PHP, ecc. Ma, che tu ci creda o no, i CSS possono causare un'enorme quantità di problemi se non vengono architettati correttamente quando si tenta di aggiungere o modificare qualcosa in futuro, a meno che il tuo sito non sia semplice e piccolo.
Se sei interessato a saperne di più sul motivo per cui questa tecnica di stile relativamente semplice è soggetta a problemi, puoi cercare su Google perché i CSS sono fastidiosi o puoi leggere di più sulle 5 cose più fastidiose con i CSS.
Ecco alcuni suggerimenti rapidi da parte mia senza molti dettagli:
- Applicare una buona pratica di denominazione. Usa una metodologia di denominazione come BEM (Block Element Modifier)
- Evita lo styling in linea. Usa invece fogli di stile esterni.
- Cerca di inventare modelli riutilizzabili comuni quando possibile, senza limitarti a ingombrare gli stili quando necessario.
- Suddividi gli stili in più file in base alle caratteristiche o alle aree del sito web. Se temi che un numero maggiore di file di stile possa influire sulle prestazioni di caricamento, puoi ovviare a questo problema utilizzando un buon plug-in di memorizzazione nella cache che consoliderà più file in un unico file.
- Utilizza preprocessori CSS come SASS, LESS e così via.
10. Ricevi feedback dagli attuali sviluppatori
Come ultimo pensiero, e per completare l'elenco, puoi ottenere feedback dai tuoi sviluppatori sui problemi che hanno dovuto affrontare lavorando sul tuo sito. Potrebbero essere in grado di dare qualche buon consiglio in quanto sono quelli che si sono sporcati le mani sul tuo sito. Potrebbero anche segnalare errori o codice sporco lasciato dagli sviluppatori precedenti.