I 12 errori peggiori che fanno gli sviluppatori WordPress avanzati

WordPress è un modo molto popolare per far funzionare rapidamente un sito. Tuttavia, nella loro fretta, molti sviluppatori finiscono per prendere decisioni orribili. Alcuni errori, come lasciare WP_DEBUG impostato su true , possono essere facili da fare. Altri, come raggruppare tutto il tuo JavaScript in un unico file, sono comuni come ingegneri pigri. Qualunque errore tu riesca a fare, continua a leggere per scoprire i 12 errori più comuni di WordPress che commettono sviluppatori nuovi e esperti. Se ti ritrovi a commettere uno di questi errori, non disperare. Ogni errore è un'opportunità per imparare.

1. Inserimento del codice JavaScript del tema WordPress in un file principale

Una volta, durante l'ottimizzazione della velocità della pagina per i siti Web di un cliente, ho notato che stavano utilizzando un tema premium che conteneva tutte le librerie che stavano utilizzando, incluso il codice personalizzato, in un unico file chiamato main.js , theme.js o custom.js . Questa pratica è negativa per i seguenti motivi:

1. Il file, nel tempo, può diventare davvero grande poiché il tema, essendo attivamente sviluppato, aumenterà in termini di funzionalità e talvolta vedrai file di dimensioni pari a 1 MB. Il file verrà caricato in tutto il sito anche se in alcune pagine è necessario solo il 10% del codice del file. Ciò renderà le pagine più lunghe per il download e più lente per il rendering, soprattutto se si tratta di codice di blocco del rendering all'interno della sezione head della pagina.
2. Rende più difficile la gestione del codice all'interno del file, poiché non è possibile utilizzare funzioni come wp_dequeue_script() per scaricare parte del codice in alcune pagine per migliorare la velocità della pagina o per prevenire un conflitto con altro codice JavaScript che potrebbe essere caricato da uno dei plugin attivi. Certo, il file può essere suddiviso in più file e messo in coda in WordPress, ma se in un momento successivo l'amministratore del sito Web esegue un aggiornamento del file main.js del tema, l'intero processo deve ricominciare da capo.

2. Utilizzo di nomi troppo comuni per variabili, funzioni, costanti o classi

Quando si sviluppa un plug-in, è meglio utilizzare una convenzione di denominazione che prevenga il conflitto di codice nel caso in cui ci siano altri plug-in che utilizzano lo stesso nome. Ecco perché molti sviluppatori antepongono alle loro variabili e nomi di funzione qualcosa di unico e correlato al plugin stesso. Oltre a eliminare i conflitti di codice, rende anche le cose più facili da trovare quando hai molti plugin abilitati.

Ci sono sviluppatori, d'altra parte, che preferiscono utilizzare gli spazi dei nomi PHP per incapsulare elementi e risolvere i due problemi che gli autori di librerie e applicazioni incontrano durante la creazione di elementi di codice riutilizzabili come classi o funzioni:

1. Nomi le collisioni tra il codice che creano e PHP interno o di terze parti, classi, funzioni o costanti
2. Possibilità di alias (o accorciare) Extra_Long_Names progettato per risolvere il primo problema o migliorare la leggibilità del codice sorgente. Questo è il mio preferito poiché sviluppo spesso temi o plugin con molto codice. Con questo, posso leggere e gestire facilmente il codice senza dovermi preoccupare molto di avere nomi univoci lunghi.

Consiglierei una buona comprensione degli spazi dei nomi prima di usarli poiché spesso possono essere usati nel modo sbagliato.

A seconda del progetto che prenderai a bordo, è probabile che dovrai attenerti allo stile di codifica esistente, a meno che il tuo lavoro non sia per lo più separato da quello esistente. Nel caso in cui devi estendere un plugin o un tema esistente che segue già gli standard di codifica PHP per WordPress, è meglio attenersi a loro per avere uno stile coerente in modo che il codice diventi pulito e facile da leggere. Si noti che alcune regole sono universalmente applicate per migliorare le prestazioni, ignorando lo stile di codifica. Ad esempio, è sempre meglio usare virgolette singole (anziché doppie) se non stai valutando nulla nella stringa. Inoltre, il codice deve essere rientrato per poter essere letto, specialmente se ha codice nidificato (ad esempio, IF s all'interno di IF s, nidificato FOREACH s e FOR s).

3. Non sfruttare le funzionalità di base di WordPress esistenti al suo vero potenziale

Poiché WordPress viene fornito con una suite di librerie regolarmente aggiornate che possono essere semplicemente richiamate nei nostri plugin e temi, è meglio utilizzare il più possibile le funzionalità di base esistenti. Ho visto temi e plugin di WordPress che avevano file nella loro directory delle risorse che erano già nei file core di WordPress (ad esempio, jQuery o Color Picker). Oltre al fatto che il pacchetto diventerà più grande e impiegherà più tempo a caricarsi sulla rete, devi anche assicurarti che tutte le librerie di terze parti siano regolarmente aggiornate, il che è solo un'altra cosa di cui occuparsi.

Sfrutta ciò che WordPress ha già da offrire, poiché le librerie sono già aggiornate dal team principale di sviluppo di WordPress e puoi avere un progetto leggero e di facile manutenzione. Eseguendo regolarmente aggiornamenti di WordPress, accedi a più funzionalità (che si tratti di un plug-in, di un tema o del core di WordPress stesso poiché la sua dashboard è costantemente migliorata) e rendi il sito Web più sicuro nel caso in cui vengano rilevate vulnerabilità nelle vecchie versioni di codice.

4. Non rendere il plug-in o il tema facile da modificare tramite azioni e filtri

Modificare direttamente un plugin o un tema WordPress è una cattiva idea, a meno che, ovviamente, tu non sia direttamente coinvolto nello sviluppo di quel pacchetto e contribuisca al suo codice. Se viene eseguito un aggiornamento automatico del plug-in o del tema, qualsiasi modifica diretta al pacchetto andrebbe persa e dovrai modificare nuovamente i file.

Ecco perché l'utilizzo di azioni e filtri, nonché la creazione di un tema figlio (che estende il tema principale) sono gli approcci più efficaci per modificare un tema poiché è possibile modificare la funzionalità esistente senza modificare il tema principale o il plug-in stesso. Inoltre, se offri un plug-in per il download gratuito su WordPress.org e in seguito desideri creare un'estensione premium che dipenda dal plug-in principale, dovresti sviluppare il plug-in gratuito in modo tale che essere facile da estendere e aggiungere estensioni premium.

5. Sviluppo con WP_DEBUG Impostato su false

Per impostazione predefinita, la costante WP_DEBUG è impostata su 'false' per evitare di stampare eventuali errori PHP, avvisi e avvisi. In un ambiente live, questa è una scelta consigliata in quanto mantiene i percorsi e gli script dei server privati ​​nascosti alla vista pubblica, il che è ottimo per motivi di sicurezza. Tuttavia, durante la fase di sviluppo, è meglio impostarlo su "true" poiché ci avviserà di eventuali errori nel nostro codice. Anche se gli errori non influiscono direttamente sulla funzionalità, spesso ti costringeranno a scrivere codice migliore ea sviluppare abitudini di codifica migliori. È successo a me. Ciò garantirà anche che il plugin o il tema che sviluppi non generi errori PHP in nessuna installazione di WordPress.

Anche se questo è qualcosa che fanno gli sviluppatori più esperti, succede, specialmente di fretta. Non importa quanto sia urgente il lavoro, gli sviluppatori dovrebbero sempre cercare di mantenere gli standard di codifica di WordPress, con un occhio ovvio alle migliori pratiche PHP.

6. Scrivere codice PHP senza considerare che la pagina potrebbe essere memorizzata nella cache un giorno

Questo è un errore PHP comune e, come il precedente, è relativamente facile da evitare se ci si attiene agli standard di codifica PHP.

Alcuni sviluppatori hanno l'abitudine di implementare frammenti di PHP in temi e plugin che sono validi solo se il codice PHP viene attivato continuamente. Ad esempio, una funzione PHP che risponda all'HTTP User Agent con determinate azioni dovrebbe essere intrapresa o meno (ad esempio, accodare script destinati solo agli utenti mobili).

Se il tuo client installa un plug-in che memorizza nella cache la pagina (ad esempio, W3 Total Cache o WP Rocket) senza attivare i condizionali nel tuo tema o plug-in, il tuo codice PHP sarà reso inutilizzabile. Se l'intenzione è quella di rendere le pagine reattive, allora questo dovrebbe essere fatto sul lato front-end attraverso media query e JavaScript. Quest'ultimo, solo se realmente richiesto. Idealmente, dovresti evitare di utilizzare JavaScript per rendere il tuo sito reattivo.

7. Non tenere traccia delle modifiche apportate in modo professionale tramite un sistema di controllo della versione come Git

I file con codice personalizzato, come un tema figlio o un plug-in personalizzato, dovrebbero idealmente essere sotto il controllo della versione. Git crea una registrazione di ciò che è stato modificato e consente agli sviluppatori di lavorare insieme sullo stesso progetto WordPress o di ripristinare facilmente una versione precedente ogni volta che qualcosa va storto con il sito web. Inoltre, i clienti possono utilizzare Git per tenere traccia di tutta la cronologia del lavoro eseguita da tutti gli sviluppatori che sono stati assunti per quel particolare progetto, soprattutto se si trattava di un sito Web WordPress personalizzato di grandi dimensioni a lungo termine.

Sebbene all'inizio possa essere intimidatorio, specialmente per gli sviluppatori junior, capire Git varrà la pena e un software Git GUI come SourceTree (uno dei miei preferiti) sarebbe semplicemente il modo in cui interagisci con i tuoi repository Git, rendendo l'intero curva di apprendimento più piacevole. Una volta compreso come funziona, prendi in considerazione la possibilità di controllare Git Best Practices and Tips di Toptal Developers che spiega in modo più approfondito alcuni modi di utilizzare Git.

8. Accodamento di file CSS e JavaScript quando non sono necessari

Avere molte richieste HTTP renderebbe il caricamento del sito Web più lento, avendo così un punteggio più basso in Google PageSpeed ​​che probabilmente influenzerebbe il ranking di ricerca. Potrebbe anche portare a errori JavaScript dovuti a conflitti tra i plugin. Ad esempio, potrebbero esserci due plugin che utilizzano una libreria jQuery comune, che potrebbe essere caricata due volte e potrebbe causare problemi. E in realtà, questo è l'esempio migliore, dal momento che jQuery viene molto comunemente caricato più volte su siti Web live. Questo probabilmente accade a causa di plugin o temi scritti male.

9. Utilizzo di file .php per generare codice CSS o JavaScript invece di file statici .css e .js

Ho visto temi e persino plugin di WordPress con file come style.php usati solo per generare codice CSS personalizzato e stamparlo. Cose come i colori, le dimensioni dei caratteri e la spaziatura intorno agli elementi sono stati impostati nelle impostazioni del tema e quindi salvati nel database. Quindi viene letto style.php (ad es. <link rel='stylesheet' type='text/css' href='css/style.php?ver=1' /> ) e genera il codice CSS in base alle impostazioni personalizzate che sono stati aggiornati nella dashboard.

Questa è davvero una cattiva pratica in termini di prestazioni di WordPress. Ecco i principali svantaggi che ne derivano:

1. Poiché il file CSS viene caricato all'interno del tag head (che è normale e la maggior parte di essi si carica in questo modo), c'è un problema di prestazioni che deriva da questo poiché il browser deve scaricare completamente il file prima di eseguire il rendering della pagina. Se l'ambiente WordPress è lento a causa di alcuni plugin, ciò ritarderà notevolmente il tempo di caricamento. Anche se vengono utilizzate tecniche di memorizzazione nella cache o viene caricata solo una parte dell'ambiente WordPress per recuperare i valori dal database. È meglio utilizzare invece un file .css statico.
2. Nel file PHP, il codice (regole CSS mescolate con variabili PHP e clausole condizionali) sarà più difficile da leggere dagli sviluppatori quando avranno bisogno di controllare qualcosa. Certo, il file può essere eseguito nel browser (anche se sono sicuro che quando verrà stampato, non sarà nemmeno indentato o bello da vedere) ma se hai una copia locale del progetto e sfoglia il codice del tema e hai bisogno trovare una sintassi CSS o JavaScript (nel caso in cui venga utilizzato script.php), renderebbe più difficile la leggibilità.

La soluzione: salvare qualsiasi CSS personalizzato al di fuori della directory del plug-in. Esempio: /wp-content/uploads/theme-name-custom-css/style-5.css . In questo modo, nel caso in cui il tema o il plug-in vengano aggiornati, il file personalizzato non andrà perso.

10. Non utilizzare l'architettura corretta (organizzazione del codice) per i plugin e i temi di WordPress

A seconda delle dimensioni e della natura del plug-in (ad esempio, un plug-in autonomo o un'estensione del plug-in che funziona solo se è attivato un plug-in principale come WooCommerce), è necessario impostare la corretta architettura e organizzazione del codice.

Se devi creare un plug-in WordPress monouso per un client e ha un'interazione limitata con il core, i temi e altri plug-in di WordPress, non è efficace progettare classi complesse a meno che tu non sia sicuro che il plug-in si espanderà considerevolmente in seguito su.

Se il plug-in sarà caratterizzato da un ricco contenuto di codice, l'utilizzo di un approccio di codifica OOP (Objected Oriented Programming) (con molte classi) avrebbe senso. Ad esempio, se hai molti codici brevi, puoi tenerli tutti in un file di classe separato come class.shortcodes.php o se sono presenti file CSS e JavaScript che devono essere caricati nella dashboard e nella vista front-end quindi una classe come class.scripts.php può essere utilizzata e accodare i file front-end all'interno di un metodo come enqueue_public_scripts() mentre si accodano i file destinati a essere caricati nell'area di amministrazione all'interno del metodo enqueue_admin_scripts() .

Invece di mescolare l'HTML con il codice PHP, è meglio tenerlo separato implementando il modello MVC nei plugin e nei temi. Un buon esempio è il plugin WooCommerce. Ha modelli per vari layout che possono anche essere facilmente sovrascritti tramite il tema o vari filtri solo perché la logica è separata dal design. Il modello contenente il layout HTML viene utilizzato principalmente per la stampa delle informazioni già elaborate. Avere codice HTML all'interno dei metodi PHP è solitamente una cattiva pratica (ci sono ovviamente delle eccezioni per piccoli bit di codice HTML), specialmente per un plugin che viene mantenuto da più di uno sviluppatore man mano che le dimensioni crescono.

Secondo il WordPress Plugin Handbook, sebbene ci siano una serie di possibili modelli di architettura, possono essere raggruppati in tre varianti:

• File di plugin singolo, contenente funzioni
• File di plug-in singolo, contenente una classe, un oggetto istanziato e, facoltativamente, funzioni
• File plug-in principale, quindi uno o più file di classe

11. Non prendere sul serio la sicurezza di WordPress durante la scrittura del codice

La sicurezza spesso non viene presa sul serio nello sviluppo di WordPress poiché molti sviluppatori alle prime armi si concentrano maggiormente sui risultati desiderati dal cliente. Tutto va bene fino a quando il sito Web del cliente non viene violato o il tuo plug-in pubblicato su WordPress.org non presenta una vulnerabilità, lasciando migliaia di siti Web interessati. Queste cose accadono a volte e anche il core di WordPress ha affrontato un discreto numero di vulnerabilità di sicurezza sin dai primi giorni del CMS. È nostra responsabilità renderlo il più sicuro possibile e, nel caso accadesse qualcosa, agire tempestivamente e assicurarci di rilasciare una patch solida e ben testata.

Alcuni dei più importanti suggerimenti per la sicurezza sono:

Vulnerabilità XSS: per evitare ciò, è necessario fare due cose: disinfettare i dati di input e disinfettare i dati di output. A seconda dei dati e del contesto in cui vengono utilizzati, in WordPress esistono diversi metodi per disinfettare il codice. Non ci si dovrebbe fidare dei dati di input, né dei dati che verranno stampati. Una funzione comune per la sanificazione dell'input dei dati è sanitize_text_field() . Verifica la presenza di caratteri UTF-8 non validi, converte i singoli caratteri < in entità HTML, rimuove tutti i tag, rimuove le interruzioni di riga, le tabulazioni e lo spazio bianco aggiuntivo e rimuove gli ottetti. Per quanto riguarda la stampa dei dati, un buon esempio per l'output dei collegamenti è la funzione esc_url() , che rifiuta gli URL non validi, elimina i caratteri non validi e rimuove i caratteri pericolosi.

Impedisci l'accesso diretto ai tuoi file: è possibile accedere direttamente ai file poiché la maggior parte degli host lo consente. Tuttavia, se ciò accade e il codice non è scritto correttamente per gestirlo, potrebbero essere stampati alcuni errori (ad es. funzioni mancanti o variabili non dichiarate) che conterrebbero informazioni preziose per potenziali aggressori. Uno snippet di codice comune che vedi spesso nei plugin e nei temi è:

 // Exit if accessed directly if ( ! defined( 'ABSPATH' ) ) exit;

Se la costante ABSPATH non è definita (che dovrebbe essere per qualsiasi installazione di WordPress), lo script uscirà e non stamperà nulla.

Usa Nonces: come indicato nella documentazione di WordPress, un nonce è un "numero utilizzato una volta" per proteggere gli URL e i moduli da determinati tipi di uso improprio, dannoso o altro.

Ad esempio, il seguente URL all'interno della dashboard verrebbe utilizzato per cestinare un post: http://example.com/wp-admin/post.php?post=123&action=trash —Quando si accede a questo URL, WordPress convaliderà le informazioni sui cookie di autenticazione e se hai la giusta autorizzazione (ad esempio, sei un amministratore con tutti i privilegi), quel post verrà eliminato.

Quello che un utente malintenzionato potrebbe fare è fare in modo che il tuo browser acceda a quell'URL a tua insaputa creando un collegamento su una pagina di terze parti come nell'esempio seguente: <img src="http://example.com/wp-admin/post.php?post=123&action=trash" /> Quando si effettua questa richiesta a WordPress, il browser allegherà automaticamente il cookie di autenticazione e WordPress considererà la richiesta valida.

Questo è quando si verifica un nonce poiché l'attaccante non sarà in grado di ottenere il valore nonce (generato per l'amministratore che è effettivamente connesso a WordPress) così facilmente. Il nuovo URL della richiesta sarebbe simile al seguente: http://example.com/wp-admin/post.php?post=123&action=trash&_wpnonce=b192fc4204

Senza un nonce valido, una risposta 403 Forbidden verrebbe inviata al browser da WordPress con il noto messaggio di errore: "Sei sicuro di volerlo fare?"

Sebbene la maggior parte delle persone non prenda sul serio la sicurezza di WordPress, pensando che il loro sito Web non sarebbe mai stato violato, fidandosi dell'hosting (che può essere utile, ma solo fino a un certo punto) e del fatto che hanno acquistato plugin/temi commerciali (che spesso portano supponendo che siano molto sicuri), dovremmo sempre eseguire test di penetrazione per i nostri siti Web al fine di identificare le vulnerabilità sfruttabili prima che qualsiasi hacker sia in grado di identificarle e sfruttarle.

Nota che un gran numero di hack là fuori non viene nemmeno fatto da una persona con l'intenzione di hackerare specificamente il tuo sito web. Spesso ci sono bot che scansionano automaticamente i siti WordPress in modo coerente e nel momento in cui viene rilevata una vulnerabilità nota, questa viene sfruttata e il server utilizzato per spamming, ottenere informazioni private dal database, posizionare collegamenti nascosti all'interno di determinate pagine del sito Web che porterebbe a tutti i tipi di siti Web ingannevoli (ad esempio, pornografia, droghe illecite). A volte, gli hack sono nascosti così bene che è necessaria una scansione adeguata del tuo sito Web e vedere la data in cui sono stati aggiornati file specifici per rilevare il codice violato. Ecco perché è bene anche reinstallare WordPress (sì, la stessa versione se hai l'ultima) in modo che tutti i file compromessi vengano sovrascritti dai file core originali di WordPress.

12. Utilizzo di funzioni e frammenti di codice di WordPress senza capirli

Spesso, quando gli sviluppatori si bloccano e trovano una soluzione in posti come StackOverflow, sono semplicemente contenti del fatto che sono riusciti a far funzionare qualcosa senza preoccuparsi di capire la logica dietro quel codice o se quel codice può essere modificato per caricare più velocemente o avere meno righe di codice.

Ho visto questa pratica così tante volte quando frammenti di codice vengono copiati all'interno di script PHP quando viene effettivamente utilizzato solo un terzo di quel codice.

Questo può avere alcuni svantaggi, tra cui:

1. Il codice non utilizza lo stesso stile del codice del progetto esistente. Sì, è comodo semplicemente copiare e incollare frammenti che funzionano fuori dagli schemi e, sebbene vadano bene per un piccolo progetto personale (un giorno potrebbe trasformarsi in un grande progetto, chissà), questa pratica spesso non è buona quando arriva al lavoro commerciale dove è necessario mantenere una coerenza di stile.
2. Sebbene il codice svolga il suo lavoro, potrebbe contenere funzioni inefficaci che non sono consigliate per l'attività che deve essere eseguita. Se il codice non è ottimizzato, questa pratica di "copia e incolla" può portare a un sito web lento e difficile da mantenere, soprattutto se più di uno snippet viene utilizzato in varie posizioni all'interno del progetto.
3. Il codice potrebbe non essere concesso in licenza per il riutilizzo e l'inclusione del codice nel progetto di un cliente può causare molti problemi legali.

Miglioramento costante

Tutti commettono errori e ogni errore è un'opportunità per migliorare te stesso. Come sviluppatori WordPress, il nostro settore si muove a un ritmo molto veloce e non c'è mai un "modo giusto" impostato per fare le cose. Tuttavia, più ti eserciti e impari, meglio diventerai.

Non sei d'accordo con qualcuno degli errori che ho indicato, o pensi che me ne sia perso uno? Fatemelo sapere nei commenti e ne discuteremo.