I 10 errori più comuni che fanno gli sviluppatori di WordPress

Siamo solo umani e uno dei tratti dell'essere umani è che commettiamo errori. D'altra parte, ci stiamo anche correggendo da soli, nel senso che tendiamo a imparare dai nostri errori e, si spera, siamo in grado di evitare di fare gli stessi due volte. Molti degli errori che ho commesso nel regno di WordPress derivano dal tentativo di risparmiare tempo nell'implementazione delle soluzioni. Tuttavia, questi in genere alzerebbero la testa lungo la strada quando sorgerebbero problemi a seguito di questo approccio. Fare errori è inevitabile. Tuttavia, imparare dalle sviste di altre persone (e dalla tua ovviamente!) è una strada che dovresti intraprendere in modo proattivo.

Errore comune n. 1: mantenere il debug disattivato

Perché dovrei usare il debug quando il mio codice funziona correttamente? Il debug è una funzionalità integrata in WordPress che causerà la visualizzazione di tutti gli errori PHP, avvisi e avvisi (su funzioni obsolete, ecc.). Quando il debug è disattivato, potrebbero essere generati avvisi o avvisi importanti che non vediamo mai, ma che potrebbero causare problemi in seguito se non li gestiamo in tempo. Vogliamo che il nostro codice funzioni bene con tutti gli altri elementi del nostro sito. Quindi, quando aggiungi un nuovo codice personalizzato a WordPress, dovresti sempre svolgere il tuo lavoro di sviluppo con il debug attivato (ma assicurati di disattivarlo prima di distribuire il sito alla produzione!).

Per abilitare questa funzione, dovrai modificare il file wp-config.php nella directory principale della tua installazione di WordPress. Ecco uno snippet di un file tipico:

 // Enable debugging define('WP_DEBUG', true); // Log all errors to a text file located at /wp-content/debug.log define('WP_DEBUG_LOG', true); // Don't display error messages write them to the log file /wp-content/debug.log define('WP_DEBUG_DISPLAY', false); // Ensure all PHP errors are written to the log file and not displayed on screen @ini_set('display_errors', 0);

Questo non è un elenco esaustivo delle opzioni di configurazione che possono essere utilizzate, ma questa configurazione suggerita dovrebbe essere sufficiente per la maggior parte delle esigenze di debug.

Errore comune n. 2: aggiungere script e stili utilizzando wp_head Hook

Cosa c'è di sbagliato nell'aggiungere gli script nel mio modello di intestazione? WordPress include già una pletora di script popolari. Tuttavia, molti sviluppatori aggiungeranno script aggiuntivi usando l'hook wp_head . Ciò può comportare il caricamento più volte dello stesso script, ma di una versione diversa.

L'accodamento qui viene in soccorso, che è il modo amichevole di WordPress per aggiungere script e stili al nostro sito Web. Usiamo l'accodamento per prevenire conflitti di plugin e gestire eventuali dipendenze che uno script potrebbe avere. Ciò si ottiene utilizzando le funzioni integrate wp_enqueue_script o wp_enqueue_style per accodare rispettivamente script e stili. La principale differenza tra le due funzioni è che con wp_enqueue_script abbiamo un parametro aggiuntivo che ci permette di spostare lo script nel footer della pagina.

 wp_register_script( $handle, $src, $deps = array(), $ver = false, $in_footer = false ) wp_enqueue_script( $handle, $src = false, $deps = array(), $ver = false, $in_footer = false ) wp_register_style( $handle, $src, $deps = array(), $ver = false, $media = 'all' ) wp_enqueue_style( $handle, $src = false, $deps = array(), $ver = false, $media = 'all' )

Se lo script non è necessario per eseguire il rendering del contenuto above the fold, possiamo spostarlo in sicurezza nel footer per assicurarci che il contenuto above the fold venga caricato rapidamente. È buona norma registrare lo script prima di accodarlo, poiché ciò consente ad altri di annullare la registrazione dello script tramite l'handle nei propri plug-in, senza modificare il codice principale del plug-in. In aggiunta a ciò, se l'handle di uno script registrato è elencato nell'array di dipendenze di un altro script che è stato accodato, tale script verrà caricato automaticamente prima di caricare lo script accodato evidenziato.

Errore comune n. 3: evitare temi figlio e modificare i file core di WordPress

Crea sempre un tema figlio se prevedi di modificare un tema. Alcuni sviluppatori apporteranno modifiche ai file del tema principale solo per scoprire dopo un aggiornamento al tema che le loro modifiche sono state sovrascritte e perse per sempre.

Per creare un tema figlio, inserisci un file style.css in una sottodirectory della cartella del tema figlio, con il seguente contenuto:

 /* Theme Name: Twenty Sixteen Child Theme URI: http://example.com/twenty-fifteen-child/ Description: Twenty Fifteen Child Theme Author: John Doe Author URI: http://example.com Template: twentysixteen Version: 1.0.0 License: GNU General Public License v2 or later License URI: http://www.gnu.org/licenses/gpl-2.0.html Tags: light, dark, two-columns, right-sidebar, responsive-layout, accessibility-ready Text Domain: twenty-sixteen-child */

L'esempio sopra crea un tema figlio basato sul tema WordPress predefinito, Twenty Sixteen . La riga più importante di questo codice è quella contenente la parola "Modello" che deve corrispondere al nome della directory del tema genitore da cui stai clonando il figlio.

Gli stessi principi si applicano ai file core di WordPress: non prendere la strada facile modificando i file core. Fai quel ulteriore sforzo utilizzando le funzioni e i filtri collegabili di WordPress per evitare che le modifiche vengano sovrascritte dopo un aggiornamento di WordPress. Le funzioni collegabili ti consentono di ignorare alcune funzioni principali, ma questo metodo viene gradualmente eliminato e sostituito con filtri. I filtri ottengono lo stesso risultato finale e vengono inseriti alla fine delle funzioni di WordPress per consentire la modifica del loro output. Un trucco è sempre quello di avvolgere le tue funzioni con if ( !function_exists() ) quando si utilizzano funzioni collegabili poiché più plugin che tentano di sovrascrivere la stessa funzione collegabile senza questo wrapper produrranno un errore irreversibile.

Errore comune n. 4: valori di hardcoding

Spesso sembra più veloce codificare semplicemente un valore (come un URL) da qualche parte nel codice, ma il tempo speso lungo la strada per eseguire il debug e correggere i problemi che ne derivano è molto maggiore. Utilizzando la funzione corrispondente per generare dinamicamente l'output desiderato, semplifichiamo notevolmente la successiva manutenzione e debug del nostro codice. Ad esempio, se esegui la migrazione del tuo sito da un ambiente di test a quello di produzione con URL codificati, all'improvviso noterai che il tuo sito non funziona. Questo è il motivo per cui dovremmo utilizzare funzioni, come quella elencata di seguito, per generare percorsi e collegamenti di file:

 // Get child theme directory uri stylesheet_directory_uri(); // Get parent theme directory get_template_directory_uri(); // Retrieves url for the current site site_url();

Un altro cattivo esempio di hardcoding è quando si scrivono query personalizzate. Ad esempio, come misura di sicurezza, cambiamo il prefisso predefinito del datatable di WordPress da wp_ a qualcosa di un po' più unico, come wp743_ . Le nostre query falliranno se spostiamo l'installazione di WordPress, poiché i prefissi delle tabelle possono cambiare tra gli ambienti. Per evitare che ciò accada, possiamo fare riferimento alle proprietà della tabella della classe wpdb :

 global $wpdb; $user_count = $wpdb->get_var( "SELECT COUNT(*) FROM $wpdb->users" );

Nota come non sto usando il valore wp_users per il nome della tabella, ma invece sto lasciando che WordPress lo risolva. L'uso di queste proprietà per generare i nomi delle tabelle aiuterà a garantire la restituzione dei risultati corretti.

Errore comune n. 5: non impedire che il tuo sito venga indicizzato

Perché non voglio che i motori di ricerca indicizzino il mio sito? L'indicizzazione è buona, giusto? Bene, quando crei un sito web, non vuoi che i motori di ricerca indicizzino il tuo sito fino a quando non hai finito di costruirlo e hai stabilito una struttura di permalink. Inoltre, se disponi di un server di staging in cui testare gli aggiornamenti del sito, non desideri che motori di ricerca come Google indicizzino queste pagine duplicate. Quando sono presenti più contenuti indistinguibili, è difficile per i motori di ricerca decidere quale versione sia più pertinente per una query di ricerca. I motori di ricerca in questi casi penalizzeranno i siti con contenuti duplicati e di conseguenza il tuo sito ne risentirà nelle classifiche di ricerca.

Come mostrato di seguito, le impostazioni di lettura di WordPress hanno una casella di controllo che dice "Scoraggiate i motori di ricerca dall'indicizzare questo sito", sebbene questo abbia un'importante nota sottostante che afferma che "Spetta ai motori di ricerca onorare questa richiesta".

Tieni presente che i motori di ricerca spesso non soddisfano questa richiesta. Pertanto, se vuoi impedire in modo affidabile ai motori di ricerca di indicizzare il tuo sito, modifica il tuo file .htaccess e inserisci la seguente riga:

 Header set X-Robots-Tag "noindex, nofollow"

Errore comune n. 6: non verificare se un plug-in è attivo

Perché dovrei controllare se esiste una funzione plug-in se il mio plug-in è sempre attivo? Di sicuro, il 99% delle volte il tuo plugin sarà attivo. Tuttavia, che dire di quell'1% delle volte in cui per qualche motivo è stato disattivato? Se e quando ciò si verifica, il tuo sito Web probabilmente visualizzerà alcuni brutti errori PHP. Per evitare ciò, possiamo verificare se il plugin è attivo prima di richiamarne le funzioni. Se la funzione del plugin viene chiamata tramite il front-end, dobbiamo includere la libreria plugin.php per poter chiamare la funzione is_plugin_active() :

 include_once( ABSPATH . 'wp-admin/includes/plugin.php' ); if ( is_plugin_active( 'plugin-folder/plugin-main-file.php' ) ) { // Run plugin code }

Questa tecnica è generalmente abbastanza affidabile. Tuttavia, potrebbero esserci casi in cui l'autore ha cambiato il nome della directory principale del plugin. Un metodo più robusto sarebbe quello di verificare l'esistenza di una classe nel plugin:

 if( class_exists( 'WooCommerce' ) ) { // The plugin WooCommerce is turned on }

È meno probabile che gli autori cambino il nome della classe di un plug-in, quindi in genere consiglierei di utilizzare questo metodo.

Errore comune n. 7: caricare troppe risorse

Perché dovremmo essere selettivi nel caricare le risorse dei plugin per le pagine? Non vi è alcun motivo valido per caricare stili e script per un plug-in se tale plug-in non viene utilizzato nella pagina in cui l'utente è passato. Caricando i file plug-in solo quando necessario, possiamo ridurre il tempo di caricamento della pagina, il che si tradurrà in una migliore esperienza per l'utente finale. Prendi, ad esempio, un sito WooCommerce, in cui desideriamo che il plug-in venga caricato solo nelle nostre pagine di shopping. In tal caso, possiamo rimuovere selettivamente tutti i file dal caricamento su tutte le pagine degli altri siti per ridurre il gonfiore. Possiamo aggiungere il seguente codice al tema o al file functions.php del plugin:

 function load_woo_scripts_styles(){ if( function_exists( 'is_woocommerce' ) ){ // Only load styles/scripts on Woocommerce pages if(! is_woocommerce() && ! is_cart() && ! is_checkout() ) { // Dequeue scripts. wp_dequeue_script('woocommerce'); wp_dequeue_script('wc-add-to-cart'); wp_dequeue_script('wc-cart-fragments'); // Dequeue styles. wp_dequeue_style('woocommerce-general'); wp_dequeue_style('woocommerce-layout'); wp_dequeue_style('woocommerce-smallscreen'); } } } add_action( 'wp_enqueue_scripts', 'load_woo_scripts_styles');

Gli script possono essere rimossi con la funzione wp_dequeue_script($handle) tramite l'handle con cui sono stati registrati. Allo stesso modo, wp_dequeue_style($handle) impedirà il caricamento dei fogli di stile. Tuttavia, se questo è troppo difficile da implementare per te, puoi installare Plugin Organizer che offre la possibilità di caricare plug-in in modo selettivo in base a determinati criteri, come un tipo di post o il nome di una pagina. È una buona idea disabilitare tutti i plug-in di memorizzazione nella cache, come W3Cache, che potresti aver attivato per impedirti di dover aggiornare costantemente la cache per riflettere eventuali modifiche apportate.

Errore comune n. 8: mantenere la barra di amministrazione

Non posso semplicemente lasciare la barra di amministrazione di WordPress visibile a tutti? Ebbene sì, potresti consentire ai tuoi utenti di accedere alle pagine di amministrazione. Tuttavia, queste pagine molto spesso non si integrano visivamente con il tema scelto e non forniscono un'integrazione perfetta. Se vuoi che il tuo sito abbia un aspetto professionale, devi disabilitare la barra di amministrazione e fornire una tua pagina di gestione dell'account front-end:

 add_action('after_setup_theme', 'remove_admin_bar'); function remove_admin_bar() { if (!current_user_can('administrator') && !is_admin()) { show_admin_bar(false); } }

Il codice sopra, quando copiato nel file functions.php del tuo tema mostrerà solo la barra di amministrazione per gli amministratori del sito. Puoi aggiungere qualsiasi ruolo utente o funzionalità di WordPress nella funzione current_user_can($capability) per escludere gli utenti dalla visualizzazione della barra di amministrazione.

Errore comune n. 9: non utilizzare il filtro GetText

Posso usare CSS o JavaScript per cambiare l'etichetta di un pulsante, cosa c'è che non va? Ebbene sì, puoi. Tuttavia, stai aggiungendo codice superfluo e tempo extra per il rendering del pulsante, quando puoi invece utilizzare uno dei filtri più pratici in WordPress, chiamato gettext . In combinazione con il textdomain di testo di un plug-in, un identificatore univoco che assicura che WordPress possa distinguere tra tutte le traduzioni caricate, possiamo utilizzare il filtro gettext per modificare il testo prima che la pagina venga visualizzata. Se cerchi il codice sorgente per la funzione load_plugin_textdomain($domain) , ti darà il nome di dominio di cui abbiamo bisogno per sovrascrivere il testo in questione. Qualsiasi plug-in affidabile garantirà che il textdomain di testo per un plug-in sia impostato all'inizializzazione del plug-in. Se si desidera modificare del testo in un tema, cercare la riga di codice load_theme_textdomain($domain) . Usando ancora una volta WooCommerce come esempio, possiamo modificare il testo che appare per l'intestazione "Prodotti correlati". Inserisci il seguente codice nel file functions.php del tuo tema:

 function translate_string( $translated_text, $untranslated_text, $domain ) { if ( $translated_text == 'Related Products') { $translated_text = __( 'Other Great Products', 'woocommerce' ); } return $translated_text; } add_filter( 'gettext', 'translate_string', 15, 3 );

Questo hook di filtro viene applicato al testo tradotto dalle funzioni di internazionalizzazione __() e _e() , purché il textdomain di testo sia impostato tramite le funzioni sopra menzionate.

 _e( 'Related Products', 'woocommerce' );

Cerca nei tuoi plugin queste funzioni di internazionalizzazione per vedere quali altre stringhe puoi personalizzare.

Errore comune n. 10: mantenere i permalink predefiniti

Per impostazione predefinita, WordPress utilizza una stringa di query con l'ID del post per restituire il contenuto specificato. Tuttavia, questo non è facile da usare e gli utenti possono rimuovere parti pertinenti dell'URL durante la copia. Ancora più importante, questi permalink predefiniti non utilizzano una struttura adatta ai motori di ricerca. L'abilitazione di quelli che chiamiamo permalink "carini" assicurerà che i nostri URL contengano parole chiave pertinenti dal titolo del post per migliorare le prestazioni nelle classifiche dei motori di ricerca. Può essere un compito piuttosto scoraggiante dover modificare in modo retrospettivo i tuoi permalink, soprattutto se il tuo sito è in esecuzione da un periodo di tempo significativo e hai centinaia di post già indicizzati dai motori di ricerca. Quindi, dopo aver installato WordPress, assicurati di modificare prontamente la struttura dei permalink in qualcosa di un po' più adatto ai motori di ricerca rispetto a un semplice ID post. In genere uso il nome del post per la maggior parte dei siti che creo, ma puoi personalizzare il permalink in qualsiasi formato ti piaccia usando i tag di struttura del permalink disponibili.

Conclusione

Questo articolo non è affatto un elenco esaustivo degli errori commessi dagli sviluppatori di WordPress. Se c'è una cosa che dovresti togliere da questo articolo, però, è che non dovresti mai prendere scorciatoie (e questo è vero in qualsiasi piattaforma di sviluppo, non solo in WordPress!). Il tempo risparmiato ora da cattive pratiche di programmazione tornerà a perseguitarti in seguito. Sentiti libero di condividere con noi alcuni errori che hai commesso in passato e, soprattutto, qualsiasi lezione appresa, lasciando un commento qui sotto.