Aldolat.it — Post con tag Sviluppo

Una pezza per SyntaxHighlighter

aldolat@gmail.com (Aldo Latino) — Sat, 19 Jan 2019 20:21:19 +0000

Con una funzione molto semplice è possibile mettere una pezza al problema del plugin SyntaxHighlighter, che segnalavo qui.

Grazie a @kaggdesign per la condivisione.

L'articolo Una pezza per SyntaxHighlighter è uno scritto di aldolat.it. Rispettane le condizioni di licenza.

WordPress 5, SyntaxHighlighter Evolved e il carattere «&»

aldolat@gmail.com (Aldo Latino) — Wed, 09 Jan 2019 18:24:17 +0000

C’è attualmente un problema, confermato da Alex Mills, a.k.a. @viper007bond, circa il corretto escaping del carattere & in WordPress. Trovate la mia discussione con Alex nel forum di WordPress.

Dalle mie prove sembrerebbe che il problema si presenti solo nei pezzi di codice pubblicati in un post usando il plugin SyntaxHighlighter Evolved. Ad esempio:

Qui ho usato il blocco standard di WordPress per il codice e il carattere è correttamente mostrato.

Qui, invece, usando il blocco del plugin SyntaxHighlighter Evolved, no.

Alex ha aperto un ticket su Github in quanto dipenderebbe da WordPress.

L'articolo WordPress 5, SyntaxHighlighter Evolved e il carattere «&» è uno scritto di aldolat.it. Rispettane le condizioni di licenza.

Facciamo il punto sul mio plugin “Posts in Sidebar”

aldolat@gmail.com (Aldo Latino) — Sun, 06 Jan 2019 09:30:39 +0000

L’ultima volta che ho scritto di Posts in Sidebar è stato il 2 giugno 2013 e, da allora, sono stati fatti tanti rilasci di questo mio plugin. Tante ore spese a scrivere codice, fare debug e dare assistenza nel forum. Nato da un’esigenza puramente personale, il plugin venne pubblicato perché era giusto consentire ad altri di poterne trarre qualche vantaggio e, a quanto pare, viene usato da un po’ di utenti.

Dalla versione 1.7, di cui scrivevo appunto nel giugno 2013, siamo arrivati alla versione 4.7.3. Il plugin è cambiato parecchio e tante funzioni sono state aggiunte: diciamo che l’oggetto WP_Query è abbastanza “alla portata di widget”. Dalla galleria di foto qui sotto (fare clic per ingrandire l’immagine) si vede come il plugin sia cresciuto: nella versione 1.0 le opzioni stanno tutte su una schermata, come anche nella successiva 1.7 anche se aumentate, mentre nell’attuale 4.7.3 sono cresciute a dismisura tanto che stanno quasi tutte racchiuse dentro pannelli e sottopannelli (ogni box verde è un pannello che si espande e si contrae con un clic):

Il pannello delle opzioni di Posts in Sidebar 1.0.

Il pannello delle opzioni di Posts in Sidebar 1.7.

Il pannello delle opzioni di Posts in Sidebar 4.7.3.

A cosa serve questo plugin

I sottopannelli dedicati alla personalizzazione della query.

Questo plugin serve a mostrare nella sidebar alcuni post scelti secondo determinati criteri. Ad esempio:

mostrare gli ultimi post;
mostrare gli ultimi post pubblicati in una o più categorie o in uno o più tag;
mostrare post a caso;
mostrare post a caso ma aventi certe tassonomie (categorie, tag, formati di post, ecc.);
mostrare post con un certo stato (pubblicato, programmato, bozza, in attesa di revisione, ecc.);
mostrare post di un certo autore;
mostrare post con determinati campi personalizzati;
mostrare post pubblicati in certi intervalli di date;
mostrare post risultanti da una ricerca;
mostrare post mediante query complesse di tassonomie;
mostrare un determinato gruppo di post in tutte le pagine e, invece, i post dell’autore dell’articolo corrente quando si visualizza un articolo singolo;
mostrare i post di una delle categorie del post quando si visualizza un articolo singolo;
e altro ancora.

Oltre a ciò è possibile scegliere cosa visualizzare del post: oltre al titolo, si può scegliere se mostrare anche un estratto (o un altro tipo di testo); si può mostrare l’immagine in evidenza, le categorie, i tag, le tassonomie personalizzate, la data, ecc.

Il prezzo di questo plugin

Posts in Sidebar è distribuito gratuitamente nel repository di WordPress ed è pubblicato sotto licenza GPL v3. Chi ha pagato tanto in termini di tempo e fatica sono io, ma l’ho fatto divertendomi. Quando, a volte, in alcune applicazioni disponibili sulla rete vedo la riga che dice Made with love in California (o altrove), ecco ritengo che sia molto vero se penso alla mia esperienza di lavoro sui miei plugin. 🙂

L’assistenza nel forum

Uno dei punti cardine dello sviluppo di Posts in Sidebar è stato il mio rapporto con gli utenti nel forum. Sempre rispettosi dello sviluppatore del plugin, mi hanno chiesto assistenza nell’uso ma soprattutto nell’adattamento dell’aspetto alla grafica del tema. Il plugin, infatti, non ha una grafica sua e visualizza i post senza interporre nulla a livello di CSS (se non quando esplicitamente si attivano alcune opzioni dedicate). Spessissimo mi hanno anche chiesto assistenza su cose che esulavano del tutto dal plugin, ma non mi sono tirato indietro e non li ho mai liquidati con risposte sbrigative, cercando invece di immedesimarmi e di dar loro il supporto richiesto.

Il widget che questo plugin genera è stracarico di opzioni. Molte le ho aggiunte io, nel tentativo di rendere facilmente disponibile a tutti la potenza di WP_Query, ma molte opzioni nascono nascono proprio da loro richieste. A memoria mia credo di averne respinte poche, perché le reputavo interessanti e utili per altri eventuali utenti.

Il futuro dello sviluppo

Ad oggi non ho molto da aggiungere al plugin, perché credo di essere molto vicino al traguardo che mi ero prefissato: poter estrarre i post desiderati dal database e mostrarli in un widget.

A livello di scrittura del codice confesso che mi sarebbe piaciuto programmarlo ad oggetti, ma non ho mai avuto il tempo di imparare. Non programmo per mestiere e guardando il codice si vede, ma oltre non potevo andare.

L'articolo Facciamo il punto sul mio plugin “Posts in Sidebar” è uno scritto di aldolat.it. Rispettane le condizioni di licenza.

Usare Bazaar con un repository centrale su disco esterno

aldolat@gmail.com (Aldo Latino) — Tue, 03 Nov 2009 09:18:41 +0000

Ho sempre usato Bazaar tenendo il database delle revisioni nella stessa directory di lavoro del progetto, e la cosa non è sbagliata perché questo sistema di controllo di versione è stato pensato proprio così. Mi sono sempre trovato bene, ma ciò che mi sarebbe piaciuto era avere un unico archivio centrale dove tenere i database di tutti i progetti (idea che è nata dopo aver provato SVN); precisamente mi sarebbe piaciuto su un disco esterno, in modo da rendere più difficile la perdita dei dati in caso di crash o altro.

In questi ultimi tempi ho anche provato Subversion, che mi è piaciuto per il suo rigore nello struttura delle working directory (branches, tags, trunk) e per la filosofia di repository centrale, che mi è piaciuta davvero. Di contro non mi è proprio piaciuta la consuetudine di infilare una directory nascosta .svn in ogni dove nel progetto. Non ho però una seria esperienza di Subversion per poterlo giudicare, ma mi è apparso comunque un pelino schizzinoso rispetto a Bazaar,¹ che invece apprezzo per la sua facilità e… direi “umanità”, proprio nello stile di Ubuntu, visto che anche lui è sponsorizzato da Canonical.

Con un po’ di pazienza e avendo in mente di creare un repository di progetti su un disco esterno, mi sono spulciato la documentazione ufficiale di Bazaar, in cui ho trovato le informazioni che mi servivano.

Ecco le mie note personali su quello che ho fatto. Non prendetele come una guida all’uso, ma come una condivisione di esperienza che sicuramente ha lati non chiari per me. Anzi, se avete da correggere quanto scrivo, discutiamone pure nei commenti.

Inizializzare il repository centrale sul disco esterno

Sul mio disco esterno USB ho creato una directory bzr-repo, una sorta di contenitore: in essa metterò tutti i progetti, uno in ogni sua sottodirectory:

bzr-repo       # contenitore centrale
+- progetto1   # directory progetto 1
+- progetto2   # directory progetto 2
+- progetto3   # directory progetto 3
...

Questa è l’idea. L’unica directory che ho creato finora è bzr-repo. Le dipendenti le creeremo con bazaar. Da terminale diamo:

bzr init-repo --no-trees file:///media/Golia/Aldo/bzr-repo/

L’opzione --no-trees dice a Bazaar che in quel repository non si terranno le copie di lavoro (working copy) dei file, ma solo il database con la loro storia. Questo comando va dato ovviamente una sola volta per tutti i progetti.

Creare la directory del progetto 1

Quello che segue va fatto per ogni progetto che si vuole collegare al repository centrale.

Inizializziamo la directory del primo progetto:

bzr init file:///media/Golia/Aldo/bzr-repo/progetto1

Questo comando creerà la directory progetto1 con all’interno una nascosta .bzr.

Creare la directory di lavoro locale e collegarla al repository

Col repository abbiamo finito. Passiamo ora in locale e creiamo la struttura delle directory di lavoro (immaginiamo di voler tenere i progetti nella directory progetti nella propria home), quelle in cui terremo le working copy. Per essere chiari, ecco cosa ho in mente di creare:

progetti           # contenitore generale
 +- progetto-uno   # directory principale progetto 1
 |  +- releases    # directory con i tarball dei rilasci
 |  +- trunk       # directory di sviluppo
 |
 +- progetto-due   # directory principale progetto 2
 |  +- releases    # directory con i tarball dei rilasci
 |  +- trunk       # directory di sviluppo
 …```

Questa struttura è quella che ho scelto io: ognuno può organizzarsi come meglio crede. Immagino sia semplice capire l’uso delle directory in base ai commenti.

Passiamo all’opera nel terminale:

cd ~/
mkdir -p progetti/progetto1
cd progetti/progetto1

Colleghiamo (facciamo in realtà il checkout su) questa directory con quella relativa all’interno del repository:

bzr co file:///media/Golia/Aldo/bzr-repo/progetto1/ trunk

Questo comando creerà la directory trunk (quella in cui terremo fisicamente i file di lavoro) dentro progetti/progetto1. Se ora la aprite, vedrete la solita directory .bzr per il controllo.
Passiamo ora in trunk:

cd trunk/

Possiamo già iniziare a creare i nostri file e a lavorare.

Se invece abbiamo già un progetto in corso non ancora sotto controllo di versione, copiamo tutti i file e tutte le directory qui dentro:

cp -ar ~/vecchia-directory/* .

Ora che abbiamo copiato i file, Bazaar ancora non sa cosa siano, quindi aggiungiamoli:

bzr add

e Bazaar li aggiungerà tutti, comprese le sottodirectory e il loro contenuto. Fatto ciò, eseguiamo il nostro primo commit (cioè inviamo il tutto al repository centrale):

bzr commit -m "Primo upload"

che possiamo anche scrivere con l’alias ci:

bzr ci -m "Primo upload"

L’acronimo ci sta per check-in.

Abbiamo finito con l’impostare database e directory di lavoro. Chiunque, adesso, se il disco è accessibile in rete, può scaricare la propria copia del progetto1 e lavorarci; ad esempio, in una rete dove è attiva una connessione SSH, si può lanciare un comando del tipo:

mkdir mia-directory-di-lavoro/progetto1

bzr co sftp://aldo@192.168.1.2/Aldo/bzr-repo/progetto1/

Questo comando si tirerà dietro tutta la storia del progetto. Se non lo si desidera, si può scaricare solo il progetto:

bzr co --lightweight sftp://aldo@192.168.1.2/Aldo/bzr-repo/progetto1/

Commit delle modifiche

I paragrafi che seguono sono soltanto un promemoria rapido per alcune operazioni comuni con Bazaar. Vediamo la principale: il commit.

Dopo ogni serie di modifiche correlate, eseguire il commit con:

bzr ci -m "Descrizione della modifica"

Commit locale se il repository è irraggiungibile

Qualora stiamo lavorando offline, lontano dal disco esterno, possiamo eseguire i commit localmente (cioè nel database locale presente nella directory trunk) e poi inviare tutte le modifiche in una volta al repository. Ecco come cambia il comando:

bzr ci --local -m "Descrizione delle modifiche"

Quando il repository sarà di nuovo raggiungibile, possiamo inviarle così:

bzr update

e quindi il commit

bzr ci -m "Descrizione delle modifiche"

Il comando update esegue il merging delle revisioni, diciamo una “ri-unione” delle versioni tra quelle del repository e quelle del database locale. Questo perché Bazaar considera il lavoro offline come se fosse una nuovo linea di sviluppo (nello screenshot più sotto si vede graficamente questo concetto).

Taggare una versione

Periodicamente è bene taggare (etichettare) una revisione del lavoro, magari in concomitanza di un rilascio. Dalla directory trunk digitiamo:

bzr tag 0.3

Dopo aver taggato una versione non c’è bisogno di fare il commit, che precede quindi il comando di tag.

Esportare il codice in un pacchetto o in una directory

Bazaar consente di esportare facilmente la directory di lavoro in un pacchetto compresso, senza esportare la directory nascosta. Entrare in trunk/ e digitare:

bzr export ../releases/version-0.3.tar.gz

La directory releases deve ovviamente essere già stata creata manualmente prima del comando.

Si può scegliere anche un altro formato di compressione: Bazaar lo ricoscerà automaticamente dall’estensione. I formati sono: .tar, .tar.bz2, .tar.gz, .zip (comprese le forme contratte). Se non mettiamo alcuna estensione, Bazaar esporterà il contenuto in una directory (nel caso di sopra in ../releases/version-0.3/).

Una GUI per Bazaar

Esiste anche una comodissima interfaccia grafica per Bazaar, Olive, che potete installare con apt. Ecco qualche screenshot:

I progetti su Olive e la barra degli strumenti.

La storia delle revisioni di un progetto, con i commit locali (in blu) poi riuniti e i tag.

I cambiamenti effettuati in una particolare revisione.

Photo credits: Williamcho, Bugis Street is not quite the same as what it used to be…, CC by-nc, 2010.

Ad esempio, avevo cancellato un bel numero di file e la loro directory da quella di lavoro. Al momento del commit Subversion mi dice che non potevo eseguire il commit perché questi file non c’erano (o erano obsoleti, onestamente non ricordo). Esisterà un comando per farglieli cancellare dal database pur non essendo presenti fisicamente, ma non ci sono riuscito (diciamo pure che non mi sono impegnato). Bazaar, invece, capisce che quei file sono già stati eliminati dall’utente e permette il commit, eliminandoli automaticamente. ↩︎

L'articolo Usare Bazaar con un repository centrale su disco esterno è uno scritto di aldolat.it. Rispettane le condizioni di licenza.

WordPress 2.8: alcune novità

aldolat@gmail.com (Aldo Latino) — Tue, 21 Apr 2009 08:34:27 +0000

Questa mattina, aggiornando la mia versione di sviluppo di WordPress che provo sotto un server Lampp, ho visto alcune delle novità: mi sono piaciute e le condivido con voi. Non sono entrato in ulteriori dettagli e questo è quello che si scopre in una rapida visita.

Temi: è possibile adesso installare un tema senza passare dall’anteprima. È stata aggiunta una riga di link con cui effettuare le operazioni: Attiva, Anteprima, Cancella (fig. 1).
Temi: è stata aggiunta una pagina sotto Aspetto che consente di installare i temi online, cercandoli in base ai tag del tema (fig. 2): un po’ come già oggi si fa con i plugin. Ho provato a cercare temi con tag “Holiday” e in figura vedete cosa ho trovato (fig. 3).
Editor temi: è stato aggiunto il conteggio delle righe dei file relativi al tema, in modo da individuare subito la riga che si sta cercando (fig. 4);
Widgets: finalmente (!) una gestione dei widgets più facile! Ora è possibile avere sott’occhio tutte le aree dei widget e aggiungerli in modo più semplice e rapido (fig. 5).

Ecco una galleria di screenshot:

Fig. 1: I link per la gestione completa dei temi installati

Fig. 2: La pagina di installazione dei temi

Fig. 3: Il risultato della ricerca online dei temi

Fig. 4: Le righe dell’editor sono ora numerate

Fig. 5: Le aree dei widget

Ma quando sarà possibile riordinare le pagine del proprio blog allo stesso modo di come ora si farà con i widget? 😀 È vero che col plugin PageMash è possibile, ma meglio avere la funzione integrata in WordPress.

L'articolo WordPress 2.8: alcune novità è uno scritto di aldolat.it. Rispettane le condizioni di licenza.