Personal tools
Analisi (e modifica) di come Plone genera link ai File: una storia vera (parte 1)

La rete è fatta di URL: meglio se leggibili!

May 03, 2013

Analisi (e modifica) di come Plone genera link ai File: una storia vera (parte 1)

L'esigenza: rendere i link ai file generati in Plone compatibili con software di statistiche e come una serie di prodotti riutilizzabili abbiamo risolto il problema

C'era una volta il File in Plone

Questa Storia parte da un Cliente non molto contento del modo in cui Plone gestisce i file.
Nel caso non lo sappiate, c'è una certa confusione a riguardo.

Se nel vostro sito Plone vi collegate all'indirizzo diretto a un file, nella forma...

http://vostro-host.com/percorso/al/file.pdf

...il file in questione viene "aperto direttamente": gli header inviati da Plone scatenano l'apertura del file "inline", quindi sfruttando eventuali plugin del browser, se presenti.
Questo tipo di comportamento ha problemi di usabilità: utenti che non capiscono di essere ancora "dentro al browser" potrebbero chiudere il browser pensando che si tratti di un programma esterno. Se l'utente poi vuole scaricare il file dal plugin, deve trovarne la funzione all'interno dello stesso.

Eppure se arrivate allo stesso file dall'interfaccia Plone (dal navigatore del sito, da una delle viste, ...) vi troverete a un URL diverso:

http://vostro-host.com/percorso/al/file.pdf/view

Questo è l'indirizzo della vista del contenuto file (file_view) da cui potete vedere alcune informazioni sul file e da dove viene mostrato il link per scaricarlo, che assume invece questa forma:

http://vostro-host.com/percorso/al/file.pdf/at_download/file

NB: per alcuni, passare prima dalla vista del contenuto file è solo una perdita di tempo... e un click inutile. Per altri, se il navigatore facesse scaricare direttamente il file (funzionalità semplice da ottenere con Plone), sarebbe inconcepibile: capirete quindi che non esiste una soluzione universale.

La Storia si complica

Il contenuto File in Plone è uno di quei pochi tipi dove il campo titolo non è obbligatorio.

Partendo da Plone 4 (con l'inclusione di plone.app.blob nel core Plone) è stata introdotta un'altra grossa differenza: prima di Plone 4, caricare un file con e senza titolo non aveva differenze sull'URL generato: l'id del file (che determinava anche l'URL) era sempre lo stesso: il nome del file caricato.
Con Plone 4 il campo titolo è rimasto opzionale ma, se venisse fornito, questo verrà utilizzato per generare l'id del contenuto (come per tutti gli altri tipo Plone).
Se dovessimo quindi caricare lo stesso "file.pdf" con il titolo "Il mio file PDF", otterremmo in realtà questo URL:

http://vostro-host.com/percorso/al/il-mio-file-pdf

TinyMCE (la Storia diventa un gran caos)

Avete mai fatto caso al modo in cui TinyMCE genera link ai file? Li tratta in modo diverso dagli altri contenuti?
No!

Usando il comodo plugin per i link interni, TinyMCE genera un semplice link diretto al file, che per quanto visto sopra è il link che determina l'apertura del file inline.

Vediamo di ricapitolare; la situazione è la seguente:

  • dai navigatori Plone arrivo alla vista dei file ("/view")
  • da questa vista ho disponibile il link per scaricare il file ("/at_download/file")
  • usando link generati dall'editor ottengo l'apertura diretta del file inline.

...ed infine le statistiche

Il colpo di grazia ci viene dato dai sistemi di statistiche che analizzano i log. Esistono infatti software che, analizzando i log degli accessi HTTP, sono in grado di individuare se la risorsa scaricata è un file, e di quale tipo.

Il problema di questo approccio è che nel log HTTP non ci sono molte informazioni se non l'URL (questo è un limite universale dell'approccio... Plone e altri CMS non potrebbero fare nulla per evitarlo); per capire quindi se un dato URL si riferisce ad un file PDF, l'unico modo è sperare che l'URL stesso finisca con ".pdf". Nessun header può fare la differenza qui...

Se torniamo ai file di Plone, avrete notato come da quasi nessuno di questi si capisca che si sta per accedere ad un file PDF:

  • http://vostro-host.com/percorso/al/il-mio-file-pdf
    non finisce con ".pdf"
  • http://vostro-host.com/percorso/al/il-mio-file-pdf/view
    non finisce con ".pdf" ma almeno non mente! Non è un link al file, ma solo una vista
  • http://vostro-host.com/percorso/al/il-mio-file-pdf/at_download/file
    non finisce con ".pdf"
  • http://vostro-host.com/percorso/al/file.pdf
    questo andrebbe bene... peccato che l'unico caso in cui potremmo ottenere questo URL è non fornendo un titolo al file (potreste aggiungere il titolo dopo ma sarebbe troppo scomodo, e dovremmo essere certi che nessuno lo rinomini).

Tanto per essere chiari: il Cliente utilizza uno di questi sistemi di statistiche e si è trovato (giustamente) scontento della grande varietà di URL presenti.

Ci è quindi giusta questa richiesta:

  • "niente attivazione di plugin, i file vanno scaricati"
  • "voglio che gli URL dei file Plone indichino il formato del file".

Fase 1: fermare il problema

Analizzando la situazione, ci siamo resi conto che il comportamento corretto per scaricare file lo abbiamo solo tramite la chiamata a "/at_download/file", che però ha comunque dei problemi:

  • non finisce col nome reale del file
  • non è utilizzata da TinyMCE.

La fortuna ha voluto che il Cliente utilizzasse già da tempo (e con soddisfazione) una variante del plugin dei link a file in Plone: collective.tinymceplugins.advfilelinks.
Se fino ad allora questo plugin si era sempre limitato ad accorgimenti grafici atti ad aumentare l'usabilità dei link (in primis: fornire la dimensione del file che si sta per scaricare), ora poteva tornarci utile per sistemare una delle funzionalità che TinyMCE non offre: scegliere il tipo di link al file.

Abbiamo quindi rilasciato una nuova versione del prodotto che portasse una nuova funzionalità: poter scegliere se avere un link diretto al file (inline), un link alla vista (preview) del file o un link per scaricare il file - tramite un nuovo menù a tendina.

Per questioni di correttezza verso la comunità che già utilizza questo prodotto non sarebbe stato giusto scegliere un valore di default diverso da quello predefinito di TinyMCE, quindi è stato tenuto come valore predefinito il "link diretto al contenuto".
Ma non era nemmeno pensabile che gli utenti del Cliente cambiassero ogni volta quel menù a tendina... è stato quindi usato un prodotto aggiuntivo che "sistemasse" il valore predefinito (funzionalità nativa, prevista dalla nuova versione di collective.tinymceplugins.advfilelinks).

Bene! Ora i link ai file fatti tramite TinyMCE hanno iniziato ad essere link al download reale, tagliando fuori gli eventuali plugin.

at_download, Quel Permissivo

Ma rimane il problema cruciale delle statistiche.

Dopo aver eseguito qualche test ci siamo accorti che la chiamata a "at_download/file" può ricevere altri elementi di percorso senza inficiarne il comportamento.

La cosa forse è un po' strana, ma richiamando un URL Plone in questo modo...

http://vostro-host.com/percorso/al/il-mio-file-pdf/at_download/file/fasullo.doc

... non ottenete errori: L'URL scatena comunque il download del file (e negli header inviati c'è il vero nome "file.pdf"... non preoccupatevi).
Il sistema di statistiche però in questo caso avrebbe (erroneamente) capito che la risorsa scaricata era un file di Word (.doc).

Sfruttando questa "funzionalità" abbiamo reso collective.tinymceplugins.advfilelinks ancora più flessibile, rendendo possibile indicare, tramite un prodotto di terze parti, come generare gli URL nel caso di "URL alla preview" o "URL al download".
Nello stesso prodotto di cui sopra è stato quindi cambiato il valore per il download del file da "/at_download/file" a "/at_download/file/nome reale del file".

Infine, la cosa più semplice: cambiare la vista file_view perché mostrasse lo stesso URL di download modificato. Per fare questo è stato rilasciato un micro-pacchetto: rer.downloadurl.

Ok, missione compiuta: da ora in poi i link ai file saranno amichevoli con il software di statistiche!

... ma i vecchi link?!

Siete curiosi di sapere come finisce? Per ora ho già scritto troppo; per il resto della Storia ci rivediamo martedì prossimo!

Filed under: , , ,
comments powered by Disqus