Scrittura di widget WordPress mantenibili parte 2 di 2

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.


Informazioni su hook, azioni e filtri

Prima di sviluppare plugin, è importante capire il modello di WordPress per l'aggancio nell'applicazione e il diverso tra azioni e filtri.

  • Gli hook sono aree nell'applicazione principale di WordPress che ti permettono di registrare il tuo codice per l'esecuzione. In poche parole, il tuo plugin si registra con WordPress in un punto specifico di esecuzione. Quando WordPress raggiunge quel punto di esecuzione (sia nel salvataggio delle informazioni, nel rendering delle informazioni o in qualche altro punto), spara il tuo codice.
  • Le azioni sono un tipo di hook che WordPress mette a disposizione per sfruttare ogni volta che si verifica un evento specifico durante il ciclo di vita dell'applicazione. Alcuni di questi punti includono ogni volta che viene attivato un tema, ogni volta che viene salvato un post o quando vengono sottoposti a rendering i fogli di stile. In generale, se stai cercando di inserire qualche tipo di funzionalità personalizzata in qualsiasi punto del ciclo di vita di WordPress, è probabile che sia disponibile un hook di azione.
  • I filtri sono un tipo di hook che WordPress mette a disposizione per manipolare i dati prima di inviarli al database o inviarli al rendering nel browser. In poche parole, WordPress passerà il contenuto alla tua funzione e poi continuerà con il suo processo con qualunque cosa tu ritorni. Se stai cercando di manipolare i dati prima di salvarli o vederli, l'opzione migliore è usare il filtro.

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].


Un Plugin Boilerplate

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:

  • Codice plug-in principale
  • Fogli di stile
  • JavaScript
  • File di localizzazione
  • markup
  • immagini

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.

Lo scheletro del plugin

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:

  1. Costruttore. Questa funzione è responsabile della definizione di tutte le costanti utilizzate nel codice, specificando eventuali file di localizzazione e registrando tutte le azioni e i filtri con WordPress.
  2. Le Funzioni principali sono le definizioni di funzioni effettive registrate nel costruttore che vengono attivate dopo l'esecuzione di WordPress.
  3. Le funzioni di supporto si riferiscono a funzioni che utilizzo che aiutano nell'esecuzione estrapolando funzionalità comuni (come la registrazione di JavaScript e fogli di stile).

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.


Un esempio di lavoro con il feed RSS del tuo blog

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:

  • Mostra un messaggio al piè di pagina di ogni post
  • Il messaggio dovrebbe apparire solo nei lettori RSS
  • Il messaggio dovrebbe contenere un link al sito web del post

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. = '

'; $ content. = __ ('Grazie per aver letto! Assicurati di recuperare il resto dei miei post su', PLUGIN_LOCALE); $ content. = ''; $ content. = get_bloginfo ('name'); $ content. = '!'; $ content. = '

'; $ content. = '
'; // end if return $ content; // end display_rss_note

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.

  1. http://codex.wordpress.org/Function_Reference/add_action
  2. http://codex.wordpress.org/Function_Reference/add_filter
  3. http://codex.wordpress.org/Plugin_API
  4. http://codex.wordpress.org/Main_Page
  5. http://codex.wordpress.org/Function_Reference/the_content
  6. http://codex.wordpress.org/Template_Tags/the_excerpt_rss
  7. http://codex.wordpress.org/Function_Reference/is_feed
  8. http://codex.wordpress.org/Function_Reference/get_bloginfo