Gli errori più comuni nello sviluppo di temi WordPress (e come risolverli)

Pubblicato: 2019-05-14

Inviare un tema alla directory dei temi di WordPress.org è un ottimo modo per condividere il tuo lavoro e contribuire alla community di WordPress. Attualmente, ci sono oltre 7000 temi nella directory, il più popolare dei quali supera le 300.000 installazioni attive. (Esclusi i temi di Twenty____ che sono pacchettizzati con WordPress e hanno un numero di installazioni nell'ordine di milioni.)

Prima di inviare il tuo tema alla directory, è importante comprendere prima il processo di revisione perché se il tuo tema non soddisfa questi requisiti può essere rifiutato sul posto.

I temi che presentano 3 o più problemi distinti possono essere chiusi come non approvati. Tuttavia, gli autori del tema possono inviare nuovamente il tema dopo aver corretto i problemi.

https://make.wordpress.org/themes/handbook/review/required/

I revisori sono dalla tua parte e vogliono che il tuo tema venga pubblicato, una volta che soddisfi gli standard richiesti. Se il tuo tema ha solo problemi minori che ne impediscono l'inclusione nella directory, il tuo revisore lavorerà con te per risolverli.

Sfortunatamente, se il tuo tema ha troppi problemi verrà chiuso come non approvato. Se decidi di risolvere i problemi, puoi caricare di nuovo il tema, ma si unirà in fondo alla coda.

Dalla mia esperienza nella revisione di oltre 100 temi sono stato in grado di identificare i problemi più comuni che impediscono l'approvazione dei temi. Condividendoli con te in questo articolo, spero di poterti aiutare a evitare di rimanere bloccato in coda o rifiutato.

Caricamento del tuo tema

Quando carichi un tema, questo si unisce alla coda per essere rivisto. In media ci vorranno due mesi prima che il tuo tema raggiunga la prima fila e riceva la sua prima recensione. Tutti i revisori sono volontari con un tempo limitato a disposizione per completare le revisioni. Una varietà di fattori può influenzare il tempo di attesa. Quando più persone si offrono volontarie per rivedere i temi, la coda si sposta rapidamente. Al contrario, quando vengono inviati temi con molti problemi, la coda rallenta.

Inviando un tema che soddisfi tutti i requisiti, il processo di revisione sarà molto più agevole e, in definitiva, il tuo tema sarà pubblicato prima. In questa guida, esploreremo i problemi più comuni che manterranno il tuo tema in coda e ne impediranno l'approvazione.

Nota: gli autori di temi che hanno una comprovata esperienza nell'invio di temi senza problemi possono presentare domanda per diventare "Autori attendibili".

Problemi di denominazione

Quando carichi un tema, il primo controllo che viene eseguito è vedere se il nome è già stato preso. Spesso ti verrà detto che il nome che hai scelto è già stato preso, anche se non puoi vedere un tema con quel nome nella directory.

Come potrebbe essere? Il motivo è che il test non sta controllando solo la directory, ma confrontando l'intero ecosistema di WordPress. Se un tema è stato rilasciato ovunque (Github, ThemeForest, ecc.) e ha oltre 50 installazioni attive, quel nome non sarà disponibile per l'uso.

Nota: se hai rilasciato il tuo tema altrove e hai accumulato oltre 50 installazioni, puoi comunque utilizzare quel nome nella directory.

Output senza escape

I revisori dei temi prendono molto sul serio la sicurezza, c'è persino una risorsa dedicata. Si potrebbe scrivere un intero articolo sulla scrittura di temi sicuri, ma in questa sezione esploreremo un aspetto: l'escape dell'output.

L'output senza escape mette a rischio gli utenti del tuo tema. Ecco un esempio di un valore senza escape ($titolo):

 $titolo = get_option('mio_titolo_personalizzato');
echo '<h2>' . $titolo. '</h2>';

Il problema con quanto sopra è che mentre sappiamo quale tipo di valore dovrebbe essere $titolo, una stringa, non abbiamo verificato se questo è il caso.

Se un hacker è riuscito a modificare il valore di 'my_custom_title' nel database, il tuo tema visualizzerà quel valore. Ciò presenta un rischio enorme in quanto potrebbero sostituire l'output previsto con Javascript inline:

 alert('Questo è pericoloso');

La soluzione è sfuggire a tutto l'output per garantire che includa solo il tipo di dati che ci aspettiamo.

Il nostro esempio potrebbe essere risolto in questo modo:

 $titolo = get_option('mio_titolo_personalizzato');
echo '<h2>' . esc_html($titolo) . '</h2>';

Lo svantaggio dell'utilizzo di esc_html è che rimuove tutti i tag HTML. Se $titolo include grassetto o corsivo, ad esempio:

 $title = 'Questo articolo è <strong>molto</strong> utile';
echo esc_html($titolo);

La parola "molto" non sarebbe in grassetto sul frontend; invece produrrebbe il codice <strong>molto</strong>.

Questo illustra perché è importante utilizzare le funzioni di escape corrette per il contesto. Se ci aspettassimo dell'HTML nell'output, sarebbe meglio usare wp_kses_post() o wp_kses() e impostare il parametro $allowed_html.

È necessario eseguire l'escape anche delle funzioni che generano l'output:

 <a href="<?php echo esc_url( get_permalink() ); ?>">

L'eccezione sono le funzioni principali di WordPress che includono "the_" nel loro nome, di solito sono già sfuggite.

 funzione the_permalink($post = 0) {
    /**
     * Filtra la visualizzazione del permalink per il post corrente.
     *
     * @dalla 1.5.0
     * @dal 4.4.0 Aggiunto il parametro `$post`.
     *
     * @param string $permalink Il permalink per il post corrente.
     * @param int|WP_Post $post ID post, oggetto WP_Post o 0. Predefinito 0.
     */
    echo esc_url(applica_filters('il_permalink', get_permalink($post), $post));
}

Testo intraducibile

Per essere accettati nella directory, tutti i temi devono essere 'pronti per la traduzione' al 100%. Ciò significa che ogni stringa di testo generata dal tuo tema deve essere traducibile.

WordPress ha già i sistemi e le funzionalità per gestire il processo di traduzione, devi solo assicurarti che le tue stringhe utilizzino le funzioni corrette.

Sebbene sia semplice da implementare, questo è spesso trascurato in quanto va contro il flusso di come le persone scrivono HTML.

Normalmente, potresti fare qualcosa del genere:

 <h1>404 - Non trovato</h1>

Per renderlo traducibile, devi aggiungere del PHP:

 // Le funzioni __ sono alla base della localizzazione.
<h1><?php echo __( '404', 'testo-dominio' ); ?>

// Le funzioni _e fanno eco al valore.
<h1><?php _e( '404', 'testo-dominio' ); ?>

// Esci e fai eco alla stringa.
<h1><?php esc_html_e( '404', 'testo-dominio' ); ?>

// localizzazione e variabili.
<h1><?php _n( 'Un post', '%s post', $count, 'testo-dominio'); ?>

Anche le stringhe emesse dalle funzioni devono essere pronte per la traduzione:

 // non pronto per la traduzione :-(
<?php next_posts_link( 'Voci meno recenti' ); ?>

// pronto per la traduzione :-)
<?php next_posts_link( esc_html__( 'Voci meno recenti', 'dominio-testo' ) ); ?>

Suggerimento: molti esempi di codice in codex.wordpress.org non utilizzano le funzioni di traduzione, quindi fai attenzione quando copi e incolli quelli.

Accodamento errato delle risorse

I file .css e .js utilizzati dal tuo tema devono essere accodati utilizzando le funzioni corrette: wp_enqueue_style() per CSS e wp_enqueue_script() per Javascript.

Un errore comune è codificare gli script e gli stili direttamente in <head> o prima di </body>. Ci sono due problemi in questo approccio:

1. Impossibile da rimuovere

Se un plug-in deve rimuovere una risorsa che hai caricato, non è possibile. Se avessi usato le funzioni di accodamento appropriate, potresti farlo in questo modo:

 /**
 * Elimina dalla coda il javascript del tema.
 *
 * Agganciato all'azione wp_enqueue_scripts, con priorità tardiva (100),
 * in modo che sia dopo che lo script è stato accodato.
 */
funzione wptavern_dequeue_script() {
   wp_dequeue_script( 'script di temi' );
}
add_action( 'wp_enqueue_scripts', 'wptavern_dequeue_script', 100 );

2. Caricamento duplicato

Se accodi una risorsa, ad esempio jQuery, e anche un plug-in la accoda, WordPress è abbastanza intelligente da caricarlo solo una volta.

 /**
 * Accoda jQuery
 *
 * jQuery verrà caricato solo una volta, nonostante le due code.
 * jQuery è incluso in WordPress, quindi non è necessario specificare un src. 
 */
funzione wptavern_enqueue_script() {
   wp_enqueue_script('jquery');
   wp_enqueue_script('jquery');
}
add_action( 'wp_enqueue_scripts', 'wptavern_enqueue_script' );

Se invece avessi codificato jQuery nel tuo <head>, WordPress non avrebbe modo di saperlo e verrebbe caricato due volte.

Funzionalità plug-in-territorio

L'ambito di un tema dovrebbe gestire solo il design e l'estetica di un sito Web, tutte le altre funzionalità dovrebbero essere gestite da WordPress stesso o dai plug-in.

Nel tentativo di aggiungere più valore ai loro temi, gli autori di temi spesso cercano di incorporare funzionalità extra, ad esempio controlli SEO o tipi di post personalizzati.

Il problema con il raggruppamento della funzionalità in un tema è che i dati non sono portabili. Prendi i controlli SEO come esempio, se l'utente cambia il tema, perde tutto il lavoro svolto per ottimizzare le proprie pagine. Al contrario, utilizzando un plug-in SEO, i dati e le funzionalità sono indipendenti dal tema e verranno mantenuti quando si cambia il tema.

Alcuni esempi di funzionalità del territorio dei plugin:

  • Analisi/Tracciamento
  • Controlli SEO
  • Moduli di contatto
  • codici brevi
  • Blocchi di Gutenberg

Suggerimento: se il tuo codice scrive nel database, è molto probabile che sia il territorio del plug-in. L'eccezione sarebbero le impostazioni relative al design (posizione della barra laterale, colori, ecc.).

Non prefissato

Il prefisso è un modo per garantire che il codice non si scontra con il codice dei plug-in. Il namespace in PHP è un modo migliore per ottenere lo stesso effetto. Tuttavia, alcuni utenti stanno ancora utilizzando vecchie versioni di PHP (5.2) che non supportano tale funzionalità.

Justin Tadlock ha condiviso un elenco di cose comuni che dovrebbero essere precedute:

  • Nomi delle funzioni PHP.
  • Nomi di classi PHP.
  • Variabili globali PHP.
  • Ganci azione/filtro.
  • Maniglie di script.
  • Maniglie di stile.
  • Nomi delle dimensioni dell'immagine.

Fonte: https://themereview.co/prefix-all-the-things/

 // esempio di funzione.
mio_prefisso_esempio();

// esempio di classe.
classe Mio_Prefisso_Esempio { … }

// esempio di azione e filtro.
fare_azione('mio_prefisso_azione');
apply_filters('my_prefix_filter', $valori);

// accoda esempi.
wp_enqueue_script( 'my_prefix_script', get_template_directory_uri() . '/js/custom-script.js' );
wp_enqueue_style( 'my_prefix_style', get_template_directory_uri() . '/css/styles.css' );

// esempio di dimensione dell'immagine.
add_image_size('my_prefix_image_size', 220, 180); // 220 pixel di larghezza per 180 pixel di altezza.

Eccezione: quando si accodano risorse di terze parti, non aggiungere un prefisso:

 // accodamento di uno script di terze parti (chosen.js).
 wp_enqueue_script('scelto', get_template_directory_uri() . '/js/scelto.js');

Problemi di licenza

Il tuo tema e tutti i suoi file devono essere compatibili al 100% con GPL. Ciò include immagini, librerie, script e caratteri.

Tutte le risorse di terze parti devono elencare la loro fonte e le informazioni sulla licenza.

Questo requisito può essere particolarmente complicato in quanto non tutte le licenze sono compatibili con la GPL. La licenza Unsplash ha solo una restrizione:

"Questa licenza non include il diritto di compilare foto da Unsplash per replicare un servizio simile o concorrente."

Quella restrizione, tuttavia, è sufficiente per renderlo non compatibile con GPL e, in quanto tale, non vedrai le immagini Unsplash incluse nei temi di wordpress.org.

Un elenco delle licenze compatibili con GPL è disponibile qui – https://www.gnu.org/licenses/license-list.html#GPLCompatibleLicenses

Recentemente, stocksnap.io è stata la fonte di immagini più comune nella directory poiché tutte le immagini elencate sono concesse in licenza come CC0 (compatibile con GPL).

Errori nelle schermate

I requisiti stabiliscono che il tuo screenshot dovrebbe essere una rappresentazione inedita del tuo tema che non assomigli a una pubblicità. Ciò significa che nessun lavoro di Photoshop, sovrapposizioni, bordi o effetti di fantasia.

Le immagini devono anche seguire gli stessi requisiti di licenza che abbiamo esplorato sopra.

tema nella foto: Blocksy

Bonus: usa uno standard di codifica

Un codice che sembra facile da leggere e da capire per te, può essere l'esatto opposto per un revisore che ha solo 10-15 minuti per controllare il tuo codice.

Sebbene non vi siano requisiti per gli standard di codifica, seguirne uno semplifica la lettura, la comprensione e la manutenzione del codice. Personalmente uso e raccomando gli "Standard di codifica di WordPress", anche se ce ne sono altri.

L'uso di PHP_CodeSniffer e il set di regole di WordPress nel tuo editor di codice può rendere molto più semplice l'adesione a uno standard: https://github.com/WordPress-Coding-Standards/WordPress-Coding-Standards

Conclusione

I requisiti del tema vengono creati pensando all'utente finale. Evita di commettere gli errori comuni che ho elencato sopra e il tuo tema verrà approvato in pochissimo tempo. Se desideri sperimentare il processo di revisione dall'altra parte, puoi persino diventare un revisore.