Personalizzare i temi grafici di WordPress e rimanere aggiornati
Sto cominciando ad avere confidenza con WordPress e subito mi sono messo a curare la grafica del blog. Innanzitutto ho sostituito il tema grafico (theme) di base con uno un po’ meno spartano. Guardando sul Theme Viewer ho trovato TypoXP, un buon punto di partenza. La licenza del tema permette di modificarlo e così ho fatto, cambiando un po’ la grafica e traducendo alcune parti in italiano.
Ora però se l’autore originale del tema decidesse di produrre un aggiornamento, io mi ritroverei a dover gestire le sue modifiche oltre alle le mie. Se ignorassi le sue modifiche, perderei dei miglioramenti magari utili. Se ignorassi le mie modifiche, perderei le mie personalizzazioni.
E’ un problema comune a tutti i temi di WordPress (e in genere al software scaricato da Internet e poi modificato). Con l’aiuto di CVS, il problema è facile da risolvere.
Innanzitutto bisogna avere CVS (Concurrent Versioning System) installato. E’ disponibile per Windows e per vari tipi di Unix. Il mio esempio si basa su MacOS con shell Bash.
Il mio repository esiste già e si trova in “/Users/predo/cvsroot”. Se dovessi inizializzarlo da zero doveri eseguire:
mkdir /Users/predo/cvsroot export CVSROOT=/Users/predo/cvsroot cvs init
Ora voglio importare una versione del tema TypoXP. Attualmente è disponibile la versione 1.0.3 ma per mostrare il problema degli aggiornamenti, cui ho accennato nel sommario, scarico volutamente una versione più vecchia, la 1.0. Una volta scaricato il file typoxp.zip nella mia home eseguo:
cd /Users/predo unzip typoxp.zip cd typoxp cvs import -m "Import iniziale" typoxp sunaryo_hadi typoxp_1_0
Notate i parametri del comando cvs import. “-m” introduce un commento a piacere. “typoxp” indica il nome scelto per questo modulo. “sunaryo_hadi” è il vendor tag, che indica chi ha prodotto questa versione del modulo. “typoxp_1_0″ è il release tag, che indica in questo caso la versione 1.0 secondo la numerazione dell’autore originale.
A questo punto cvs stampa una lunga lista di messaggi, l’ultimo dei quali è “No conflicts created by this import”. Tutto bene. Ora il modulo è dentro cvs. Posso cancellare la directory e procedere con un checkout.
cd /Users/predo rm -rf typoxp cvs co typoxp
Adesso mi ritrovo nuovamente con la directory “/Users/predo/typoxp” che comprende tutti i file del modulo, oltre alla directory speciale “CVS” creata da cvs durante il checkout.
-rw-r--r-- 1 predo predo 151 Jun 12 19:56 404.php drwx------ 5 predo predo 170 Jun 12 20:53 CVS -rw-r--r-- 1 predo predo 2497 Jun 12 19:56 archive.php -rw-r--r-- 1 predo predo 385 Jun 12 19:56 archives.php -rw-r--r-- 1 predo predo 3985 Jun 12 19:56 comments.php -rw-r--r-- 1 predo predo 446 Jun 12 19:56 footer.php -rw-r--r-- 1 predo predo 923 Jun 12 19:56 header.php drwx------ 45 predo predo 1530 Jun 12 20:53 img -rw-r--r-- 1 predo predo 1311 Jun 12 19:56 index.php -rw-r--r-- 1 predo predo 242 Jun 12 19:56 links.php -rw-r--r-- 1 predo predo 598 Jun 12 19:56 page.php -rw-r--r-- 1 predo predo 14530 Jun 12 19:56 screenshot.png -rw-r--r-- 1 predo predo 1574 Jun 12 19:56 search.php -rw-r--r-- 1 predo predo 276 Jun 12 19:56 searchform.php -rw-r--r-- 1 predo predo 5200 Jun 12 19:56 sidebar.php -rw-r--r-- 1 predo predo 2774 Jun 12 19:56 single.php -rw-r--r-- 1 predo predo 6661 Jun 12 19:56 style.css
Fra questi file riconosco style.css (lo stylesheet CSS), single.php (con le definizioni del testo principale del blog), sidebar.php (con le definizioni di ciò che appare nella parte a destra dello schermo), archive.php (la pagina dei risultati di una ricerca), ecc.
Decido di modificare questi file introducendo varie personalizzazioni. Complessivamente modifico 7 file. Qui per brevità riporto solo un esempio delle modifiche apportate a style.ccs. La seguente riga
body {font: 0.71em/1.5em Verdana, Arial, Helvetica, sans-serif;
color: #333; background: #eee; width: 980px; margin:0; padding:0;}
diventa
body {font: .9em/1.2em Verdana, Arial, Helvetica, sans-serif;
color: #333; background: #eee; width: 740px; margin: 0 auto; padding:0;}
Questa modifica mi permette di aumentare le dimensioni del testo, di restringere la larghezza della pagina e di centrala all’interno del browser. Una volta soddisfatto delle modifiche posso fare commit su cvs.
cd /Users/predo/typoxp cvs commit -m "personalizzazioni"
A questo punto introduciamo il vero problema: ho scaricato (e personalizzato) la versione 1.0 di TypoXP ma ora scopro che esiste una versione più recente (la 1.0.3) che voglio incorporare mantenendo le mie personalizzazioni. Scarico il file typoxp1.0.3.zip contenente la nuova versione ed eseguo:
cd /Users/predo mkdir tmp cd tmp unzip /Users/predo/typoxp1.0.3.zip
Ora la nuova versione è disponibile in /Users/predo/tmp/typoxp ma non è ancora caricata in cvs. Per fare questo devo eseguire un nuovo import, similmente a quanto fatto all’inizio
cd /Users/predo/tmp/typo cvs import -m "Import di 1.0.3" typoxp sunaryo_hadi typoxp_1_0_3
Notate che è cambiato il release tag, che adesso è “typoxp_1_0_3″, che riflette la numerazione delle versioni secondo l’autore originale. Nuovamente cvs stampa una lunga lista di messaggi ma questa volta termina con:
5 conflicts created by this import.
Use the following command to help the merge:
cvs checkout -j<prev_rel_tag> -jtypoxp_1_0_3 typoxp
Seguo il consiglio di cvs ed eseguo:
cd /Users/predo/ rm -rf typoxp cvs co -jtypoxp_1_0 -jtypoxp_1_0_3 typoxp
Notate che come “prev_rel_tag” ho indicato la release tag “typoxp_1_0″. Ho importato solo due release tag, “typoxp_1_0″ e “typoxp_1_0_3″ in questo orine, quindi “typoxp_1_0″ è la release precedente a “typoxp_1_0_3″.
L’ultimo comando stampa una linga lista, in cui individuo una serie di conflitti:
RCS file: /Users/predo/cvsroot/typoxp/sidebar.php,v retrieving revision 1.1.1.1 retrieving revision 1.1.1.2 Merging differences between 1.1.1.1 and 1.1.1.2 into sidebar.php rcsmerge: warning: conflicts during merge RCS file: /Users/predo/cvsroot/typoxp/style.css,v retrieving revision 1.1.1.1 retrieving revision 1.1.1.2 Merging differences between 1.1.1.1 and 1.1.1.2 into style.css rcsmerge: warning: conflicts during merge RCS file: /Users/predo/cvsroot/typoxp/img/verdana-bg.gif,v retrieving revision 1.1.1.1 retrieving revision 1.1.1.2 Merging differences between 1.1.1.1 and 1.1.1.2 into verdana-bg.gif rcsmerge: warning: conflicts during merge
C’è qualche conflitto in sidebar.php, style.css e verdana-bg.gif. Vado nei file e, uno a uno, risolvo i conflitti, che non sono altro che righe che sono state modificate sia da me che dall’autore di TypoXP ma in modi diversi. Per mostrare un esempio, in style.css trovo:
<<<<<<< style.css
body {font: .9em/1.2em Verdana, Arial, Helvetica, sans-serif;
color: #333; background: #eee; width: 740px; margin: 0 auto; padding:0;}
a { color: #0D6AA6; text-decoration: none; }
a:hover { text-decoration: underline; color: #f60;}
=======
/**********************************/
/* General */
/**********************************/
body {font: 0.71em/1.5em Verdana, Arial, Helvetica, sans-serif;
color: #333; background: #666; width: 980px; margin:0; padding:0;}
a { color: #0D6AA6; text-decoration: none; }
a:hover { text-decoration: underline; color: #f60;}
>>>>>>> 1.1.1.2
che risolvo così:
/**********************************/
/* General */
/**********************************/
body {font: .9em/1.2em Verdana, Arial, Helvetica, sans-serif;
color: #333; background: #eee; width: 740px; margin: 0 auto; padding:0;}
a { color: #0D6AA6; text-decoration: none; }
a:hover { text-decoration: underline; color: #f60;}
L’unica cosa a cui prestare attenzione è il conflitto sul file img/verdana-bg.gif. Trattandosi di file binario, risolvo il conflitto decidendo di tenere le mie modifiche:
update -C img/verdana-bg.gif
Ora i conflitti sono risolti. Testo che il modulo funzioni ancora caricandolo sul blog ed eseguo commit su cvs:
cvs commit -m "conflitti 1.0.3 risolti"
Quando un giorno uscirà la versione 1.0.4 (o qualunque altra) del tema potrò ripetere questo procedimento. Anche se piuttosto laborioso all’inizio, sul lungo termine il procedimento risulta vantaggioso, fa risparmiare tempo e riduce gli errori.
Aprile 6th, 2008 13:09
[…] « Commons BeanUtils: accedere ai JavaBean con minimo sforzo […]