Codice OOP nei plugin di WordPress

In questo articolo introdurremo alcuni dei concetti chiave per programmare in modo Object-Oriented in WordPress; requisiti necessari sono la conoscenza dell'OOP in PHP e competenze di base sul funzionamento del CMS.

Un CMS misto: OOP e programmazione procedurale in WordPress

Un mito comune riguardante WordPress è quello secondo cui il codice sorgente di questo CMS sia interamente procedurale nel suo design. Nulla di più falso: la scelta di design di WordPress è stata quella di costruire le fondamenta del CMS usando le classi e di esporre i metodi e le proprietà di tali classi tramite funzioni e variabili globali.
Ad esempio tutti noi sappiamo che il Loop principale di WordPress - ossia il ciclo attraverso cui vengono reperiti i contenuti - può di solito presentarsi come segue:

if( have_posts() ) {
    while( have_posts() ) {
        the_post();
    }
}

Apparentemente tale codice è interamente procedurale, in realtà tutte le funzioni che abbiamo utilizzato non sono altro che una scorciatoia per il seguente codice OOP:

$loop = new WP_Query( array( 'posts_per_page' => -1 ) );
if( $loop->have_posts() ) {
     while( $loop->have_posts() ) {
         $loop->the_post();
     }
}

Lo stesso concetto vale per le funzioni get_posts() e query_posts(), esse sono tutte basate sulla classe WP_Query; più precisamente, tutto ciò che in WordPress ha a che fare con il Loop - ossia con il reperimento dei contenuti dal database (post, pagine, allegati) - dipende direttamente da tale classe e non può in alcun modo prescindervi.

Ma non basta: anche la temporizzazione degli eventi, la gestione degli errori, delle richieste AJAX, delle query dirette al database, degli utenti e dei loro ruoli, dei menu di navigazione, i widget e altro ancora, sono tutte funzionalità affidate alle classi.

In definitiva, noi usiamo quasi sempre funzioni in WordPress, ma in realtà stiamo adottando le sue classi che restano nascoste dietro le quinte.

Perchè usare l'OOP?

Abbiamo detto che in WordPress le funzioni svolgono egregiamente il loro compito, quindi, per aggiungere una funzionalità al tema utilizzato è solitamente sufficiente modificare il file "functions.php" (il nome è significativo) con il nostro codice e ottenere così l'effetto desiderato.
Se per esempio volessimo creare uno shortcode per visualizzare una citazione di blocco, dovremmo semplicemente aggiungere il seguente codice:

function my_pullquote( $content ) {
    return '<blockquote class="pullquote">' . $content . '</blockquote>';
}
add_shortcode( 'my-pullquote', 'my_pullquote' );

Ma cosa succederebbe se avessimo più di uno shortcode da aggiungere? A livello di gestione e manutenibilità del codice ci ritroveremmo con un file "functions.php" letteralmente traboccante di funzioni, per cui ogni volta che dovessimo modificare una funzionalità saremmo costretti a ricordarci in quale funzione l'abbiamo definita. Si tratta di uno scenario davvero difficile da gestire.
Le classi ci permettono invece di raggruppare il codice in moduli separati, ciascuno con una propria logica ed una propria struttura; quindi, per gli shortcode potremmo definire una classe apposita:

class MyThemeShortcodes {
}

Al suo interno saranno i metodi della classe a definire le azioni legate a ciascuno shortcode:

class MyThemeShortcodes {
    public function __construct() {
        add_shortcode( 'my-pullquote', array( &$this, 'createPullQuote' ) );
    }
    public function createPullQuote( $content ) {
    	  return '<blockquote class="pullquote">' . $content . '</blockquote>';
    }
}
$myThemeShortcodes = new MyThemeShortcodes();

Nel caso specifico l'istanza della classe richiama direttamente la funzione di WordPress add_shortcode() che crea lo shortcode. Quindi in "functions.php" richiameremo i moduli desiderati:

require_once( TEMPLATEPATH . '/framework/MyThemeShortcodes.php' );

Si potrebbe obiettare che questo tipo di classi in WordPress non sono altro che dei wrapper per metodi pubblici, ma in realtà non è così; si supponga ad esempio di voler eliminare la marcatura aggiuntiva inserita da WordPress nel contenuto degli shortcode:

private function _removeWPAutop( $content ) {
    $content = do_shortcode( shortcode_unautop( $content ) );
	$content = preg_replace( '#^<\/p>|^<br \/>|<p>$#', '', $content );
	return $content;
}

public function createPullQuote( $content ) {
    return '<blockquote class="pullquote">' .
    $this->_removeWPAutop( $content ) . '</blockquote>';
}

Come si può notare, viene applicata la stessa distinzione alla base della logica OOP di PHP: un metodo privato opera all'interno della sua classe di appartenenza secondo il principio dell'incapsulamento.

Il metodo è privato perché al di fuori della classe che gestisce gli shortcode non sarebbe di alcuna utilità. Infatti il problema della marcatura extra è peculiare degli shortcode di WordPress.
Lo stesso principio si applica alle proprietà di queste classi, ad esempio potremmo volere che sia l'utente a scegliere di rimuovere la marcatura dagli shortcode o mantenerla:

class MyThemeShortcodes {
    public $removeAutop = false;
    public function __construct() {
        if(get_option('my-no-autop')) {
            $this->removeAutop = (bool) get_option('my-no-autop');
        }

//...
    }
    public function createPullQuote( $content ) {
         if($this->removeAutop) {
              // rimuove la marcatura
          } else {
             // non la rimuove
          }
    }
}

In questo caso usiamo una proprietà pubblica in modo da poter comunicare lo status della classe alle altre classi che andremo a definire, ossia la scelta di non intervenire sul contenuto degli shortcode.