WordPress » Tutorials » Sviluppo » PHP » Internet

Sulla struttura ad oggetti di un Plugin WordPress

venerdì 24 aprile, 2009

Se ci affidassimo al semplice esempio hellodolly.php fornito da WordPress, o anche alla stessa documentazione ufficiale, non arriveremmo mai alla stesura di un buon ed efficiente plugin. Vogliamo qui analizzare una possibile struttura, quindi uno scheletro, in grado di essere utilizzato più volte.

Le basi

Prima di tutto dobbiamo capire come e quando un plugin WordPress viene caricato nel sistema. Quando si attiva un plugin dall’amministrazione, il file che contiene il codice principale, riconosciuto dalle classiche linee di commento:

1
2
3
4
5
6
7
8
/*
Plugin Name: Mio Plugin
Plugin URI: http://wordpress.org/extend/plugins/mioplugin/
Description: Descrizione mio plugin
Version: 1.0.0
Author: Giovambattista Fazioli
Author URI: http://labs.saidmade.com
*/

viene caricato sia se ci troviamo nel front-end sia se ci troviamo nell’amministrazione (back-end):

Schema di caricamento di un Plugin WordPress

Questo comportamento è di per sé corretto e, probabilmente, in molti casi non è preso in considerazione dallo sviluppatore. Inoltre alcuni plugin hanno una struttura (ad esempio non hanno impostazioni e quindi non necessitano di una amministrazione) tale da rendere inutile soffermarsi su tale punto.
Tuttavia va considerato che alcuni plugin hanno una consistente amministrazione, cioè portano con se molto codice usato solo nel back-end di WordPress. In questi casi se non si prendono le opportune precauzioni si rischia di far caricare al front-end, cioè la parte visibile a navigatori, codice completamente inutile che non fa altro che appesantire il caricamento del blog.

Possibili conflitti: spazio dei nomi

Dal punto precedente si deduce un altro fatto importante; tutti i plugin WordPress vengono caricati nella stessa area di funzionamento, il ché si traduce nella spiacevole conseguenza che se due diversi plugin hanno una funzione (una variabile o una costante) identificata dallo stesso nome, questi andranno in conflitto tra loro!

L’ideale, quindi, sarebbe quello di riuscire a:

  • Separare il caricamento del codice per il front-end ed il back-end
  • Proteggere lo “spazio dei nomi” per evitare possibili conflitti con altri plugin caricati nel sistema

Front-end o Back-end?

Il modo più semplice per determinare se si è in amministrazione (back-end) è quello di chiamare la funzione is_admin():

1
2
if( is_admin() ) // includi il codice lato back-end
else // includi codice lato front-end

In pratica, schematizzando, possiamo realizzare:

Font-end, Back-end

ovvero:

1
2
3
4
5
if( is_admin() ) {
    require_once( 'admin.php' );
} else {
    require_once( 'client.php' );
}

Uso delle classi per proteggere lo spazio dei nomi

Per impedire sovrapposizioni spiacevoli un buon modo è quello di “avvolgere” le nostre funzioni e le nostre variabili in opportuni contenitori: gli oggetti. Definendo una classe abbiamo più possibilità di proteggere i nomi delle nostre funzioni ottenendo come ulteriore vantaggio il possibile riutilizzo del codice in futuri plugin. Questa tecnica permette di avere due plugin diversi, quindi due oggetti diversi, con il medesimo metodo (funzione). Il conflitto viene eliminato grazie alla nomenclatura diversa delle classi e delle loro istanze.

Plugin Sketch

Detto tutto ciò vediamo come realizzare uno Sketch (che potete trovare sempre aggiornato nel repository Google Code di Saidmade), uno scheletro, da poter riutilizzare ogniqualvolta abbiamo bisogno di scrivere un plugin. Prima di tutto nella nuova organizzazione ad oggetti rendiamoci conto che se è vero che esiste una separazione “netta” tra la parte di back-end e quella front-end è vero anche che alcune “funzioni” sono e saranno condivise! Questo, a livello di programmazione ad oggetti, ci indica la strada da percorrerre in una possibile organizzazione del codice. Ad esempio, l’intuito ci suggerisce che la creazione di una classe “madre”, cioè una classe da cui deriveranno le nostre classi “client” (front-end) e “admin” (back-end), sarebbe una buona cosa!
Questa classe “madre” conterrà tutte le proprietà (variabili) e metodi (funzioni) condivise dagli ambienti front-end e back-end:

wpplugin

Avremo quindi la nostra classe “madre” e due classi specifiche per il front-end e il back-end:

1
2
3
wp-sketch_class.php   // classe madre
wp-sketch_admin.php   // classe per il back-end
wp-sketch_client.php  // classe per il front-end

Il file principale (wp-sketch.php) non farà altro che includere nel modo opportuno queste classi ed istanziarle a dovere:

1
2
3
4
5
6
7
8
9
10
require_once( 'wp-sketch_class.php');                       // load the core class

if( is_admin() ) {                                          // check admin
    require_once( 'wp-sketch_admin.php' );                  // load admin class
    //
    $wp_sketch_admin = new WPSKETCH_ADMIN();                // create object
} else {
    require_once( 'wp-sketch_client.php');                  // load client front-end class
    $wp_sketch_client = new WPSKETCH_CLIENT();              // create object
}

In questo “contesto” bisogna solo stare attenti a definire in modo univoco le variabili che contengono le istanze delle classi ($wp_sketch_admin e $wp_sketch_client) e i nomi delle classi stesse (WPSKETCH_ADMIN e WPSKETCH_CLIENT), ma non i metodi e le proprietà in esse presenti.

Entrambe le classi WPSKETCH_ADMIN e WPSKETCH_CLIENT sono “sottoclassi” (figli) di WPSKETCH_CLASS, definita nel file wp-sketch_class.php. Questa, come accennato sopra, dovrà contenere solo gli elementi condivisi (variabili e funzioni) in quanto viene sempre caricata a prescindere se ci troviamo nel back-end o nel front-end.

Concludendo…

È possibile scaricare l’intero scheletro dal repository Google Code di Saidmade. In questo troverete anche un file wp-sketch_functions.php, utilizzato per evitare che le chiamate alle funzioni nel front-end si traducano un una chiamata oggetto->metodo(). Di fatto è un file opzionale non sempre necessario.

Possibili sviluppi di quest’approccio sono la sempre migliore identificazione della sezione su cui stiamo operando e WordPress, in questo senso, offre innumerevoli azioni di ottimizzazione da compiere, nell’ottica di caricare solo il codice necessario e quando davvero serve. Ulteiori esempi su questo versante li vedremo prossimamente.

Post correlati

Questo articolo ti è stato utile?: Per nientePocoAbbastanzaMoltoMoltissimo
Loading ... Loading ...

Tags: , , , , ,

8 commenti a: “Sulla struttura ad oggetti di un Plugin WordPress”

  1. 24 apr, 2009 Saidmade Labs» creazione siti web, sviluppo applicazioni web, marketing virale:

    [...] Una tecnica per scrivere velocemente un plugin WordPress può essere quella di prepararsi uno scheletro (sketch) da cui partire. Le specifiche WordPress, infatti, portano spesso ad avere plugin strutturalmente molto simili tra loro, addirittura, sono i nomi delle funzioni e il loro contenuto a cambiare. Tuttavia, nella preparazione di uno scheletro, bisogna tenere a mente di non duplicare costanti o nomi di funzioni usate da altri (anche nostri) plugin, pena ottenere un errore.Tutti i plugin attivi condividono la stessa area di funzionamento. Così se un plugin ha una funzione che si chiama abc_normalize() nessun altro plugin può avere una funzione con un nome identico.Caso remoto? Coincidenza? Anche se a prima vista sembra una questione del tutto trascurabile, quando accade è oltremodo fastidiosa, soprattutto per l’utente finale che si ritrova nell’impossibilità di usare un plugin. Inoltre nella definizione delle costanti (tipo TABLE_NAME, WP_MAIN_PATH, ecc…) è molto più frequente ottenere duplicati. Per ulteriori dettagli: Sulla struttura ad oggetti di un Plugin WordPress [...]

  2. 25 apr, 2009 Il meglio della settimana #15 | BigThink:

    [...] Sulla struttura ad oggetti di un Plugin WordPress Come strutturare le classi di un plugin WordPress per ottimizzarne il caricamento ed il riuso del codice. [...]

  3. 26 apr, 2009 Le top news del web della settimana (20-25 Apr. 09):

    [...] questa carrellata con la naturale prosecuzione dell’articolo di Napolux, ovvero con Struttura ad oggetti di un plugin wordpress del blog [...]

  4. 03 mag, 2009 Best of Week #18 | Gioxx's Wall:

    [...] Sulla struttura ad oggetti di un Plugin WordPress [...]

  5. 19 mag, 2009 Serdominik:

    Ciao leggo questo bell’articolo e volevo farti una domanda: ho creato un plugin per la gestione di prodotti categorizzati per le categorie di wp e altre categorie create da me tramite altre tabelle, il plguin nel back-end funziona perfettamente sorge difficile farlo funzionare nel front-end cioè non saprei come far visualizzare i prodotti sia per elenco che per dettaglio… cioè nn saprei come farlo funzionare per i permalinks sarebbe col mod rewrite che funge molto bene.
    fammi sapere
    Domenico

    Rispondi Quota
  6. 20 mag, 2009 Giovambattista Fazioli:

    @Serdominik: Ciao Domenico, potresti spiegarmi meglio in dettaglio cosa vuoi realizzare?

    Rispondi Quota
  7. 23 mag, 2009 Serdominik:

    @Giovambattista Fazioli:
    Ciao grazie da avermi dato una risposta.

    il mio quesito è abbastanza difficile da capirlo in poche righe di testo ed è difficile scriverlo per fartelo capire (scusa se ti do del tu) difficile seguire poi tramite i commenti domande e risposte per me poichè tra tante cose mi dimentico anche di andare a controllare se per caso mi hai risposto vedi oggi dopo 3 giorni. Se vuoi e se per te nn è un disturbo sentirci tramite msn o skype o per email

    Purtroppo preferisco non fare tanti dettagli via commenti del progetto che sto realizzando

    Rispondi Quota
  8. 26 giu, 2010 Wordpress Plugin Maker | Undolog.com:

    [...] Il codice prodotto segue lo standard ad oggetti descritto in Sulla struttura ad oggetti di un Plugin WordPress [...]

Lascia un commento

TAG XHTML PERMESSI: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong> INSERIMENTO CODICE: 
<pre></pre>                                  // blocco generico
<code></code>                                // blocco generico
[cc_actionscript][/cc_actionscript]          // Actionscript
[cc_actionscript3][/cc_actionscript3]        // Actionscript 3
[cc_css][/cc_css]                            // CSS Style Sheet
[cc_html][/cc_html]                          // HTML
[cc_js][/cc_js]                              // Javascript
[cc_objc][/cc_objc]                          // Objective-C
[cc_php][/cc_objc]                           // PHP
[cc_sql][/cc_sql]                            // SQL