Pinakes 0.7.89 è online. È una versione con due anime. La prima è quella che si vede: un libro che finalmente sa dove è stato stampato, una citazione che si scarica, gli articoli di rivista che si trovano come si trovano i libri, più file digitali sulla stessa scheda. La seconda è fatta di cose che dicevano una cosa e ne facevano un’altra, e che ho scoperto solo andando a ricontrollare lavoro che consideravo chiuso.
Il luogo di stampa, e la citazione che si porta via
Uwe, che usa Pinakes per catalogare articoli e saggi, aveva messo in fila una serie di richieste precise, del tipo che fa chi cita per mestiere. Una delle più semplici in apparenza era anche la più ovvia: una citazione Chicago o Harvard di un libro vuole il luogo di pubblicazione, «Lund: Nordic Academic Press», e Pinakes quel dato non lo aveva proprio. Non era un campo nascosto da qualche parte: mancava la colonna.
Adesso la scheda del libro ha il campo Luogo di pubblicazione. Arriva con una migrazione del database, migrate_0.7.89.sql, che aggiunge una colonna vuota: i libri già catalogati non ricevono un luogo inventato, restano senza finché qualcuno non lo scrive. Il luogo compare nella scheda pubblica e in quella amministrativa, entra nelle citazioni Chicago e Harvard, e nell’esportazione MARCXML finisce nel campo 264 $a, quello in cui un altro catalogo se lo aspetta. Un dettaglio piccolo ma che si nota: se il luogo manca, la citazione non lascia due punti appesi davanti all’editore.
La finestra «Cita» di ogni libro offre ora anche un file RIS, il formato che EndNote, Zotero e Mendeley importano senza fare domande. È costruito dagli stessi dati delle citazioni a schermo, quindi le due cose non possono raccontare lo stesso libro in modo diverso. Accanto ad APA, Chicago, MLA e Harvard c’è anche lo stile Oxford nella variante dell’università di Umeå, richiesto per i lavori di chi scrive in quel contesto.
Gli articoli si trovano come i libri
La ricerca nell’intestazione suggerisce ora gli articoli pubblicati mentre si scrive, non solo dopo aver premuto invio. Nel catalogo, la scheda di un articolo rende cliccabili i suoi autori e la rivista da cui viene. Nella scheda amministrativa, un articolo si collega alla sua testata cercandola per titolo, e titolo e ISSN della testata riempiono da soli i campi ancora vuoti.
Intorno a questo, la sezione dell’emeroteca è stata ricostruita e collegata da un capo all’altro: testata, annata, fascicolo, articolo, con il precedente e il successivo e sempre una strada per tornare indietro. E tutte le pagine pubbliche ora sono montate con gli stessi pezzi: la stessa intestazione, lo stesso percorso di navigazione, la stessa barra dei filtri, la stessa paginazione. Il catalogo, l’emeroteca, gli archivi e gli eventi si leggono come un unico sito, invece che come quattro siti cuciti insieme.
Più file sulla stessa scheda
Un libro può avere ora più di un’edizione digitale, recensioni e articoli collegati, e più tracce audio, ciascuno con il suo titolo e il visualizzatore adatto. I libri che prima dell’aggiornamento puntavano a un singolo file lo conservano. Su questo punto tornerò più sotto, perché è proprio lì che ho trovato uno dei problemi più insidiosi della versione.
Dalle impostazioni del CMS, infine, si possono cambiare il titolo e il sottotitolo del catalogo, lingua per lingua: «Catalogo» e «Scopri migliaia di titoli» erano scritte fisse, e una biblioteca non poteva metterci le sue parole.
Un aggiornamento che non ci sta viene rifiutato prima di toccare qualcosa
Questa correzione ha una storia che mi brucia ancora. Un aggiornamento su un account con lo spazio esaurito si era fermato a metà con il messaggio «Errore nella copia del file: illuminate/support/Str.php». Il pacchetto era integro, verificato in ogni sua parte. Semplicemente il disco si era riempito durante la copia di sicurezza, e il nome nel messaggio era quello del file a cui la copia era arrivata in quel momento: un nome a caso. Ma sembrava un pacchetto corrotto, ed è stato trattato come tale.
Ora l’aggiornamento misura prima lo spazio che la copia di sicurezza richiederà e prova davvero a scrivere, perché sull’hosting condiviso lo spazio libero del disco e la quota dell’account sono due numeri diversi: su quell’account il disco dichiarava cinquantasei gigabyte liberi mentre la quota era a zero. Se non ci sta, si ferma prima di toccare qualunque file. E un errore di copia ora dice la sua causa (spazio o quota, permessi, cartella mancante) invece di un nome di file preso al volo.
Le cose che dicevano una cosa e ne facevano un’altra
Prima di pubblicare sono tornato su ogni commento lasciato dai revisori automatici su tutte e sei le richieste di modifica di questa versione, compresi quelli che avevo già segnato come risolti. Pensavo di non trovare nulla. Non è andata così.
Il caso più istruttivo riguarda le immagini degli eventi. Nelle impostazioni c’erano quattro modi di mostrarle, e due di questi, «piccola a sinistra» e «miniatura accanto al testo», dopo il ridisegno delle pagine finivano per produrre esattamente lo stesso risultato. Li ho uniti. Misurando la copertina per scrivere il test, però, ho visto che non rispettava nemmeno il suo limite di larghezza: doveva fermarsi a 350 pixel e ne occupava 375. Il motivo stava in una regola globale che impone a ogni immagine max-width: 100% !important, e un !important vince su qualunque limite scritto senza. Il tetto c’era nel codice, ma non era mai stato applicato.
Sempre sugli eventi, un’altra svista era ancora più silenziosa. La pagina passava i suoi stili al layout racchiudendoli in un secondo tag , dentro quello che il layout aveva già aperto. Il browser legge quel tag come parte del primo selettore, lo trova incomprensibile e scarta l’intera regola. Così la lista degli eventi perdeva la spaziatura e l’immagine del singolo evento perdeva i suoi margini, senza un solo errore da nessuna parte. Ho scritto un test che controlla tutte le pagine pubbliche, e la prima versione era troppo ingenua: si fermava al primo punto e virgola a fine riga, che è esattamente come finisce ogni riga di CSS. Rifatto leggendo il codice come lo legge PHP, ha trovato subito un altro caso, nella pagina principale: un tag di chiusura orfano presente fin dal primo commit del progetto.
Il problema più serio, però, era nei file digitali. Il vecchio campo a file singolo accettava qualunque percorso del sito e lo mostrava così com’era. Il nuovo elenco di allegati, più rigoroso, accettava solo percorsi sotto /uploads/. Una biblioteca che avesse un ebook in un’altra cartella del proprio sito, dopo l’aggiornamento, lo avrebbe visto sparire dalla scheda pubblica, e non sarebbe più riuscita a salvare quel libro. Ora qualunque percorso dello stesso sito è accettato; restano esclusi i percorsi che puntano fuori, quelli che risalgono le cartelle e le barre rovesciate.
Come l’ho verificata
Le due prove che contano sono quelle che rifà chiunque usi Pinakes. Un’installazione da zero, guidata dal programma di installazione come la farebbe un utente nuovo, seguita da tutta la batteria di prove: 170 superate. E un aggiornamento vero: installare la 0.7.88 pubblicata, poi caricare il pacchetto nuovo dal pannello di amministrazione e premere «Avvia», come si fa in produzione. La migrazione del luogo di pubblicazione è passata per il percorso reale di aggiornamento, lo schema risultante è stato confrontato colonna per colonna con quello di un’installazione nuova, e la batteria completa è passata anche lì. A parte ho verificato che il plugin dei file digitali, passando dalla 1.3.2 alla 1.4.0 su un sito già attivo, crei da solo la colonna che gli serve.
Sono prove lunghe, e in questa versione mi è costata cara anche la pazienza: ogni modifica entrata nel ramo principale ha richiesto di riallineare la successiva e di rifare da capo tutta la verifica automatica. Ma l’alternativa è scoprire i problemi sulle installazioni degli altri, e quella non è un’alternativa.