Nel primo post di questa serie, abbiamo discusso le ragioni per cui i plugin di WordPress dovrebbero essere trattati più come progetti software più grandi (ma spesso non lo sono) e abbiamo fatto un caso per usare codice ben organizzato nel tentativo di rendere i nostri progetti plugin più mantenibili . Tutto ciò è stato fatto nel contesto dello sviluppo di un widget di WordPress.
Il fatto è che i widget non sono l'unico tipo di plugin che possono essere sviluppati per WordPress. L'applicazione supporta anche plugin che estendono la sua funzionalità attraverso l'uso di ganci situati in tutta l'applicazione. In quanto tale, i widget non sono l'unico tipo di plug-in che potrebbe trarre vantaggio da un boilerplate.
In questo tutorial, definiremo quali sono esattamente gli hook di WordPress, come funzionano e perché sono utili. Successivamente, daremo un'occhiata al mio WordPress Widget Boilerplate e come sfruttarlo in nuovi progetti attraverso il contesto di un'applicazione di esempio.
Prima di sviluppare plugin, è importante capire il modello di WordPress per l'aggancio nell'applicazione e il diverso tra azioni e filtri.
Abbastanza facile, giusto? Inoltre, WordPress ha una solida documentazione per aggiungere azioni [1] e aggiungere filtri [2]. Puoi ottenere molto di più sui plugin nell'API Plugin [3] nel codice WordPress [4].
Se leggi l'articolo precedente, hai già familiarità con l'API Widget. È preciso in quanto richiede un costruttore e non meno di tre funzioni per ottenere qualcosa di lavoro. Poiché i plug-in hanno la flessibilità di aggancio in una varietà di punti nel processo di WordPress, l'API Plugin è un po 'meno strutturata. Fortunatamente, questo non significa che non siamo in grado di creare una qualche forma di piastra termica da cui creare i nostri plugin.
Dopotutto, sono ancora costituiti da alcune funzionalità comuni:
Simile al nostro WordPress Widget Boilerplate, possiamo impostare la nostra directory template per assomigliare a questo:
Sembra familiare, non è vero? L'aspetto più importante del Plugin Boilerplate non sono i dettagli della struttura delle directory (anche se esamineremo un po 'in futuro) ma l'organizzazione del codice del plugin principale stesso.
I plug-in possono essere sviluppati utilizzando una manciata di funzioni o avvolgendo ciascuna funzione in una classe in un approccio orientato agli oggetti. Sono un fan di quest'ultimo e il mio boilerplate lo rappresenta. Ecco la definizione del plugin:
init_plugin_constants (); load_plugin_textdomain (PLUGIN_LOCALE, false, dirname (plugin_basename (__ FILE__)). '/ lang'); / * * TODO: * Definisci la funzionalità personalizzata per il tuo plugin. Il primo parametro delle chiamate * add_action / add_filter sono gli hook in cui il tuo codice dovrebbe sparare. * * Il secondo parametro è il nome della funzione che si trova all'interno di questa classe. Vedi gli stub * più avanti nel file. * * Per ulteriori informazioni: * http://codex.wordpress.org/Plugin_API#Hooks.2C_Actions_and_Filters * / add_action ('TODO', array ($ this, 'action_method_name')); add_filter ('TODO', array ($ this, 'filter_method_name')); // end if // end constructor / * -------------------------------------- ------ * * Funzioni principali * --------------------------------------- ------ * / / ** * Nota: le azioni sono punti nell'esecuzione di una pagina o processo * ciclo di vita che WordPress attiva. * / function action_method_name () // TODO definisce qui il tuo metodo di azione // end action_method_name / ** * Nota: i filtri sono punti di esecuzione in cui WordPress modifica i dati * prima di salvarli o inviarli al browser. * / function filter_method_name () // TODO definisce il tuo metodo di filtro qui // end filter_method_name / * ---------------------------- ---------------- * * Funzioni private * ----------------------------- ---------------- * / / ** * Inizializza le costanti utilizzate per praticità in tutto il * plug-in. * / private init_plugin_constants () / * TODO * * Fornisce l'identificativo univoco per il plugin utilizzato in * localizzando le stringhe utilizzate in tutto. * * Ad esempio: wordpress-widget-boilerplate-locale. * / if (! defined ('PLUGIN_LOCALE')) define ('PLUGIN_LOCALE', 'plugin-name-locale'); // end if / * TODO * * Definisci questo come il nome del tuo plugin. Questo è ciò che mostra * nell'area Widget di WordPress. * * Ad esempio: WordPress Widget Boilerplate. * / if (! defined ('PLUGIN_NAME')) define ('PLUGIN_NAME', 'Plugin Name'); // end if / * TODO * * questo è lo slug del plugin utilizzato per inizializzarlo con * l'API di WordPress. * Questa dovrebbe essere anche la * directory in cui risiede il tuo plugin. Usa trattini. * * Ad esempio: wordpress-widget-boilerplate * / if (! Defined ('PLUGIN_SLUG')) define ('PLUGIN_SLUG', 'plugin-name-slug'); // end if // end init_plugin_constants / ** * Funzione di supporto per la registrazione e il caricamento di script e stili. * * @name L'ID da registrare con WordPress * @file_path Il percorso del file attuale * @is_script Argomento facoltativo per se il file_path in ingresso è un file di origine JavaScript. * / private function load_file ($ name, $ file_path, $ is_script = false) $ url = WP_PLUGIN_URL. $ File_path; $ file = WP_PLUGIN_DIR. $ File_path; if (file_exists ($ file)) if ($ is_script) wp_register_script ($ name, $ url); wp_enqueue_script ($ name); else wp_register_style ($ name, $ url); wp_enqueue_style ($ name); // end if // end if // end _load_file // end class // TODO: aggiorna la chiamata di instantiation del tuo plug-in al nome dato alla nuova definizione di classe TODO (); ?>
La maggior parte degli IDE ha una funzione che elenca tutti i TODO in circolazione, quindi li inserisco nel codice per individuare facilmente ciò che deve essere fatto durante lo sviluppo. Nota che ci sono tre aree principali di codice:
Nota che lo sviluppo dei plugin devia dallo sviluppo dei widget in quanto non ci sono più funzioni previste. In realtà, hai solo bisogno di un costruttore. Da lì, qualsiasi funzione definita all'interno delle chiamate add_action o add_filter e la tua responsabilità di implementare.
Ha senso? Diamo un'occhiata all'utilizzo di questo piatto caldaia in un semplice esempio.
WordPress offre ganci per quasi il punto di esecuzione che puoi immaginare. In questo esempio, ci collegheremo al processo di post-rendering per introdurre un messaggio personalizzato. Il fatto è che vogliamo solo visualizzare il messaggio nel contesto di un lettore RSS.
In primo luogo, i requisiti:
Sulla base di questo, non sembra che avremo bisogno di usare JavaScript, CSS o markup per creare il nostro plugin in modo da poter ridurre il nostro pluginplanplanotest al codice del plugin di base e ai file di localizzazione:
A questo punto, possiamo iniziare a stubare lo standard con un nome e le costanti del plugin:
/ ** * Inizializza le costanti utilizzate per praticità in tutto il * plug-in. * / private init_plugin_constants () if (! defined ('PLUGIN_LOCALE')) define ('PLUGIN_LOCALE', 'rss-note-locale'); // end if if (! defined ('PLUGIN_NAME')) define ('PLUGIN_NAME', 'RSS Note'); // end if if (! defined ('PLUGIN_SLUG')) define ('PLUGIN_SLUG', 'rss-note-slug'); // end if // end init_plugin_constants
Successivamente, dobbiamo considerare quale tipo di hook è richiesto per manipolare il contenuto. Ricordiamo che stiamo cercando di aggiungere qualcosa al content proir per renderlo nel browser, avremo bisogno di un filtro. Da qui, possiamo spegnere il costruttore:
/ ** * Inizializza il plug-in impostando la localizzazione, i filtri e le funzioni di amministrazione. * / function __construct () // Definisci i constnati usati nel plugin $ this-> init_plugin_constants (); load_plugin_textdomain (PLUGIN_LOCALE, false, dirname (plugin_basename (__ FILE__)). '/ lang'); // aggiungi la nota sia all'estratto che al feed principale add_filter ('the_content', array ($ this, 'display_rss_note')); add_filter ('the_excerpt_rss', array ($ this, 'display_rss_note')); // costruttore finale
Si noti che la funzione utilizza due filtri: uno per the_content [5] e uno per the_excerpt_rss [6]. Lo stiamo facendo perché alcuni utenti scelgono di pubblicare solo un estratto del loro blog piuttosto che tutti i contenuti e vogliamo essere certi di catturare entrambi i casi.
Quindi, implementiamo effettivamente la definizione della funzione che aggiungerà il messaggio al resto del post:
/ ** * Appone un breve messaggio al piè di pagina di ogni post visualizzato in un lettore RSS * che ricorda agli utenti di visitare il tuo sito. * / public function display_rss_note ($ content) if (is_feed ()) $ content. = ''; $ content. = ''; // end if return $ content; // end display_rss_note'; $ content. = __ ('Grazie per aver letto! Assicurati di recuperare il resto dei miei post su', PLUGIN_LOCALE); $ content. = ''; $ content. = get_bloginfo ('name'); $ content. = '!'; $ content. = '
'; $ content. = '
Nota che la funzione accetta un parametro riferito alla variabile $ content. WordPress stesso sta trasmettendo questi dati nella funzione. Per questi particolari filtri, abbiamo a che fare con il contenuto di un post del blog, quindi qualsiasi cosa aggiungiamo ad esso deve essere concatenato in modo che venga aggiunto alla fine di esso.
Questo messaggio che stiamo aggiungendo dice semplicemente "Grazie per aver letto! Assicurati di recuperare il resto dei miei post su [Nome blog]!" attraverso l'uso della funzione get_bloginfo () [7]? Certo, puoi aggiornarlo per leggere quello che vuoi. Infine, tieni presente che lo abbiamo concluso in un condizionale che controlla la funzione is_feed () [8]. Questo è importante perché vogliamo che questo codice si attivi solo se il contenuto viene inviato tramite un feed RSS.
Questo è tutto - non troppo male, giusto? Puoi scaricare la versione completa del codice sorgente funzionante (incluso il README associato) per questo plugin su GitHub o direttamente qui da Wptuts. Il boilerplate è anche disponibile su GitHub.
Il punto di questa serie non era solo quello di aiutare a fornire una guida introduttiva all'API WordPress Plugin, ma anche di fornire un case e un boilerplate per rendere molto più facile il trattamento e la manutenzione dei plugin WordPress come qualsiasi altro progetto software.