Creare un plugin per aggiungere funzionalità personalizzate

Un sito web, si sa, viene modificato costantemente per ragioni di sicurezza e per soddisfare le esigenze dei visitatori, che cambiano in continuazione.

Alcune volte, però, l’aggiornamento non riguarda solo i contenuti o la piattaforma, tema e plugin compresi, ma consiste in una nuova funzionalità da aggiungere, fosse anche solo uno shortcode che produca un contenuto da ripetere in più pagine o articoli. In questa situazione va aggiunto del codice Php che sfrutti le API di WordPress.

Una modalità è quella di inserirlo nel functions.php del tema child (argomento che ho già trattato in “Creare temi child per siti in WordPress”); tuttavia, per implementare modifiche molto specifiche che non riguardano la struttura del tema, questo metodo non è molto conveniente. È molto meglio scrivere un plugin ad hoc che viene caricato insieme a tutti gli altri.

In questo articolo vediamo come scrivere un plugin per aggiungere nuove funzionalità ad un sito esistente o in fase di sviluppo. Se vuoi, invece, distribuire il tuo plugin, non puoi fermarti ai concetti qua spiegati; a tale scopo ti rimando al Plugin Developer Handbook, la documentazione ufficiale del team di WordPress.

Lavorare su un’area di staging

Quando si va a modificare pesantemente un sito e, soprattutto, quando si interviene a livello di funzionamento, non è affatto consigliabile lavorare sulla versione in produzione; è possibile rompere il sito e, in casi estremi, far rischiare al proprio cliente delle perdite economiche (ad esempio quando abbiamo a che fare con un e-commerce).

Si rende così opportuno lavorare su un sito di staging, che può essere creato in un sottodominio, in un dominio differente o in una macchina virtuale nel proprio computer. Per approfondire l’argomento ti consiglio di leggere “Perché utilizzare un sito di staging”.

Suggerisco, quindi, di lavorare seguendo questa procedura.

1. Duplicazione del sito di produzione, così da ottenere una copia su cui si lavorerà seguendo i passaggi fino al 7.
2. Nella directory dei plugin (che, normalmente, è /wp-content/plugins/, salvo differenti impostazioni) creare una cartella col nome del plugin (il nome va scritto tutto in minuscolo coi trattini al posto dello spazio).
3. Dentro questa cartella creare un file con estensione .php avente lo stesso nome della directory. Altri file possono essere creati e fatti caricare dal plugin, purché si trovino tutti all’interno della cartella.
4. Nel file aprire il codice Php e mettere le intestazioni principali.
5. Attivare il plugin affinché il codice funzioni.
6. Sviluppare le proprie funzionalità.
7. Testare il plugin molte volte.
8. Una volta terminato lo sviluppo caricare, via FTP o SSH, la cartella del plugin, nella directory preposta, sul sito in produzione. Se l’avvio della funzionalità richiede modifiche al database procedere ad apportarle, previo backup di quest’ultimo.
9. Attivare il plugin e verificare che tutto funzioni correttamente.

Le intestazioni del plugin

Ogni plugin, installato in un sito WordPress, deve avere delle intestazioni che forniscano alla piattaforma una serie di informazioni utili. Qui propongo le principali; per conoscere anche le altre consultare la sezione Header Requirements del Plugin Developer Handbook.

    <?php
       /**
	* Plugin Name:       Il mio plugin
	* Description:       Aggiunge alcune funzionalità richieste per questo progetto
	* Version:           1.0.0
	* Requires at least: 5.2
	* Requires PHP:      7.2
	* Author:            Andrea Ronchetti
	* Author URI:        https://www.andrearonchetti.it/
	* Text Domain:       mio-plugin
	* Domain Path:       /languages
	*/

Le voci qui inserite sono:

• Plugin Name: nome del plugin;
• Description: breve descrizione del plugin;
• Version: versione del plugin; se vengono fatte nel tempo modifiche è bene tenere aggiornato questo valore;
• Requires at least: versione minima di WordPress compatibile
• Requires PHP: versione minima di Php
• Author: autore del plugin
• Author URI: sito dell’autore (fatti un po’ di pubblicità, non si sa mai…)
• Text Domain: text domain di gettext, il sistema usato da WordPress per tradurre le stringhe, che il plugin stampa a video, nella lingua di installazione. Ne ho parlato in “Come scrivere un plugin traducibile”
• Domain Path: la cartella, dentro quella del plugin, dove mettere i file .po e .mo per l’internazionalizzazione delle stringhe.

Di tutte queste voci quella assolutamente necessaria, al fine del corretto riconoscimento da parte di WordPress e, quindi, del funzionamento, è Plugin Name. La descrizione non è obbligatoria ma è vivamente consigliata poiché il proprio plugin sarà presente in mezzo agli altri installati e dopo parecchio tempo è difficile ricordare gli scopi per cui è stato sviluppato.

Se il plugin deve essere internazionalizzato anche le voci Text Domain e Domain Path vanno inserite.

Una volta scritte queste intestazioni è possibile attivare il plugin e iniziare a sviluppare.

Ultima considerazione: ho scritto le voci in italiano per praticità ma, normalmente, nel codice è bene usare l’inglese; se c’è bisogno di leggere, a video, delle stringhe in italiano è bene optare per il sistema di internazionalizzazione.

Attivare il debug

Quando si sviluppa un’applicazione è necessaria l’attivazione della modalità debug, al fine di sapere quali errori si verificano nel momento in cui non funziona tutto a dovere. A tale scopo WordPress prevede 3 costanti da settare nel file wp-config.php, tutte aventi un valore booleano:

• WP_DEBUG → attiva o disattiva la produzione di messaggi di errore. Di default è false, quindi il log è disattivato.
• WP_DEBUG_LOG → con valore true permette la scrittura degli errori nel file /wp-content/debug.log.
• WP_DEBUG_DISPLAY → con valore true permette di stampare a video il messaggio di errore.

Con queste costanti puoi scegliere la modalità di log che preferisci. Se decidi di scrivere il file ti consiglio di pulirlo ogni volta, così da identificare più agevolmente gli ultimi problemi verificatisi.

Sul sito di produzione è fondamentale settare tutte queste 3 costanti a false: i messaggi di log, specie se stampati a video, possono offrire informazioni molto utili per attaccare il sito. Se è proprio necessario tenere un log è bene scriverlo in una directory non facilmente raggiungibile. Oppure è possibile oscurare questo file, per le chiamate http, tramite impostazioni sul file .htaccess, che puoi creare nella cartella /wp-content/. Ecco cosa scriveremo sul questo file:

# accesso non consentito al file debug.log
<files debug.log>
order deny,allow
deny from all
</files>