Sette Cose da Sapere per Sviluppare Plugin WordPress

7 Cose che Avrei Voluto Sapere Prima di Scrivere un Plugin

Questo articolo si propone come una piccola guida in 7 punti che avrei voluto poter leggere prima di iniziare lo sviluppo, ma anche come  vademecum da tenere sott'occhio nelle varie fasi, dal debugging alla pubblicazione.

La cosa che ci piace di WordPress è la sua estensibilità, sopratutto tramite i plugin. Tutti sappiamo dove andare a cercare quando ne abbiamo bisogno, ci rivolgiamo al repository su WordPress.org. Il problema sorge quando non troviamo la cosa che ci soddisfa in pieno e dobbiamo provvedere in prima persona sederci a scrivere il codice per realizzarne uno, come è recentemente successo al sottoscritto.

1.  L’idea è fondamentale. Ancora più importante è come la realizzi!

Il primo punto l’ho voluto dedicare completamente alla filosofia e alla preparazione degli strumenti necessari, perchè se è vero che l’idea è la chiave più importante per il successo è anche vero che senza i mezzi  e la mentalità giusti non si va molto lontano.

Ora il lettore, sbavando in maniera idrofoba, si starà domandando: “Perchè parli di filosofia? Dove vuoi andare a parare? Io ho fretta di scrivere il mio codice!!”

Bene! E’ proprio questa la reazione che dovrete evitare. Mettetevi l’anima in pace, correre non porta da nessuna parte. Prendete un respiro e adottate un atteggiamento di calma Zen nei confronti delle difficoltà che troverete.

Molto spesso si incappa in errori facilmente evitabili ricontrollando più volte il codice e tenendo sotto mano la pagina principale del Codex, la Bibbia dei programmatori WordPress. Oltre alla documentazione principale di WordPress un’altra fonte di ispirazione per la realizzazione del vostro plugin può provenire da codice scritto da altri.

La potenza di questo CMS è anche quella di essere totalmente open source e di richiedere una licenza GPL 2.0 o superiore per poter risiedere nel loro repository, quindi tutto il codice dei vari plugin che vi troverete ospitato sarà liberamente consultabile e integrabile nel vostro entro i termini della licenza stessa. Cercate tra i numerosissimi plugin disponibili se c’è qualcosa di simile a ciò che vorreste realizzare,  date liberamente un’ occhiata al codice, in moltissimi casi risparmierete ore tra ricerche e progettazione.

Ora manca solo un piccolo passo prima di potersi sedere tranquilli davanti al proprio text editor preferito con una bella tazza di tè caldo in mano e Bach a risuonare nelle cuffie: il preziosissimo strumento di debug di WordPress. Questo ci permetterà non solo di vedere gli errori critici ma anche di individuare eventuali funzioni deprecated. Attivarlo è semplicissimo, ci basta aprire il file wp-config.php del sito che intendiamo utilizzare come piattaforma di test e cambiare questa riga da:

in:

Gli ultimi due parametri sono consigliatissimi, poichè leggere gli errori da un log è molto meglio che vederseli stampati a video nel sito. Ricordatevi però che il log potrebbe contenere informazioni sensibili. Visto che WordPress non ci offre la possibilità di cambiare cartella per questo file e /wp-content è pubblica cercate di tenerlo il meno possibile online, usatelo solo per il debug e poi cancellatelo.

Anche nel caso del debugging però dovremmo applicare la filosofia di cui sopra. Armatomi di pazienza vado a dare un’occhiata al codex e spulciando tra i plugin disponibili mi sono accorto dell’esistenza di Debug Bar.  Che siate amanti dell’ottimizzazione oppure semplicemente pigri, troverete in questo plugin uno strumento sorprendentemente utile e comodo da usare. Fa praticamente tutto quello di cui c’è bisogno ed è in grado di mostrare anche l’influenza in termini di tempo di risposta delle chiamate al database. Un must-have per uno sviluppatore WordPress.

2. La prima riga che scriverete sarà la più importante

“Scommettiamo che indovino quali saranno le prime righe di codice che scriverete?”

A questo punto i più smaliziati di voi avranno capito che in realtà le prime righe del file principale di un plugin sono un’ intestazione standard che WordPress ci impone e che ci torna utile per molti aspetti. Andiamoli ad analizzare partendo dal codice (che in realtà è un commento).

Cerchiamo di anticipare qualche concetto che ci potrà tornare utile dopo. Tutti i parametri che inseriremo in questo header verranno poi visualizzati all’interno della pagina Plugin nel pannello di amministrazione di WordPress. E’ quindi importante fornire tutti i link utili per gestire al meglio l’installazione e i parametri del vostro plugin e aggiornare costantemente la versione dello stesso ad ogni modifica. WordPress, infatti, prende il parametro Version dalla pagina principale del plugin e lo confronta con il tag Stable del file readme.txt presente nel loro repository (trattato in seguito) per stabilire se la versione del plugin è aggiornata.

Dimenticarsi di modificare il numero di versione ad ogni rilascio potrebbe causare moltissimi problemi a chi in futuro vorrà aggiornare il vostro plugin. Il parametro Author URI non è necessario ma, per esperienza personale, posso dirvi che porta parecchio traffico e possibilità di ricevere feedback diretti, che è sempre cosa gradita! Per completare l’introduzione vi consiglio di inserire un piccolo estratto della licenza, sempre sotto forma di commento, per dare subito l’idea di cosa si può e non si può fare con il vostro codice.

 3. Lavorare con i percorsi/path in maniera corretta

WordPress ci mette a disposizione parecchie funzioni per ricavare automaticamente i percorsi ed è indispensabile usarli per rendere il proprio plugin “universale”, delegandogli il compito di capire dove è installato. Il problema è che sono veramente tanti e bisogna capire bene come usarli. Iniziamo ad elencarli:

Questa funzione ci restituirà la URL del plugin, solitamente viene impiegato quando si vuole ricevere l’url di una risorsa che vogliamo includere. Un esempio chiarificherà il tutto:

Poi abbiamo:

Questo ci restituirà la URL della cartella contenente il plugin con uno slash finale esattamente come se non specificassimo una risorsa nella funzione precedente. Personalmente lo chiamo “metodo rapido” perché è quello che di solito si ricorda meglio e si utilizza di più quando la risorsa all’interno della cartella deve essere una variabile della funzione che stiamo costruendo. Esempio di utilizzo:

In realtà, come avrete notato, con qualche piccolo adattamento ai due metodi, possiamo tirare fuori gli stessi percorsi. Comprendere al meglio le differenze e le potenzialità ci offre il vantaggio di saper sempre scegliere la funzione che ci permetta di scrivere il minor codice possibile che funzioni al meglio per le nostre esigenze. Altra funzione comodissima è quella che ci fa tornare il filesystem path, senza http per capirci.

Buttando un’occhiata rapida, capirete che in realtà il path assoluto sarebbe molto meglio per richiamare una risorsa, sopratutto internamente alla funzione che stiamo sviluppando. Nei casi in cui la risorsa verrà poi stampata a video (tramite echo ad esempio) io preferisco comunque usare la URL, in modo da far passare il link al webserver e generarne uno che se verrà esplorato avrà la sua URL fissata da me. Sappiate però che è assolutamente ininfluente ai fini della ricerca della risorsa. Dovete immaginare il puntatore dir_url e quello dir_path come due frecce distinte che puntano allo stesso bersaglio! Altra piccola osservazione va fatta se lavorate su sotto-cartelle, in quel caso potete comodamente usare due dirname(), uno dentro l’altro, in questo modo:

 4. Problemi di lingua: ovvero come ho dovuto riscrivere un plugin perchè risultava intraducibile.

Vi siete mai chiesti come si fa a tradurre o a rendere disponibile un plugin WordPress in più lingue? Io, fino a pochissimo tempo fa’, NO!

Errore banalissimo che ci fa piangere quando dobbiamo rimettere mano ad un codice funzionante, si può evitare facendo attenzione e dedicando delle piccole accortezze in fase di programmazione. Il nostro amato WordPress utilizza dei file con estensione .mo, contenenti le varie traduzioni dei plugin. Un file .mo non è altro che un file .po o .pot “compilato” da poedit . Per rendere compatibile il nostro plugin con la stesura di un file .po e successivamente di quello .mo dovremmo studiare un attimo come dotare il nostro plugin di “ancore” per la traduzione. Iniziamo con l’incorporare nel plugin questa funzione:

Cosa abbiamo fatto? Semplicemente, abbiamo associato la cartella /languages (che dovrete creare) al textdomain con handle ‘mioplugin’, che per comodità chiamo come il plugin, questa è una cosa che vi consiglio di fare poiché dovrete richiamarlo spesso e usare un nome che ricordate vi aiuterà molto.

Ora andiamo ad operare sul codice, sarebbe meglio iniziare con questo approccio ancor prima di iniziare a scrivere il tutto, ma se come me avete mancato l’appuntamento con il destino e state già rimpiangendo di averlo fatto sappiate che dovrete rinunciare a stampare con le comode echo e sostituirle con le funzioni di WordPress _e()  / __() o la più scomoda (a mio avviso) translate().

Cosa?? Non sapevate che esistevano funzioni specifiche per stampare i testi che poi andranno tradotti??

Consolatevi, siete in buona compagnia, più della metà dei plugin che uso regolarmente non adottano minimamente questo approccio, quindi sappiate che con questo metodo sarete un passo più avanti persino dei migliori programmatori WordPress!! Finita l’ora della consolazione e della gloria personale andiamo a conoscere meglio queste due funzioni ( translate() non la tratterò). Usandole siamo costretti ogni volta a specificare l’handle del texdomain. Poco male, se ricordate prima vi ho consigliato di chiamarlo come il plugin appositamente per facilitarvi nel compito. Gli approcci, come è buona norma nella programmazione, possono essere di vario tipo e non c’è niente di meglio di un esempio dinamico per spiegarli:

A questo punto gli utenti Mac e Windows dovranno scaricare poedit da questo indirizzo e installarlo. Per gli utenti linux sarà ancora più facile perchè si trova in praticamente tutti i repo delle distribuzioni più famose. Per Fedora:

Per Debian e Ubuntu

Dopo l’installazione, al primo avvio del programma, vi verrà chiesto nome e indirizzo email. Finite le procedure burocratiche ci basterà andare su  File -> Nuovo Catalogo per ritrovarci un’altra bella lista da compilare. Scegliete la lingua in cui il vostro plugin è ORIGINARIAMENTE scritto (nel mio caso inglese) e riempite gli altri campi con i vostri contatti, fatto ciò spostatevi nella scheda Percorsi e lasciate il Percorso di Base con un punto mentre dovrete aggiungere sotto un altro percorso semplicemente aggiungendo due punti consecutivi (..) perché abbiamo bisogno anche di una sotto-directory che sarà proprio languages.

Nella scheda Parole chiavi (Orridamente tradotta in un programma di traduzioni, permettetemi un LOL) dobbiamo cancellare tutto e inserire le nostre funzioni relative a WordPress, quindi inseriamo __(), _e() in caso  l’abbiate usata anche translate(), ovviamente tutto senza parentesi. Ora salviamo nel percorso del plugin (es. /test-wordpress/wp-content/plugins/mioplugin/languages/mioplugin.pot). Fatto ciò dovrete fare update per fagli ricercare le corrispondenze, poi chiudete, tanto non avrete più bisogno di editare quel file a meno che non farete modifiche.

“Ma chi me l’ha fatto fare!! Maledetto te con queste traduzioni sto perdendo tempo!! Avrei potuto fare tutto in inglese, se lo imparassero tutti!”

Amico idrofobo, come darti torto? Cerca però di riportare alla mente la calma zen e la tazza fumante! Prova a rilassarti e a pensare che alla fine chiunque potrà tradurre nella propria lingua il tuo capolavoro. Quello che stai facendo, lo fai per farti aiutare! 😉

Andiamo avanti con il lavoro e passiamo a creare il primo file di lingua. Andate su File -> Nuovo catalogo da file POT e navigate fino a trovare il file precedentemente creato. Qui potete lasciare le cose come sono tranne per la lingua e il paese (era così ovvio che ho preferito dirvelo), controllate che le Parole chiave siano identiche a prima e che i percorsi siano rimasti inalterati, poi salvate tutto nella cartella languages rispettando la nomenclatura che prevede una struttura simile: textdomain-lingua_LOCALE.po (es. poniamo il caso abbia scelto di tradurre in italiano, /test-wordpress/wp-content/plugins/mioplugin/languages/mioplugin-it_IT.po)

Ora potete tradurre tutto quanto senza problemi e salvare nuovamente il file. Così facendo si genererà in automatico anche il file .mo e finalmente il nostro plugin sarà automaticamente multilingua!!!

L’articolo di Massimo Della Rovere che potete trovare qui, mi è stato di aiuto sopratutto per capire come funziona poedit, ottima risorsa da tenere nel taschino dedicato ai bookmark!

5. Registrare gli script e gli stili

Questa parte me la sarei risparmiata volentieri, vista anche la poca fatica che ci si mette, il problema è che in questo caso il codex non ci dà una mano chiara e fornisce esempi piuttosto nebulosi!! L’unica cosa chiara è che come avviene nei temi anche nei plugin gli script si inseriscono con wp_enqueue_script(), ma prima devono essere registrati con wp_register_script() in questo modo:

Chi ha già avuto modo di usarla nei temi è avvantaggiato e quindi ora si sta sfregando le mani, agli altri comunque spiegherò tutto partendo dalle opzioni:

Ora possiamo usare wp_enqueue_script() per richiamarlo senza troppi problemi, tramite l”handle che abbiamo registrato. Un esempio spicciolo di funzione per includere script, come al solito, pacificherà le irrequiete menti:

Anche per gli stili succede esattamente la stessa cosa, con l’unica differenza che a volte mi riservo la scelta di non registrare lo stile ma di includerlo solamente, un paio di esempi più avanti vi chiariranno la cosa. Partiamo dalle due funzioni wp_register_style() e wp_enqueue_style():

I parametri sono del tutto simili a quelli usati prima per gli script, con l’unica differenza che qui possiamo scegliere il tipo di media a cui assegnare lo stile, in accordo con le specifiche css, passandolo alla variabile $media e che non possiamo scegliere dove caricarlo,andrà nel wp_head(). In realtà, un modo per farlo finire nel footer c’è, basterebbe usare il wp_enqueue_style() nel mezzo di qualche porzione HTML di una pagina nel frontend. Purtroppo questo è l’unico hack che sono riuscito a trovare per aggirare il problema, ovviamente se qualcuno conosce anche altri modi usi tranquillamente il modulo per i commenti e mi faccia sapere!

Andiamo avanti e vi mostro ben due modi per includere i vostri stili:

Questo è il metodo corretto e anche quello che vi permetterà poi di includere ed escludere gli stili da porzioni di codice. Riguardo questo c’è la funzione opposta a wp_enqueue_style() che è wp_dequeue_style() che vi consiglio di guardare perché permette parecchi giochetti interessanti. Questa cosa di includere ed escludere gli stili tramite funzioni apposite è sia un vantaggio che uno svantaggio, poiché a volte vorremmo poter solo mettere un’ inclusione rapida, magari per un plugin con una pagina sola e 3 funzioni per generare shortcode che poggiano la loro esistenza su un CSS e stop!

“Quindi posso o no includere il mio stile senza starmi a sbattere con questa storia della registrazione?!?!”

Caro amico tranquillizzati, lo puoi fare senza alterarti! Basta ricorrere al parametro opzionale $src di wp_enqueue_style() in questo modo:

Per raggiungere lo scopo si può accettare senza problemi questa seconda soluzione, però ricordiamoci cosa distingue un vero Maestro del Bushido da un comune spadaccino, l’onore.

“Vi è un solo giudice dell’onore del Samurai: lui stesso. Le decisioni che prendi e le azioni che ne conseguono sono un riflesso di ciò che sei in realtà. Non puoi nasconderti da te stesso.”

Quindi ponetevi sempre le domande: “La risorsa che sto usando mi servirà nuovamente? Prevedo di aggiornare in futuro il plugin includendo nuove parti che potrebbero richiedere la medesima? Ho veramente bisogno di registrarla?” Dalle risposte che vi darete saprete con chiarezza quale metodo approcciare!

6. Facciamo amicizia con il file Readme

Arrivati a questo punto i più frettolosi di voi potrebbero già smettere di leggere, in fondo perchè scrivere un README se il plugin serve solo a noi che l’abbiamo costruito?

Qui però vi invito a pensare all’onore del samurai e a porvi altre domande fondamentali: “Lo utilizzerò solo io? Intendo pubblicarlo nel repository di WordPress? Questo plugin può tornare utile a qualcun’altro?”

In fondo se siete stati “costretti” a estendere le funzionalità di WordPress vorrà dire che queste aggiunte a qualcun’altro potranno tornare utili, giusto? Bene! Armiamoci di pazienza, rimettiamo su il vinile della Penguin Cafè Orchestra e capiamo cos’è questo file e perchè è così importante.

WordPress richiede obbligatoriamente la presenza del file readme.txt nella cartella principale del vostro plugin. Questo file deve essere formattato in maniera particolare, poiché i dati inseriti nel suddetto serviranno a popolare le schede descrittive del plugin nella pagina rispettiva sul sito wordpress.org. Il codex ci offre una splendida demo di come deve essere realizzato il file readme.txt. Visto che il prossimo argomento trattato riguarderà proprio il sistema di caricamento che sfrutta WordPress per mantenere aggiornate le versioni del plugin (subversioning o svn) vi invito a capire ora come scrivere il readme, per essere pronti a caricare tutto al primo colpo senza intoppi e per farlo useremo come esempio un mio plugin. Di seguito c’è il mio readme.txt che potrete confrontare con la rispettiva pagina su wordpress.org

Ricalcare questo file per produrre il vostro sarà ora più facile, ma voglio comunque soffermarmi su alcuni particolari. Il campo Contributors deve rispecchiare uno o più username registrati a WordPress mentre i tag sono completamente arbitrari, potrete sbizzarrirvi. Il consiglio è quello di cercare i tag dei plugin simili al vostro così per farvi un’idea di quelli secondari da usare. Questo passo spesso è snobbato, a mio avviso è invece importantissimo! Il sito di WordPress non presenta categorie e menù multilivello per orientarsi nella ricerca dei plugin, quindi se volete essere trovati dovrete fare un uso saggio del sistema di tag.

Subito sopra la Description e sotto il License URI troviamo la short description, purtroppo dovrete limitarla veramente tanto perché oltre un tot di caratteri, in fase di pubblicazione, vi verrà chiesto ripetutamente di accorciarla. Per evitare da subito le scocciature e i ritardi fatela essenziale e concentrate gli sforzi nella descrizione completa che può essere lunga quanto ci pare e sarà la prima pagina con cui gli utenti si confronteranno.

Dalle FAQ in poi, nulla è obbligatorio, potrete decidere se riempirlo o meno; come al solito vi consiglio di farlo perché vi risparmierà una miriade di domande e voi potrete tenere traccia di tutti i cambiamenti del vostro plugin nel tempo, accrescendo il readme con ulteriori informazioni che scoprirete utili per gli utenti stessi.

Lo Stable Tag indicherà quale versione del plugin dovrà essere considerata stabile da wordress e dal sistema di aggiornamenti, quindi la prima volta che compilerete questo campo fatelo con in mente anche una numerazione per le versioni. Quella classica suggerisce almeno un decimale, ma se il plugin è molto corposo e comprende più files e risorse forse conviene adottarne anche due, per le patch. Partite da una bella 1.0 oppure 1.0.0 e sarete apposto nella maggior parte dei casi! Altra nota va spesa per la formattazione speciale del testo:

Questa sintassi in realtà è molto diffusa nell’ambiente della programmazione e si chiama Markdown, potete usare tutte le specifiche che trovate sul sito del progetto per rendere la vostra pagina ancora più bella.

Finito di redigere il readme possiamo usare questo comodo strumento del sito di WordPress, che come al solito ci viene incontro. Permette di validare il txt e controllare che tutto sia al giusto posto.

7. Pubblichiamo il plugin usando il sistema di subversioning SVN di WordPress.org

Se non l’avete ancora fatto, questo è il momento giusto per iscriversi a WordPress.org e volendo anche a Gravatar per ottenere un immagine del profilo più carina del classico mostro da associare alla mail che userete per registrarvi.

Ora dovrete chiedere a wordpress.org di fornirvi uno spazio e le credenziali per accedere in svn al loro repository, prima di concedervelo vorranno revisionare (a mano) il vostro plugin. Collegatevi al developer center di WP e cliccate su “Add Your Plugin”, vi verrà chiesto un link da cui scaricarlo e di fornirne una piccola descrizione, se avrete inserito correttamente il file readme non avrete problemi ad effettuare rapidamente questo passaggio. Appena il plugin è stato revisionato (in genere ci vuole qualche giorno) riceverete una mail con tutti i dati relativi al vostro spazio nel repository! Prima di andare avanti voglio ricordarvi le poche regole per poter essere ospitati su wordpress.org:

  1.  Il plugin deve essere rilasciato sotto licenza GPL2.0 o successive
  2.  Non inserire materiale offensivo o illegale, anche se difficilmente lo fareste è sempre meglio ricordarlo
  3. Non inserite link a voi stessi nel codice senza l’esplicito consenso dell’utente o senza dargli la possibilità di rimuoverlo facilmente. Nel caso in cui vogliate scegliere di metterlo di default e dare la possibilità all’utente di toglierlo, SPECIFICATELO BENE sia nella documentazione sia nel readme
  4. Il resto, come ci dice anche wordpress.org, è solo una serie di regole che spiegano come non essere uno spammer. Noi daremo per certo il fatto che voi non lo siate!

Appena riceverete conferma della revisione del plugin, vi verrà fornito il link al vostro repository e le credenziali per accedervi. A questo punto dotatevi di una GUI per svn per rendere le operazioni più veloci e pratiche. Siccome si parla di scrivere percorsi di cartelle e URL, la riga di comando la lasciamo ai più temerari, che rimanderemo alla lettura del Codex. Agli altri consiglio TortoiseSVN per Windows e RapidSVN per Linux e Mac.

Ora andremo a introdurre qualche concetto generale del sistema di subversioning che qualsiasi client usiate, anche fosse svn da riga di comando, vi permetterà di padroneggiare le operazioni di revisione e pubblicazione del codice. Le operazioni principali che farete saranno 3:

  • Importare il repository (Questo generalmente si fa la prima volta e in caso ci si voglia lavorare su più postazioni)
  • Aggiungere i file alla lista dei file da committare
  • Fare il commit

Iniziamo con ordine, prendete il vostro client e importate (Checkout è il termine che troverete in molti casi) la struttura del repository in una cartella appositamente creata da voi (io l’ho messa nella cartella /home/progetti/imagenius/), usando il link e le credenziali fornitevi da wordpress. A questo punto noterete che nella cartella sono state automaticamente create delle sottocartelle, esaminiamole per bene.

/trunk/

Qui metteremo il codice su cui attualmente stiamo lavorando, può tranquillamente essere l’ultima stabile se non avete in progetto nulla di nuovo, la cosa importante è che questa è la prima cartella che va riempita di tutti i files e le cartelle di cui necessita il vostro plugin, compreso il nostro carissimo file readme.txt.

/tags/

Questa cartella deve contenere sottocartelle nominate con il numero di versione, al cui interno potete iniziare con il creare la vostra 1.0 e copiandoci il contenuto di /trunk/. Il modo in cui si dovrebbe procedere è, infatti, quello di lavorare nella cartella trunk e poi a codice ultimato e testato creare una nuova cartella in tags e copiarci direttamente tutto dentro, stando attenti a modificare poi il numero di versione stabile nel readme sia nel trunk che nella cartella corrente.

/branches/

Qui siamo facilitati dalla parola stessa che ci indica la funzione della cartella. Ovviamente se lo state pubblicando ora la vedo difficile che avrete branches disponibili al volo, se comunque doveste sentirne necessità questa è la cartella dove piazzare tutto il codice!

/assets/

Questa cartella è praticamente a vostra disposizione per poggiarci tutto ciò che pensate possa tornarvi utile, io la uso per aggiornare la documentazione per esempio. La funzione fondamentale di questa cartella però è quella di permetterci di caricare il banner e gli screenshot del nostro plugin da mostrare poi nella relativa pagina su wordpress.org.

Gli screenshot devono essere rinominati in questa forma screenshot-1.png con numero progressivo, per essere associati alla relativa descrizione che abbiamo messo nel readme mentre il banner deve essere un png di 772×250 pixel e deve chiamarsi banner-772x250.png.

Riempite le varie cartelle con i giusti files che dovrete procedere ad aggiungere (add in molti client) e successivamente a committare (commit). Controllate bene di aver aggiunto tutti i files, anche quelli nelle sottocartelle del vostro plugin, prima di fare commit. Avere un client svn è comodo perchè ci segnala i cambiamenti nelle cartelle e ci fa notare eventuali disallineamenti di versioni con il server.

La pecca di questo sistema, però, è che per ogni minima modifica dovrete indicarla con un piccolo commento e quando si tratta di cose veramente piccole a volte non si sa neanche cosa scrivere! 😀

Ricordiamoci  che per “spingere” un aggiornamento per il vostro plugin basta cambiare il parametro stable del readme messo nel /trunk, quindi prima creiamo le cartelle, committiamo tutto nella cartella relativa alla nuova versione e cambiamolo nel suo readme.txt e poi anche in quello del /trunk!

Il sistema di subversioning ci permette altre operazioni comode per spostare, unire e controllare le differenze tra le varie revisioni (i commentini di cui parlavo prima), per questo vi rimando ad una basilarissima ma completa guida sul tema.

Conclusioni

Eccoci giunti alla fine di questo articolo. Quelle che sono state presentate sono state le cose che avrei voluto conoscere prima ancora di scrivere il mio plugin, ma questo non vuol dire che nel futuro non leggerete altri miei aggiornamenti. La programmazione offre il vantaggio di portarci sempre nuove conoscenze e condividerle è la cosa più bella.

Come spesso accade su questo blog, mi farebbe piacere cosa pensate di questo articolo, se ci sono dubbi, se avete da passare qualche suggerimento… Insomma, per qualsiasi comunicazione, la sezione dei commenti è proprio qua sotto!

Lascia il tuo Pensiero

17 Responses to “7 Cose che Avrei Voluto Sapere Prima di Scrivere un Plugin”

  1. Roberto Iacono

    Complimenti Andrea, sono rimasto a bocca aperta. Articolo stupendo!

    Aggiunto ai preferiti dei preferiti 😉
    Quando mi viene la voglia malsana di realizzare un nuovo plugin per WP, sicuramente so da dove partire 🙂
    Ciao!

    Rispondi
    • Andrea Barghigiani

      Povero Eugenio! Per questi argomenti di plugin e programmazione avanzata posso dire tranquillamente che Eugenio è il mio mentore quindi, per roberto e gli altri lettori, sappiate che è questa la persona alla quale chiedo aiuto nei dubbi di programmazione più profondi e che contribuisce a questo sito.

      Grazie ancora Eugenio!

      Rispondi
  2. Alessandro

    Ciao Andrea! E’ un po’ che non ci sentiamo…e ne colgo l’occasione commentando questo articolo.
    Wpandmore sta crescendo e con esso la qualità dei suoi articoli. Spaziando con le mie letture ho trovato questo articolo e mi ha affascinato positivamente…al punto che ho pensato…perché non provare a creare un plugin?
    Ho messo in atto quanto spiegato da Eugenio su un piccolo esperimento che avevo in mente…e…tadaaaa..adesso ho il mio plugin sul repository di WordPress!
    Buon lavoro ragazzi

    Rispondi
    • Andrea Barghigiani

      Ciao Alessandro,
      sono felicissimo del tuo risultato e mi fa un immenso piacere sapere che ci sei riuscito leggendo anche gli articoli di wpAndMore! Sono sicuro che anche Eugenio muore dalla voglia di conoscere il tuo nuovo plugin e potremmo anche inserirlo nella serie Weekly Plugin che voglio riprendere con questa estate.

      Restiamo in contatto e continua così, WordPress sta crescendo e con esso la necessità di conoscere persone che sanno il fatto suo.
      A presto,
      Andrea

      Rispondi
    • Eugenio Petullà

      Felicissimo di averti aiutato!

      L’intento dell’articolo era proprio quello di facilitare ogni utente nella fase di pubblicazione nel repo di WordPress. A questo punto facci pervenire qualche link senza problemi, siamo sempre ben disposti a contribuire nell’accrescere la comunità italiana di sviluppatori WP!

      Proprio a questo scopo ti invito anche a partecipare su Google Plus aderendo alla nostra community in modo da far conoscere anche li la tua opera.

      https://plus.google.com/communities/109254048492234113886

      Rispondi
  3. Alessandro

    Ciao ragazzi,
    eccomi…meglio tardi che mai…purtroppo il tempo non basta mai ( vero Andrea? :-)).
    Volevo ringraziarvi per l’interesse fornitomi nelle risposte.
    Il link del plugin che ho fatto è :
    http://wordpress.org/plugins/spamdyke-analyzer/installation/
    e come avete intuito si chiama “Spamdyke Analyzer”; in parole povere nel lavoro che faccio ho dovuto implementare un meccanismo di controllo dello spam su un server di posta e la mia attenzione si è focalizzata su un modulo chiamato appunto Spamdyke che lavora in complicità con il server Qmail (per chiunque fosse interessato all’argomento,indico l’articolo che ho scritto in merito: http://www.alessandroconsorti.it/combattere-lo-spam-ed-aumentare-la-sicurezza-di-un-linux-mail-server-con-qmail-e-spamdyke/ ). Quando un messaggio viene filtrato da Spamdyke, quest’ultimo ritorna al mittente come risposta un codice di errore. Nasce da qui l’idea di creare un plugin WordPress che, leggendo questo codice di errore, lo traducesse in qualcosa di più comprensibile; ecco che grazie a questo articolo prende vita la realizzazione del plugin di cui sopra (visto anche che nel repository non esiste niente di pronto).
    Essendo riuscito quindi a sviluppare il plugin, nato in lingua inglese, ho deciso di rileggere la parte di questo articolo che indica come rendere la propria creazione multilingua….ed ecco che ho pubblicato ieri la nuova versione anche in lingua italiana.
    Putroppo, anche se il plugin funziona, sto cercando di capire il perché WordPress al momento dell’attivazione mi segnala:
    “Il plugin durante l’attivazione ha generato 3 caratteri di output inaspettato. Se si nota un messaggio di “headers already sent”, problemi con i feed o altre tipologie di problemi, si provi a disattivare o rimuovere il plugin.”.
    Ho provato ad attivare il debug di WordPress ma stranamente non viene scritto nulla nel file di log. Non mi resta quindi che sperare che al più presto pubblichiate qualche bell’articolo come questo per spiegare bene come attivare e sfruttare al meglio le potenzialità di debug di WP.
    A presto

    Rispondi
    • Eugenio Petullà

      Ciao Alessandro, fatti fare i complimenti per il plugin, da linaro, sistemista e per giunta amante di Qmail mi stai regalando una gioia!*_*

      Veniamo subito al sodo, probabilmente è colpa mia che ti ho fuorviato con l’articolo. Provvederò a correggere a breve e ad ampliare la sezione “Icludere stili e script” perchè in effetti così è poco chiara e in alcuni casi, come il tuo, ti porta fuori strada.

      Ho installato il tuo plugin, il debug funziona e mi ha subito segnalato un errore nell’includere lo stile. Ti consiglio, come ho scritto nell’articolo, di demandare a debug bar l’arduo compito di analizzare gli errori, senza attivare il debug nativo di wp che dipende sempre comunque dal server per quanto riguarda i log.

      Per correggere ti basta sostituire la riga iniziale in cui includi lo stile con questa funzione.

      function spamdyke_register_styles() {
      wp_enqueue_style(‘ietl-box’, WP_PLUGIN_URL.’/ietl-spamdyke/css/style.css’);
      }
      add_action( ‘wp_enqueue_scripts’, ‘spamdyke_register_styles’ );

      Ho creato una funzione in cui registro gli stili e la richiamo tramite un hook in wordpress. Il modo in cui lo hai incluso tu avrebbe funzionato nel caso in cui la funzione fosse stata richiamata direttamente, ad esempio tramite shortcode, in cui dentro la funzione generale ci piazzo anche l’includi lo stile. Nel tuo caso lo stile deve invece essere passato a wordpress tramite un uncino, in questo caso ho sfruttato in momento in cui wordpress include gli script (e gli stili) wp_enqueue_scripts e gli ho aggiunto un’azione (il nome della mia funzione).

      Prova a vedere se così và meglio e fammi sapere! Aspetto un update in dashboard, ancora complimenti! 🙂

      Rispondi
  4. Alessandro

    Buongiorno Eugenio,
    grazie per il supporto. Ho appena variato il plugin nel repository con i tuoi suggerimenti.
    Ho installato debug bar ma stranamente non mi riesce a dare indicazioni sull’errore che ti ho mensionato nel post precedente e che purtroppo ancora persiste (appena ho più tempo per indagare lo fixerò 🙂 ).
    Grazie di nuovo per il tuo impegno per la community e buon fine settimana.

    Rispondi
    • Eugenio Petullà

      Quegli errori li sono i più bastardi perché è difficile debuggarli, essendo errori di output sconosciuti (come ti dice il messaggio). Penso comunque di esserci riuscito sistemando il codice in alcuni punti. Ti ho mandato il pacchetto via dropbox (ti ho scritto una mail), vedi se ha risolto anche per te il problema! 😀

      Rispondi
    • Eugenio

      E’ una dimenticanza da nulla, succede spesso anche a me, non servendomi il content dimentico che qualcuno potrebbe comunque provare ad usare lo shortcode nella maniera non prestabilita, comunque dovrebbe funzionare lo stesso il plugin (proprio per questio poi non ritroviamo l’errore). 😀

      Le parentesi quando stampi in html tramite php puoi farle anche con i caratteri speciali, es. &# 040; aperta e &# 041; chiusa (togli lo spazio). Questo per semplici questioni di leggibilità del codice, le parentesi confondono essendo parte basilare di molti linguaggi di programmazione e in questo modo si capisce al volo che sono parte dell’output html e non parentesi di php. 🙂

      Complimenti ancora e ora che ci hai preso gusto mi manca solo di salutarti e di augurarmi di sentirti al prossimo che svilupperai!

      Rispondi
    • Andrea Barghigiani

      Grazie mille Mario per questo tuo commento, è un’incredibile piacere sapere che il materiale che produciamo è utile ai nostri lettori; sono sicuro che anche Eugenio quando leggerà questo commento farà i salti di gioia 😀

      Continua pure a navigare all’interno di questo sito e se il tuo interesse è rivolto anche allo sviluppo web in generale (e non soltanto a WordPress) ti ricordo che abbiamo da poco aperto una scuola online ricca di corsi di formazione.

      Se poi vuoi entrare in contatto con noi puoi venire a vedere i nostri webinar dal vivo all’interno di questa playlist 🙂

      Rispondi
    • Eugenio Petullà

      Il tuo è il miglor commento che potessi leggere su wpandmore. 😀

      Sono felice che ti sia stato utile, fondamentalmente scrivo per questo e mi baso sempre e solo su esperienze personali quindi spesso mi ritrovo a leggere miei vecchi articoli io stesso per ricordare come ho trovato soluzioni ai problemi che ho incontrato! 🙂

      Rispondi