Share
Benvenuto nell'ultima parte di questa serie. Se sei appena arrivato, controlla i nostri due precedenti articoli. Abbiamo coperto finora i seguenti argomenti:
Suggerimenti per le migliori pratiche nello sviluppo di WordPress
Altri suggerimenti per le migliori pratiche nello sviluppo di WordPress
In questo articolo finale, parlerò di tre cose importanti che, sebbene non influenzino l'operazione del plugin, sono essenziali se si desidera fornire un plug-in di qualità.
La prima cosa che dovresti fare mentre scrivi un plugin è abilitare la modalità di debugcome raccomanda WordPress. In questo modo vedrai tutti gli errori, gli avvertimenti e i problemi.
Per abilitare la modalità di debug nella tua posizione semplice wp-config.php
Accentsconagua
define ('WP_DEBUG', true);Una volta ricaricato il sito, verranno visualizzati tutti gli avvisi e i problemi insieme ad altri messaggi come le note delle funzioni di WordPress deprecate. Se vuoi fornire un prodotto di qualità assicurati che usando il tuo plugin con la modalità debug abiliti o disabiliti il risultato nella stessa cosa (nessun errore, avviso o avviso).
Se vuoi invece salvare gli errori in un file e non visualizzarli nell'HTML, puoi farlo aggiungendo con WP_DEBUG le seguenti linee.
// tutti gli errori verranno salvati in un file di registro debug.log all'interno della directory / wp-content / define ('WP_DEBUG_LOG', true); // non visualizza errori in HTML define ('WP_DEBUG_DISPLAY', false);Un'altra impostazione di debug che utilizzo molto per salvare tutte le query del database in una matrice è la seguente:
define ('SAVEQUERIES', true);Di solito uso tutti questi (specialmente l'ultimo) con il plugin Debug Bar e la console Debug Bar. Se non li conosci, vai a prenderne una copia e inizia a eseguire il debug di plug-in e temi. Vedrai quanto è facile farlo.
Puoi anche controllare gli elenchi di plugin che uso per lo sviluppo in Wp Favs.
Documentare ogni aspetto del tuo plugin o tema renderà i tuoi utenti e la tua vita molto più semplici. Saranno in grado di far funzionare il plugin o il tema seguendo una guida o un video o una combinazione di entrambi e risparmierai molto tempo con i ticket di supporto e le e-mail senza fine.
Consiglio di dividere la documentazione in categorie o sezioni come la più importante:
Quindi, a seconda del tema o del plug-in, è possibile aggiungere il resto delle sezioni o delle categorie. Se controlli la pagina di documentazione degli inviti sociali di WordPress vedrai cosa intendo.
Se hai aggiunto filtri e ganci come ho detto nell'articolo precedente, è una buona idea creare una pagina di riferimento Filtro / Azioni che spieghi cosa fanno.
Le schede della guida sono un altro modo per fornire assistenza ai tuoi utenti direttamente sul tuo plug-in, invece di reindirizzarle al tuo sito web. Normalmente vengono utilizzati per fornire informazioni sullo schermo utilizzato in quel momento.
Ad esempio, su uno dei miei plugin chiamato Social PopUP, utilizzo una scheda di aiuto per spiegare gli shortcode disponibili.
Se stai usando una classe nel tuo plugin e vuoi aggiungere la scheda di aiuto in un tipo di messaggio personalizzato, potresti fare qualcosa del tipo:
/ ** * Inizializza il plug-in caricando gli script e gli stili di amministrazione e aggiungendo una * pagina delle impostazioni e un menu. * * @since 1.0.0 * / function __construct () [...] // Scheda Aiuto add_action ('load-post.php', array ($ this, 'my_admin_add_help_tab')); / ** * Aggiungi la scheda di aiuto al tipo di messaggio spucpt * @since 1.0 * @return void * / function my_admin_add_help_tab () $ screen = get_current_screen (); if ('spucpt'! = $ screen-> id) return; // Aggiungi my_help_tab se il tipo di messaggio è spucpt $ screen-> add_help_tab (array ('id' => 'my_help_tab', 'title' => __ ('Shortcode'), 'content' => 'Ciao contenuto va qui' ,)); È molto importante controllare che l'ID della schermata corrente corrisponda al tipo di post personalizzato o che la scheda della guida venga visualizzata ovunque.
Se invece hai aggiunto una pagina delle opzioni potresti usare il codice usato come esempio nel Codex.
add_help_tab (array ('id' => 'my_help_tab', 'title' => __ ('My Help Tab'), 'content' => ''. __ ('Il contenuto descrittivo che verrà mostrato nella scheda La mia guida è disponibile qui.'). '
',)); ?>Secondo me le schede di aiuto non sono molto visibili agli utenti, e la maggior parte di loro non sanno nemmeno che esistono, ma è una buona pratica includere alcune linee di aiuto all'interno del plugin stesso.
Internazionalizzazione anche conosciuta come i18n (ci sono 18 lettere tra l'io e il n) è la ciliegina sulla torta di un plugin o di un tema. Come sai già WordPress è usato da persone di tutto il mondo, quindi al momento di fornire un plugin o un tema dobbiamo essere sicuri che possano essere facilmente tradotti nella loro lingua nativa.
In primo luogo, dovremmo imparare il significato di queste due parole conosciute anche come i18n e i10n. L'internazionalizzazione si riferisce al processo di creazione di un plugin o tema traducibile mentre la localizzazione è fondamentalmente l'atto di farlo.
WordPress usa la famosa libreria gettext che spiegava in poche parole, possiamo dire che funziona così:
La prima cosa che devi fare è decidere a text-dominio che verrà utilizzato per avvolgere tutti i plugin o le traduzioni dei temi. Il dominio di testo dovrebbe corrispondere al tuo plugin slug.
Esistono diversi modi per creare le stringhe traducibili in base alla creazione di variabili, all'eco di qualcosa, ecc. Le funzioni più comuni sono __ () e _e () . Vediamo alcuni esempi di seguito:
// creazione di una variabile $ hello = __ ('Ciao, sono una stringa traducibile', 'mio-dominio-testo'); eco ''. __ ('Ciao, sono una stringa traducibile', 'mio-dominio-testo'). '
'; // per fare un eco puoi usare _e ('Hello, Im a translatable string', 'my-text-domain'); // Quando hai delle variabili nella stringa che fai: printf (__ ('Abbiamo eliminato% d posts.', 'Mio-text-domain'), $ count); // Oppure più variabili printf (__ ('Il tuo nome è% 1 $ s e il tuo cognome è% 2 $ s.', 'Mio-dominio-testo'), $ nome, $ cognome);Un'altra funzione interessante che puoi usare è _n () che è usato per i plurali. Questa funzione richiede 4 argomenti:
Tornando all'esempio precedente, i plurali assomiglieranno a qualcosa:
printf (_n ('Abbiamo eliminato un post.', 'Abbiamo eliminato% d post.', $ count, 'my-text-domain'), $ count);Se per caso hai bisogno di tradurre stringhe nel tuo JavaScript, puoi passare tutte le stringhe usando il comando wp_localize_script () funzione che abbiamo discusso sul secondo articolo di questa serie.
wp_enqueue_script ('script-handle', ...); wp_localize_script ('script-handle', 'objectL10n', array ('alert' => __ ('Questo è un messaggio di avviso', 'my-text-domain'), 'submit' => __ ('Submit', ' dominio my-text '),));Abbiamo già aggiunto tutta la stringa traducibile attorno al nostro plug-in e ora è ora di abilitarlo. Per farlo fai semplicemente:
function myplugin_init () $ plugin_dir = basename (dirname (__FILE__)); load_plugin_textdomain ('my-text-domain', false, $ plugin_dir); add_action ('plugins_loaded', 'myplugin_init');Questo pezzo di codice proverà a caricare dalla radice del tuo plugin un file MO chiamato my-text-domain-Locale.momento . A seconda delle impostazioni della tua lingua in wp-config.php, la parte locale verrà sostituita con il tuo codice lingua. Per esempio se il mio wp-config.php è configurato come:
define ('WPLANG', 'es_ES');Il file che sta per essere caricato è my-text-domain-es_ES.mo. Per i temi è abbastanza simile, devi solo includere nel tuo functions.php il seguente:
load_theme_textdomain ('my_theme_textdomain');Il differenza principale è che questa funzione cercherà Locale .mo invece di my_theme_textdomain- locale .mo come abbiamo visto nell'esempio precedente.
Puoi leggere ulteriori informazioni su l18n nel codice WordPress.
Siamo alla fine di questa serie e spero che vi sia piaciuto leggerlo tanto quanto l'ho scritto io. Come ho detto prima, ho scritto questa serie pensando alle mie origini come sviluppatore. Ho cercato di raccogliere tutte le informazioni che ritengo importanti per fare un buon plugin, riassumendo in larga scala tutto ciò che è già spiegato nel Codex. Anche se probabilmente ho tralasciato molto, penso che sia sufficiente avere solide basi.
Mi piacerebbe vederti condividere i tuoi pensieri, suggerimenti e idee per un solido sviluppo nei commenti.
