Data di Scadenza/Pubblicazione in Plone: la guida definitiva

E' una delle funzionalità da sempre presente nel CMS, eppure rimane ancora oggi poco capita dagli utenti e spesso provoca effetti imprevisti.

Stiamo parlando della data di scadenza e della data di pubblicazione di Plone.

Il caso peggiore che può capitare
Mi torna in mente un affascinante concetto letto in un libro sulla storia della crittografia ("Codici e Segreti", ve lo consiglio). Più o meno recitava così:

La sola cosa peggiore di non avere segretezza è credere di averla

Torno subito coi piedi per terra.
Plone ha un potente sistema per rendere i nostri dati segreti e sicuri: il workflow. Quando il workflow è ben configurato e i documenti o le cartelle sono nel giusto stato di revisione, possiamo dormire sonni tranquilli.

La cosa più difficile da capire per un redattore Plone è che le date di scadenza e pubblicazione non influiscono sul workflow!

Dopo tutti questi anni ho spiegato e visto spiegare questo concetto ai redattori molte volte eppure tante volte ho visto questa stessa caratteristica di Plone non essere capita.

E qui ci ricolleghiamo alla frase che ho citato sopra. Assai spesso l'utente crede (sebbene nessuno lo abbia mai spiegato in questi termini) che quando un documento di Plone scade, questo magicamente diventi privato.
Ho visto casi dove, a volte anche dopo anni di utilizzo di un sito in produzione, un redattore scopre che qualche altro utente riesce ad accedere ad un contenuto che non dovrebbe vedere e la loro prima impressione è che sia un baco di Plone (o peggio, un baco dell'installazione data dal fornitore).

Vi siete mai sentiti dire "Ma è scaduto! Perché si vede?!", oppure: "Credevo che diventassero privati!". Ed ecco che entriamo nel caso peggiore... per tutto questo tempo il redattore ha creduto che i suoi contenuti fossero al sicuro, ma non era così!

Per certi versi questo caso è particolarmente sentito per la scadenza dei contenuti, mentre raramente lo è per la data di pubblicazione (o visibilità effettiva). Nel seguito del documento mi riferirò quindi maggiormente al concetto di scadenza ma sia chiaro che quanto verrà spiegato vale anche per i documenti non ancora giunti alla data di pubblicazione.

Badate bene: se c'è una colpa non è dei redattori. Il funzionamento del meccanismo di scadenza/pubblicazione è in effetti difficile da assimilare (e la lunghezza che assumerà questo articolo è quantomai sospetta per poterlo negare... elefantiasi letteraria a parte!  ).

In più, come vedremo poi, è un meccanismo ibrido... in parte usa i permessi (il cuore della sicurezza Plone) ma in modo assai diverso da come i permessi funzionano per tante altre situazioni. Quindi anche gli sviluppatori Plone meno esperti, che magari si sentono già padroni dell'uso del workflow, possono commettere errori.

Prima cosa da capire: scaduto non significa privato
Questo semplice concetto a volte basta agli utenti per poter dire "quindi questo meccanismo non mi serve" perché avrebbero preferito che la scadenza portasse automaticamente all'archiviazione o alla "spubblicazione" del documento.
Consiglio a questi utenti di non abbandonare così precipitosamente questa funzionalità, perché rimane nonostante tutto molto interessante e utile se la si capisce fino in fondo.

Ammettiamo di essere in presenza di un semplice workflow a due stati: privato e pubblicato. Il contenuto privato non è visibile da nessun utente se non il redattore stesso (o il suo team) ma comunque non ai semplici ed anonimi visitatori del sito.
Il contenuto pubblicato è invece di pubblico dominio. Tutti lo vedono, tutti lo trovano (compreso Google).

Poi abbiamo la data di scadenza (o pubblicazione).

Queste due entità (stato di revisione del documento e data di pubblicazione) viaggiano in modo completamente disaccoppiato e non si influenzano in nessun modo. Posso avere tutte e quattro le possibili combinazioni:

• documento privato e ancora valido
• documento privato a scaduto
• documento pubblicato e ancora valido
• documento pubblicato e scaduto

La sicurezza (il workflow) è l'unica cosa certa. Se un contenuto è privato è sicuro. Qualunque sia la data di scadenza poco importa, il documento privato non può essere acceduto direttamente, o tramite ricerche da Google o nel sito. Non ci sono problemi relativamente a scarsa sicurezza in questi casi.

I problemi che potete riscontrare iniziano quando i documenti diventano pubblicati e per questo da ora in poi ci concentriamo su questi casi. Se un documento è pubblicato è accessibile al mondo. Le date di scadenza/pubblicazione servono solo a limitare alcuni tipi di accesso al contenuto.

La prima lezione da imparare è quindi non confondere la sicurezza del contenuto con la sua validità.

Contenuto scaduto significa "non è ricercabile"
Questa è la mia Legge Zero sull'uso della scadenza/pubblicazione in Plone. E' la prima cosa che dico agli utenti quando parlo di questa funzionalità, che sia ad un corso o ad un nuovo redattore (o purtroppo ad uno vecchio che magari non aveva capito).
Ovviamente questa frase non basta... va argomentata! Ma intanto vi fa iniziare la discussione in modo diverso dal più vago "quando un contenuto è scaduto, non è più visibile", che ricorda troppo quello che capita col passaggio allo stato di revisione privato.

Il funzionamento della data di scadenza/pubblicazione è in realtà davvero tutto qui: il contenuto non può essere trovato dal catalogo di Plone.
Questo significa quindi che il contenuto è escluso automaticamente:

• dalla ricerca del sito (base, istantanea, avanzata)
• dal navigatore
• dai risultati delle collezioni
• dalle viste applicabili alle cartelle

Come dicevo, il funzionamento va argomentato un po': l'utente deve capire che Plone usa la ricerca per quasi qualunque cosa venga mostrata nella sua interfaccia. Se è ovvio comprendere questa regola per quello che riguarda la ricerca del sito, è bene accennare al fatto che anche:

• che il navigatore è frutto di una serie di utilizzi del catalogo di Plone
• che le varie viste applicabili alle cartelle eseguono delle ricerche nel catalogo (questo in realtà dovrebbe essere cambiato da Plone 4.0 ma non è cambiato il risultato quindi non complichiamo le cose!)
• che le collezioni non sono altro che "ricerche salvate" e quindi usano il catalogo

Il risultato di questa regola è che il contenuto scaduto, se non per il Manager del sito (il perché lo vedremo poi) risulta sparito.
L'effetto primario per l'utente finale è che in effetti (ad una prima occhiata che spesso confonde i redattori) subisce lo stesso effetto del cambio di stato quando si revoca il contenuto e lo si porta a privato: il contenuto non viene più trovato dalla ricerca, sparisce dai navigatori e dalle viste...

Ma la differenza quindi qual'è?

Google e cronologia hanno la memoria lunga
La differenza è semplice: un contenuto che non può essere trovato non significa sia inaccessibile mentre con l'uso del workflow abbiamo entrambe le cose.

Partiamo da Google, che ha indicizzato il vostro contenuto (in quanto c'è stato un momento nella sua storia dove probabilmente questo era pubblicato e non era scaduto). E' vero che anche i crawler dei motori di ricerca, visitando il sito come utenti anonimi, improvvisamente smetteranno di trovare link al documento in quanto il contenuto è sparito dai navigatori e dalle varie viste.

Ma questo basta per dire a Google di smettere di indicizzare quella pagina e farla sparire dagli archivi?
Ovviamente no! I motori di ricerca (e gli utenti, tramite questi) continueranno ad arrivare alla pagina. Google conosceva l'indirizzo e continuerà ad indicizzare quella pagina a meno che non decida spontaneamente di rimuoverla dall'indice. L'unico effetto certo è vederne calare il page rank, visto che i link a questa pagina saranno meno (o addirittura spariti completamente). Niente più.

A dire la verità forse Plone potrebbe esplicitamente avvertire i motori di ricerca di smettere di indicizzare le pagine scadute (basterebbe un tag META ben scritto... che sia un'ottimizzazione SEO da considerare)?

Senza andare a disturbare Big G, ricordate poi che gli utenti usano browser che sono sempre più avanzati. Oltre ai bookmarks (preferiti o segnalibri), possono contare sulla cronologia delle ricerche, l'autocompletamento, ... E' quindi comunque possibile che gli utenti raggiungano la vostra pagina semplicemente perché ci sono già stati (loro direttamente, o un altro utilizzatore dello stesso browser).

Infine: siete certi al 100% che nel resto del sito, o in un altro sito che non è sotto il controllo vostro o dei vostri redattori, qualcuno non abbia inserito un link alla pagina scaduta? Non l'avete per caso inviata per posta? Ad una mailing list? In un forum?

Capire questo vi eviterà di trovarvi nella situazione di credere che i vostri contenuti, i quali non dovrebbero essere più accessibili, siano spiacevolmente ancora pubblici.

Vorrei che i contenuti scaduti venissero archiviati
Questo è possibile? Certamente, ma va sviluppato qualcosa... a Plone va aggiunto qualche componente.
Un paio di idee:

• un processo esterno chiama Plone ogni ora (o una volta al giorno, magari la notte) e scatena un'operazione che porta i contenuti scaduti allo stato privato
• come sopra, ma li sposta in una cartella privata
• aggiungere a tutti i contenuti del sito un controllo (una viewlet andrebbe bene ma probabilmente non sarebbe troppo elegante...) che controlli se l'utente corrente ha poteri per vedere i contenuti scaduti e in caso contrario lanci l'errore di "Non Autorizzato"

Tutte queste soluzioni sono praticabili ed hanno pro e contro.

Mi serve davvero farlo scadere?
La scadenza di News ed Eventi a mio avviso è nella natura stessa di questi contenuti, quindi sì, probabilmente dovete farli scadere.
Altre volte invece ho visto utenti che volevano fondamentalmente archiviare un documento, mettere una data di scadenza a quello vecchio e pubblicare quello nuovo, per poter avere sempre disponibile la vecchia versione.

A questi utenti ricordo che Plone ha un sistema di versionamento integrato. In questo caso non vi serve assolutamente giocare con la data di scadenza. Semplicemente modificando il contenuto e sostituendo le sue informazioni con quelle aggiornate fa sì che i vecchi dati vengano salvati come "vecchia versione".

Imparare ad usare le date di scadenza e pubblicazione
Ora che abbiamo capito come non intendere il funzionamento delle date di scadenza e pubblicazione e come evitare che il loro uso improprio provochi problemi al nostro sito, non ci rimane che tirare le somme e riassumere come vanno usate.

I documenti scaduti, per la loro natura, perdono grandissima visibilità nel sito e questo è un bene. Come dicevo sopra anche Google viene influenzato dalla sparizione di link che portano a quella pagina, quindi anche la ricerca della stessa risulterà più difficile.

Ma nella mente dei vostri redattori questa deve rimanere una pagina pubblica. Dovete chiarir loro questo concetto in modo definitivo. Il documento ha perso importanza, contiene informazioni non più aggiornate, ma se un utente particolare volesse accedervi potrebbe ancora farlo.
Dovete vedere questa caratteristica come un pregio... se il visitatore vuole leggere una news scaduta, relativa ad un evento dell'anno scorso sul vostro sito, perché impedirglielo?

Purtroppo, nella pratica di Plone questo non è un ragionamento che torna completamente. Plone non permette completamente nemmeno questo (a meno di modificare i permessi, come spiegato sotto): come dicevo sopra, non potete cercare il documento scaduto.

Siamo quindi in presenza di una situazione un po' "a mezza via". Se infatti la vostra scelta è consapevole e sapete come Plone si comporterà col vostro contenuto scaduto (e lo accettate), non è quindi facile per il visitatore del sito tornare a quel documento.

L'assurdità della situazione è che Google può ancora guidare i vostri utenti alla pagina scaduta, la ricerca integrata nel sito no.

Come funziona la "magia" dei documenti scaduti?
Questa sezione diventa un po' più tecnica ma servirà a capire perché succede tutto questo.

Nei fatti non appena il comportamento di Plone diventa chiaro mi sono sentito chiedere varie volte "ma non si può correggere"?
Come dicevo all'inizio, questo comportamento è percepito con un bug. Ma è bene chiarire che non è un bug... forse potrà essere definito un limite del sistema, ma è un comportamento che ha una precisa spiegazione.

Quando eseguiamo qualcosa che scatena una ricerca nel catalogo di Plone (e questo capita decine di volte per ogni click che provoca il caricamento di una pagina), per sapere se quel contenuto può essere trovato dall'utente corrente, viene analizzato uno speciale indice del catalogo dal nome allowedRolesAndUsers. Questo indice ha un comportamento complesso che non voglio approfondire; diciamo solo che contiene, per ogni contenuto, tutte le informazioni necessarie per capire se l'utente corrente (anche il visitatore anonimo), con i suoi ruoli e i ruoli dei gruppi di cui fa parte, può vedere un documento.

Lasciando momentaneamente perdere le ricerche nel catalogo, chiediamoci invece come funziona la sicurezza di Plone: come fa Plone a sapere se un certo utente può vedere un contenuto?

Viene verificato ogni ruolo dell'utente corrente per capire se ad uno di questi è associato il permesso View, che identifica proprio il permesso di vedere il contenuto. Questo (e tutti gli altri permessi che di solito interessano) sono gestiti dal workflow di Plone. Avere questo permesso significa vedere, non averlo significa non poter accedere e ottenere quindi la pagina di errore per accesso non autorizzato (nel caso si tenti comunque di visitarne l'URL).



Lo spostamento del contenuto da stato pubblicato a privato non fa altro che modificare quel valore.



Il numero di ruoli (e anche l'essere Anonimo è visto come un ruolo) che può vedere il contenuto cambia.
Come già detto, la verifica della sicurezza di un oggetto è perfetta e non da problemi, ma le ricerche non funzionano in questo modo.

Le ricerche di Plone non accedono al contenuto vero e proprio per verificarne lo stato di revisione, ma usano l'indice allowedRolesAndUsers di cui parlavamo sopra.
Questo viene fatto per questioni di velocità: accedere al contenuto è una pratica decine di volte più lenta (e più costosa in termini di memoria) che non usare il catalogo. Quell'indice è una traduzione dello stato di visibilità corrente del contenuto (permesso di View) e viene aggiornato ad ogni modifica del contenuto stesso che ne provochi un cambio.

Non esiste quindi un permesso che si occupi dei contenuti scaduti?
Certo! Il permesso è "Access inactive portal content" (letteralmente: "accesso al contenuto inattivo") ma a differenza dello stato di revisione e del permesso di View, questo risente anche di un'altra variabile non controllata da Plone: il tempo.

Per questo non è possibile avere un ulteriore indice (o modificare il comportamento di allowedRolesAndUser) che memorizzi in qualche modo questa informazione perché l'informazione cambia con lo scorrere del tempo.
Non è nemmeno è possibile verificare il permesso direttamente sul contenuto: questa verifica comporterebbe il caricamento del contenuto stesso (e come detto poco fa è un procedimento che rallenterebbe troppo Plone, se immaginato ripetuto per centinaia o migliaia di documenti).

Quindi come viene usato? Nella pratica se l'utente corrente non ha questo permesso, ai criteri di ricerca viene letteralmente iniettato un nuovo criterio basato sull'indice effectiveRange, quindi l'intervallo di tempo in cui il contenuto è valido.
Ma come viene fatta quindi la verifica del permesso? La modifica di questo permesso non ha effetto sui singoli contenuti (e non va quindi usato nel workflow a meno di non introdurre la viewlet poco elegante ipotizzata sopra) ma può essere gestita a livello di sito.
Questo apre nuovi scenari e possibilità... e purtroppo qualche altra incomprensione.

Modifiche di "Access inactive portal content" da valutare
Abbiamo quindi imparato come questo permesso possa essere usato, ed in effetti influenzi la ricerca, sul sito Plone. Ecco infatti il motivo per cui il Manager del sito vede i documenti scaduti.

Ragionando un attimo, potrete arrivare a capire come questo porti anche ad un altro comportamento di Plone poco amichevole. Vi è mai capitato che l'autore di un contenuto (ruolo Owner) non veda più i propri documenti una volta che sono scaduti?
Ebbene... capita. L'utente è Owner sul contenuto, ma non lo è a livello di sito (l'Owner del sito è ovviamente il suo creatore, quindi l'utente Manager principale che di solito ha id "admin").

Questo ci porta in fretta a valutare le uniche due modifiche al permesso "Access inactive portal content" che vi consiglio di valutare.

Chi ha un account nel sito può vedere documenti scaduti
Nella maggior parte dei siti chi ha un account (di qualunque tipo) è un redattore o un revisore di contenuti. Ha quindi senso valutare se dare al ruolo "Member" (il Collaboratore) il permesso per trovare i contenuti scaduti.
Il Redattore A potrà vedere i contenuti scaduti, suoi e anche del Redattore B... ma questo è un problema? Dopo tutto sarebbero comunque accessibili conoscendone l'URL!

In questo modo evitate lo spiacevole caso del "non vedo i miei contenuti".

Tutti vedono i contenuti scaduti
L'interfaccia di Plone evidenzierebbe comunque l'accesso ad un contenuto che è scaduto, mostrando una scritta "scaduto".



Se vi sembra poco, la modifica di questo testo con qualcosa di più "acceso" è semplice.

Dunque perché non valutare se dare questo permesso anche agli anonimi? Otterreste che la ricerca nel sito funzionerà alla pari di Google, trovando di nuovo tutti i contenti pubblici, ma visitandone il dettaglio il visitatore potrà comunque accorgersi che sta accedendo a dati non più aggiornati.
Nota bene: purtroppo perché l'utente anonimo sia in grado di visualizzare quella scritta, come nell'immagine sopra, è anche necessario andare nel pannello di controllo di Plone (sezione "Sicurezza") e selezionare "Consenti a chiunque di vedere le informazioni personali".

Altre combinazioni?
Ci sono in effetti altri casi possibili che potete valutare ma li trovo meno comuni.
Esempio: se la squadra di revisione dei contenuti è unica nel sito (e quindi avete un gruppo di persone che hanno ruolo Reviewer ovunque) allora potreste dare il permesso "Access inactive portal content" a questo ruolo.
Stessa cosa per i contributori (Contributor) e gli Editor... dipende molto dalla dimensione e dalla struttura della vostra redazione, e del vostro sito.

Inno alla Collective

Qualche tempo fa mi è capitata una richiesta da parte di un cliente che al 70% si è rivelata già svolta grazie al lavoro di un'altra azienda (straniera) che produce prodotti Plone e che ha rilasciato il codice.
Fantastico!

Premessa: dato che il discorso che vorrei affrontare qui non è relativo a quel prodotto o a quell'azienda ma è più un discorso di attitudine generale, non scendo nei particolari. Chiamiamoli quindi Prodotto X e Azienda X (e visto che ci siamo, anche Cliente X).

Come innumerevoli altre volte, con soddisfazione ho potuto dire al Cliente X "quello che mi chiedi, Plone (la comunità) te lo offre praticamente già fatto". Soddisfazione sua (che ancora una volta ha capito quanto abbia fatto bene a scegliere Plone nel panorama dei CMS Open Source), soddisfazione mia (che lavoro meno e non devo per l'ennesima volta reinventare la ruota).

Rimane fuori quel piccolo 30%. Il Prodotto X era carente di:

• traduzione italiana (questo capita ancora troppo spesso)
  
• qualche funzionalità aggiuntiva, specifica del Cliente X, che poteva però essere resa una funzionalità generica e riutilizzabile per tutto il Prodotto X.

Aggiungiamo anche un piccolo particolare, ossia che il prodotto era testato (funzionante) solo per Plone 4. Il Cliente X ha una solida installazione Plone 3.3, sono certo che prima o poi passerà a Plone 4 (4.1?) ma senza fretta.
Quindi alla lista sopra, aggiungiamo anche il backport del codice a compatibilità con Plone 3.3.

La Collective
La comunità Plone è fantastica, tra le altre cose, per la sua adesione quasi totale all'uso del repository di codice comune: la Collective.
Raramente lo sviluppatore medio si prende il tempo di andare a cercare nella pagina della documentazione di un prodotto se c'è un link al repository del codice. E' certamente buona norma documentarlo esplicitamente (ne ho già parlato) ma i Ponisti sanno dove andare a trovare il codice.
E' come entrare in una casa di un amico, e questo ti chiede "prenditi pure una birra". La cercheresti fuori dal frigo?

Capita mai che il codice non sia dove me lo aspetto? Certo... è capitato, ma credetemi se vi dico che è un evento talmente raro da potermi dimenticare che alle volte succede!

Quale è stata la sorpresa questa volta? Ovviamente il Prodotto X (che tra le altre cose utilizza il namespace collective.xxx) non era sulla collective.

Digressione
Mi immagino già un certo numero di lettori che a queste prime parole stanno già affilando le armi pensando che questa sia una difesa all'uso di SVN. E' come se già leggessi commenti dire "la collective è roba vecchia, ora è meglio passare a Git".
Non lo nascondo, c'è una recente tendenza di spostare la gestione del codice da Subversion a Git e soprattutto Github.
Se persino il core dello sviluppo Plone si sta muovendo verso questa nuova tecnologia, sono certo al 100% che ci siano ottimi motivi ma qui non si sta parlando di quella collective.

Non deve importare la collective come "scelta tecnologia" ma come "idea": un posto dove lo sviluppatore Plone sappia di poter trovare tutto il codice che gli serve. Un posto dove tutti i plonisti del mondo possano collaborare!

Se poi la collective è un reposiroty di codice fatto con SVN, CVS, Git o come copia manuale del codice... non importa! Se c'è uno standard de-facto, usiamolo. Ad oggi avere il codice Plone sulla collective o su Github, non fa grande differenza!

Torniamo al Prodotto X dell'Azienda X
La mia idea, fin dal principio (e credo sia sempre un'ottima idea) è stata naturalmente quella di:

• tradurre/far tradurre il Prodotto X in italiano
• aggiungere la funzionalità richiesta dal Cliente X in modo tale che fosse generica (la nuova funzionalità stessa ovviamente andava ben tradotta)
• far funzionare il prodotto con Plone 3.3 e superiori (attività banale questa volta)
  

Come si comincia in questi casi? Ecco un semplice consiglio:

Se possibile, non limitiamoci a sistemare in 10 minuti le cose che ci interessano del Prodotto X, magari sul nostro repository di codice privato o tramite patch, ma forniamo agli sviluppatori dell'Azienda X un branch del loro stesso prodotto.

Dopo questo chiediamo all'Azienda X di integrare le nostre modifiche!

Questo consiglio paga? A mio parere sempre. Un branch o una patch applicata ad un prodotto di terze parti che tenete per voi e per il vostro cliente non porterà a nulla.
La sensazione iniziale è di aver velocemente risolto il problema, ma è un'attitudine che guarda molto avanti nel tempo.

Se avessi preso quella strada avrei impiegato meno tempo (non nascondiamolo), ma prima o poi il Prodotto X avrebbe rilasciato una nuova versione (corretto un bug? Aggiornato il codice ad una nuova versione di Plone? Aggiunto una funzionalità?) e io sarei stato costretto ad "inseguire", a riapplicare la patch alla versione successiva del prodotto.
Ecco che quell'ora o due risparmiate oggi diventano quattro ore domani.

La posizione del codice
L'Azienda X esce però dagli standard, commette quindi un piccolo peccato. Il Prodotto X è open source ma il codice non si trovava sulla collective.

Scopro infine che il prodotto è ben documentato e nella documentazione c'è un link al repository del codice: scopro con perplessità che l'Azienda X ha scelto di usare Mercurial e un servizio simile a Github: Bitbucket.

Non so usare Mercurial e non avevo troppo tempo per imparare quei comandi minimi per usarlo tanto da poter creare un branch.
Quello che alla fine ho fatto è stato quindi mandare all'Azienda X un file di patch con le modifiche.
Per arrivare a quel file, quel prodotto finito, ho dovuto fare qualche tentativo in varie direzioni, che alla fine si sono tradotti in... una copia del prodotto nel nostro repository aziendale (questo perché avere il codice sotto controllo di versione permette di tornare sui propri passi con eleganza e velocità).

L'ironia sta tutta qui: la scelta dell'Azienda X di non usare la collective (e la mia incapacità nell'uso di Mercurial ovviamente!) mi ha obbligato ad una serie di operazioni che mi hanno fatto perdere più tempo del dovuto.
Sono convinto che lo sforzo sia stato ben ripagato: la patch è diventata parte del Prodotto X e questo a mio avviso è sempre un buon risultato.

Ecco quindi un nuovo consiglio:

Se il vostro codice è open source ed è nei vostri obbiettivi rilasciarlo, il posto giusto è la collective (+ Github).

L'Azienda Y preferisce un repository interno. Perché?
Sia ben chiaro: lavorare con l'Azienda X è stato molto fruttuoso. La scelta di usare Bitbucket è, come dicevo, un peccato veniale. Il repository era ad ogni modo pubblico e la patch è stata discussa e integrata con estrema velocità.

Esistono motivi per cui un prodotto rilasciato non debba invece rendere disponibile il codice sulla collective?

Non ne trovo. Nemmeno uno!

Non sto dicendo ovviamente che tutto il vostro codice debba essere rilasciato. Sono convinto che una parte di questo (che sia piccola e grande dipende dal vostro tipo di cliente medio) stia bene in posti riservati perché conterrebbe informazioni che riguardano il Vostro Cliente.
La scelta in questi casi è ovviamente il vostro repository, o quello del vostro cliente (nel caso ne abbia uno).

Ma se rilasciate il prodotto, perché non dovreste usare la collective?

Come dicevo, non trovo grandi motivi, ma posso mostrarvi i motivi per cui invece dovreste rilasciare il codice dove tutti possano contribuire.

Fix di bug
Un plonista usa il vostro prodotto e ha trovato un baco. Potrebbe averlo fissato per voi. Una cosa in meno che dovrete correggere voi.
Aggiornamento ad una versione successiva di Plone
Un plonista vuole usare il vostro prodotto e ne crea un branch che lo rende compatibile con una versione di Plone più recente. Quando uno dei vostri clienti, magari gli stessi per cui già avete sviluppato il prodotto, vi chiederanno "funziona con il nuovo Plone", voi potrete dire di sì... e sopratutto dire che qualcun altro ha pagato per quell'aggiornamento. La comunità funziona.
Aggiunta di una funzionalità
Il plonista, di solito tramite un branch, aggiunge al vostro prodotto una nuova funzionalità. Vi pare poco?!
Nuova lingua
Il plonista straniero ama il vostro prodotto e lo traduce nella sua lingua. Il bacino di utenza del vostro prodotto aumenta e con esso la vostra visibilità, o quella della vostra azienda.

Quanto descritto nei casi qui sopra non è qualcosa che ho letto sul "Manuale Etico del Plonista". Sono tutte cose che ho visto succedere... e non una sola volta!

Siate generici, e riciclate
Ecco forse il consiglio più importante.

Il Cliente Y vi chiederà qualcosa di nuovo. La prima cosa da fare è guardarsi intorno. Capire se c'è giù un prodotto che fa al caso vostro. Se lo trovate, Plone (e voi con lui) farete un figurone.

Se questo non accade ma trovate qualcosa di simile, vale quanto detto fin'ora... se la vostra necessità si avvicina al 60/70% o più a quanto fornito da un altro prodotto, valutate se è possibile estendere quel prodotto, o migliorarlo.

Anche in questo caso Plone (e voi) farete una bella figura.

Capitano invece casi in cui dovete praticamente per forza tornare a sviluppare qualcosa di completamente nuovo.

Prima di iniziare a risolvere il problema del Cliente Y a testa bassa pensate se quanto state sviluppando non possa essere reso più generale, e possa quindi essere rilasciato.

Vi è mai capitato, dopo una nuova richiesta, di dirvi "questa richiesta mi è già stata fatta"? Se sì, e non avete reso la soluzione del problema generale, avete perso un'occasione. Il copia/incolla del codice da un prodotto ad un altro non è una soluzione molto mantenibile...

Non inserite un nuovo pezzo di codice "a caso" dentro ad un altro prodotto. Non conta se questa nuova funzionalità vi sembra minima. Spendendo poco in più potreste ottenere qualcosa di prezioso, qualcosa che in futuro potrebbero usare altre persone, ed essere migliorato da altri.

Come già detto: quello che spendete oggi vi ritornerà domani. Investimento!

Prendo un esempio tra i tanti che potrei citare: collective.portaltabs. Questo ricalca perfettamente quando descritto sopra.
Abbiamo incontrato vari utenti che:

• volevano il controllo dei link in testata del sito
• avevano paura (o non avevano i poteri) per accedere alla ZMI

Senza un prodotto apposito l'unica soluzione è accedere alla ZMI ed imparare come fare. E' facile? Lo è certamente per molti di voi, ma l'utente inesperto non ama la ZMI. ZMI è dove nulla è in italiano, dove si possono fare "cose pericolose" e dove le cose non sono per nulla chiare.

Quel prodotto non fa nulla di speciale, ma fa qualcosa che vari nostri clienti hanno richiesto.

Traduzioni
Un altro grande ostacolo al rilascio al pubblico sono le traduzioni del prodotto. La tentazione di partire in quarta scrivendo le varie label e descrizioni della vostra interfaccia grafica direttamente in italiano può essere forte.

Molto spesso quello che si ottiene è quindi un buon prodotto, probabilmente anche riutilizzabile e riutilizzato tra vari clienti e installazioni, ma che non può essere rilasciato pubblicamente.

Le prime volte che vi scontrate con il sistema di traduzioni di Plone può sembrare una procedimento molto lento. Ancora una volta: è un investimento. Ad oggi per me è diventato normale scrivere tutto in inglese e tradurre tutto velocemente alla fine.
Fare le traduzioni dei vostri prodotti in Plone è facile, davvero facile (ho scoperto di recente che con la nuova versione 4.1 non ci sono alcuni problemi che ho riscontrato in questi anni) e richiede un tempo aggiuntivo piuttosto misero.

Se fare questo, il vostro prodotto potrà diventare qualcosa che tutta la comunità potrà riutilizzare ed aiutarvi a mantenerlo.

Plonista avvisato...

I video in Plone: come (e nel modo giusto)

Il Web è cambiato molto, ce ne siamo accorti? Quello che una volta era una collezione di testi collegati tra loro, oggi porta tante altre tecnologie, canali di comunicazione (media) e funzionalità. Nemmeno le immagini sono più sufficienti, e il fenomeno YouTube credo ne sia in gran parte responsabile (se così si può dire).

Se quindi i video diventano, in modo ufficiale, parte dei contenuti del Web e molto spesso il contenuto stesso, tanto vale prendere in considerazione la possibilità che il nostro CMS preferito li supporti!

NB: nel seguito ometto volutamente l'argomento HTML 5, che probabilmente nei prossimi anni semplificherà l'argomento audo/video per il Web ma ad oggi è ancora prematuro.

I video in Plone
Se la necessità è integrare un nuovo tipo di contenuto in Plone o poter vedere un video all'interno di un contenuto Plone, lo standard de facto è usare collective.flowplayer.
Questo prodotto si basa sul diffuso player open source Flowplayer e si installa facilmente in Plone, fornendo alcune funzionalità semplici ma efficaci.

Che cosa fa? In modo intelligente trasforma i file inseriti in Plone (se in uno dei formati compatibili col player) in veri e propri video riproducibili dal Web. La stessa cosa viene fatta anche con i contenuti di tipo Collegamento (ma questa seconda funzionalità la trovo di più raro utilizzo... si tratta di inserire un URL ad un file compatibile).
Altra funzionalità e permettere, previa qualche configurazione, la possibilità di inserire i video all'intero dell'editor WYSIWYG di Plone.

Credo che di articoli di blog su questo prodotto ne siano stati fatti vari, quindi non è mia intenzione soffermarmi oltre, ma prima chiariamo questo punto: ci sono alternative? Altri player video? Ovviamente sì, ma Flowplayer è il più diffuso: funziona bene e forse (ma spero in minima parte) il fatto che...

• il creatore originale sia Martin Aspel
• il creatore di Flowplayer sia anche il creatore delle jQuery Tools, che sono il framework per le interfacce grafiche in Plone 4

...influiscono sulla scelta.

Formati dei video
Avete mai trovato difficoltà nello spiegare ai vostri utenti come non tutti i formati video siano amici del Web? Flowplayer supporta i formati mp4 e flv. Il DivX formato AVI della comunione di vostra nipote non è propriamente un buon formato...

Nel caso quello sia l'unico formato disponibile potete usare un programma di conversione. Ma cosa fare se tutti i video che devono essere allegati partono da un formato incompatibile? Spiegare al redattore come usare un ulteriore software per fare la conversione non è mai un buon modo... la fotocamera dell'utente gli genera un file mpeg. Se non si vede su Web sembra sempre colpa di Plone!

Esiste almeno un prodotto Plone per eseguire la ri-codifica live del video. Installando collective.transcode.star avrete disponibile nel vostro buildout un nuovo demone che si occuperà di convertire i vostri video! Fantastico!

Limiti
Anche se la strada sembra spianata, ci sono alcuni limiti (o potenziali problemi) nel gestire i video in Plone.

Innanzi tutto va tenuto presente come un video sia prima di tutto un "grosso" file. Quando il browser remoto inizia la visione del video (per meglio dire, durante il buffering) il file si muove attraverso la rete. Un video in formato flv può comunque occupare centinaia di megabyte.

Questo porta a qualche problema.

Consumo della memoria
Nelle versioni di Plone precedenti alla 4.0 (non se si è installato a parte anche plone.app.blob) il caricamento da parte di Plone di un file porta anche al caricamento completo dello stesso, che viene messo nella memoria cache del thread che ha servito la richiesta. Per fortuna plone.app.blob evita questo problema (anche su Plone 3).
Anche altri prodotti come FileSystemStorage danno lo stesso beneficio, ma se potete scegliete i blob nativi di Zope.

Lock dei thread di Zope
In una installazione standard di Plone, l'application server sottostante (Zope) è configurato per gestire al massimo 4 thread concorrenti nel servire le richieste degli utenti.

Fintanto che il file intero non viene inviato, quel thread è bloccato nel servire la richiesta. Questo vale sia per l'upload del video che per la sua visualizzazione. L'aumento del numero dei thread non è una soluzione (meglio avere più istanze di zeoclient... ma dovete avere le risorse adeguate).
Questo problema è potenzialmente grave se volete usare Plone pesantemente per la gestione dei video.

Una soluzione, che scarica completamente Plone dal problema di lettura del blob e che quindi si integra con plone.app.blob introdotto sopra, è l'uso di ore.bigfile, introdotto da un ottimo articolo di Aaron VanDerlip. Questo è da tenere presente anche se non state gestendo video in particolare, ma solamente grossi file.
Per riassumere in due parole, questo prodotto sfrutta il Web server Apache (che di solito viene messo davanti ad ogni sito Plone) per lasciare completamente a lui la gestione dell'invio del video (anche in upload). Plone viene solo interrogato per check di sicurezza, poi il file blob viene preso e mandato a client che ne ha fatto richiesta.

Pare purtroppo che questo prodotto non sia rilasciato. Il grado di maturità quindi non è ben chiaro...

EDIT. Da un commento, mi sono accorto che questo pezzo non è stato ben scritto. In Realtà plone.app.blob risolve anche il problema del lock del thread Zope pur non facendo nulla di speciale... Zope ha un modo efficiente di servire questo tipo di situazioni da moltissimo tempo (non ricordo, ma forse addirittura dalle versioni di Zope precedenti all'era Plone), ma per qualche motivo questo metodo non è così ben documentato e noto.

    import os, stat
    from ZPublisher.Iterators import filestream_iterator

    def download(self):
        filepath = '/home/me/VeryBigBigFile.pdf'
        size = os.stat(filepath)[stat.ST_SIZE]
        self.REQUEST.RESPONSE.setHeader('Content-Length', size)
        return filestream_iterator(filepath, 'r')

Cosa succede? Quando nella response viene inserito un oggetto filestreamiterator, Zope sa che deve servire in modo efficiente la lettura della risorsa. Non ricordo i dettagli del funzionamento ma fondamentalmente la lettura viene gestita con un thread separato, e quello di Zope viene quindi subito liberato.

Quindi? Tutto ok?

A mio avviso questo non significa che coi BLOB abbiamo risolto tutti i problemi per rendere Plone la "Uber-Applicazione" di streaming. Come ho detto sopra, ogni istanza Zope è fatta di thread, che quindi vengono eseguiti all'interno dello stesso processo Zope (se non capite bene di cosa parlo, leggete cosa dice Wikipedia).

Un nuovo thread aumenta il lavoro totale che viene fatto dal processo. Ricordate quando sopra dicevo che l'aumento del numero di thread non è quasi mai una soluzione? Il problema è che se la vostra istanza Zope viene eseguita su una supermacchina in stile Multivac, con vari processori multicore, l'istanza (il processo) viene eseguita comunque da un processore. Più istanze (zeoclient) e uno zeoserver invece usano processi (e, se disponibili, processori) diversi.

Per tornare ai nostri blob: il thread non viene bloccato, ma il nuovo thread rende "tutto più lento".

Perché l'approccio di ore.bigfile è migliore? Perché Apache è un'applicazione che nativamente usa processi separati. Far servire il file direttamente ad Apache:

• fa sì che il file non passi, neanche in minima parte, per l'area di memoria del processo Zope
• non aumenta il carico dell'istanza con un nuovo thread
  
• sfrutta Apache, in un processo separato.
  

Consumo della banda
A questo problema non c'è una soluzione pratica e spesso viene dimenticato. Il cliente vi chiede "voglio i video in Plone", ma non ci si ferma a pensare che se questi video hanno successo, è la banda disponibile al vostro sito a risentirne se decine di persone iniziano a guardare i vostri bellissimi filmati. Questo comporta che:

• i video si vedano male (i video "scattano")
  
• la navigazione del resto del sito ne risenta (il sito va lento)
  
• l'attività dei redattori del sito ne risenta (il sito va lento)
  

Non sottovalutate mai l'opportunità di mettere i vostri video da "un'altra parte", su servizi che questo lavoro lo fanno di mestiere. Esempio?

• YouTube
• Vimeo
• ...

Se un account "gratuito" su questi servizi non vi pare sufficiente, valutate anche cosa comporta spendere una piccola somma per comprare un account premium... siete certi che il gioco non valga la candela?

Video esterni: e adesso?
La cosa più semplice in assoluto è configurare Plone per consentire ai vostri redattori di inserire il codice HTML necessario per eseguire l'inclusione del video del sito remoto (teniamo come esempio principale YouTube, ma la cosa vale per qualunque altro servizio).

Dovete configurare i filtri HTML di Plone per non considerare più "cattivi" alcuni tag HTML usati per questo tipo di soluzioni: i tag sono di solito EMBED e OBJECT.

Questo viene fatto dal pannello di controllo di Plone, nella sezione di gestione "Filtri HTML".

NB: c'è un motivo valido, di sicurezza, per cui Plone di base non permette agli utenti di poter usare questi tag... un redattore potrebbe inserire codice malevolo nelle vostre pagine!

Come detto precedentemente la documentazione di collective.flowplayer affronta anche questo argomento. Se siete interessati

Un altro interessante approccio piuttosto recente è un prodotto sviluppato da Quintagroup per interfacciarsi con i servizi di embed.ly.
Usando collective.embedly il codice per l'integrazione con i video remoti viene generato in un modo semplice, non dipendente dalla piattaforma scelta (e ne sono supportate varie) e usando TinyMCE! Del codice Javascript al momento del rendering della pagina "trasforma" i link marcati nel player video corretto! Questo elimina anche il problema di abilitate i tag potenzialmente pericolosi in TinyMCE!
Notevole, ma solo per Plone 4.

Ancora video esterni... ma pur sempre contenuti
Il limite di inserire video esterni nei modi descritti sopra è che il video diventa parte di un contenuto ma non è un contenuto. Non possiamo taggarlo o associargli gli utili metadati che abbiamo in Plone. Non possiamo fornire ai nostri utenti una collezione di video... questo potrebbe essere un grosso limite per la parte redazionale del vostro sito.

Quindi? L'unica soluzione è avere la banda? Non esattamente. In RedTurtle ad esempio abbiamo sviluppato un prodotto, redturtle.video, che fa di nuovo dei video un contenuto. Il prodotto segue espressamente una specifica richiesta di un cliente ed è composto da due contenuti: il tipo "Video Interno" e il "Link a Video".
Mentre il primo è tutto sommato un semplice contenuto costruito sulle funzionalità già date da collective.flowplayer (ma faccio notare una questione di usabilità non da poco: non è semplice capire che per creare un "video" in Plone un utente dovrebbe inserire un "file", come invece è nel funzionamento di collective.flowplayer... l'utente si aspetta che nel menù di aggiunta element ci sia "Video") voglio evidenziare ciò che viene dato da contenuto di tipo link.
In minima parte è, di nuovo, un contenuto costruito su qualcosa che da collective.flowplayer, ma fa anche altro: un po' come collectve.embedly si integra con siti esterni che forniscono servizi video, ma tramite un contenuto simile al link. L'utente inserisce un link a YouTube, oppure Vimeo, e di nuovo abbiamo il nostro player integrato (e tag, correlati, etc...).

Altri prodotti
Prima di cambiare rotta con un argomento parallelo, voglio fare notare come le suite di prodotti nel mondo di Plone non si limitano al solo collective.flowplayer.
Eccone altri:

• Plumi. Praticamente trasforma Plone in un CMS per i Video. Se il vostro target è creare un sito il cui documento principale sono i video, valutate seriamente questo prodotto!
• Plone4ArtistsVideo. Storicamente è stato il primo prodotto che si è occupato di video... funziona ancora... ma il Web è pieno di persone che si sono pentite di averlo installato.
• Plone Video Suite. Progetto interessante e di buone intenzioni. Nasce da alcuni sprint che volevano portare ordine nel caos della situazione video in Plone (probabilmente il ruolo di Attila in questo caos lo ha fatto P4A Video ).
  Purtroppo ad oggi non si sa a cosa porti questo progetto.
  

La panoramica sui prodotti video è finita, ma vi pare poco?

Per quanti riguarda l'accessibilità
Per chi come me l'accessibilità dei siti Web non è solo un'abitudine, ma una necessità quotidiana nel lavoro, sa come inizialmente i requisiti della Legge Stanca (Legge 4/2004) possano a volte sembrare limitanti in maniera piuttosto stringente. In realtà, sebbene sia una legge lungi dall'essere perfetta (e per chi ha lavorato con Plone sa bene cosa significhi il Requisito 1, relativo al codice HTML/XHTML Strict) è comunque una legge "giusta".

Un sito accessibile è quasi sempre un sito ben costruito, e non solo da un punto di vista strutturale, ma anche umano. Sapendo che il sito sviluppato ha tenuto conto, magari anche solo in minima parte, di utenti non vedenti, non udenti o ad altre forme di disabilità dovrebbe farci sentire meglio.

Ecco gli "obiettivi e finalità" della Legge:

La Repubblica riconosce e tutela il diritto di ogni persona ad accedere a tutte le fonti di informazione e ai relativi servizi, ivi compresi quelli che si articolano attraverso gli strumenti informatici e telematici.

Se per quanto detto fin'ora il nostro sforzo è che i video diventino contenuti, i video devono essere accessibili. Ci sono ovviamente requisiti tecnici specifici riguardanti i video e i contenuti multimediali nella Legge Stanca, ma chiediamoci prima di tutto come un video può essere completamente accessibile.

Quali difficoltà ci sono nell'accesso ad un video sul Web?

• Accessibilità dei comandi del video a tutti i dispositivi di input
• Accesso ai contenuti del video a soggetti non vedenti
• Accesso ai contenuti del video a soggetti non udenti
• Accesso ai contenuti del video a soggetti non udenti e non vedenti

Molto di quello che leggere di seguito viene dalla lettura dell'ottimo libro di Michele Diodati: "Accessibilità - guida completa".

Accessibilità dei dispositivi di input
Non esiste solo il mouse, anzi: fingiate esista solo la tastiera! Questa regola non vale solo per i video ovviamente, ma per i contenuti Web, Plone in proposito fa già un ottimo lavoro.
Per l'accesso al video l'attenzione si sposta sul player usato.

Le ultime versioni di Flowplayer dovrebbero aver migliorato la situazione. Uso il condizionale perché non ho avuto esperienze dirette di recente, ma ho solo letto i commenti degli autori alle ultime release.

Tempo fa, essendo rimasto piuttosto affascinato dal mondo dei plugin che girano attorno a Flowplayer, ho sviluppato un prodotto Plone, collective.flowplayer_toolbar, che sfrutta le funzionalità di uno di questi plugin: il plugin della barra di controllo.
Questo prodotto funziona bene anche con le versioni recenti di Plone e collective.flowplayer, quindi nel caso qualcosa nell'accessibilità della barra di controllo Flash non vi piaccia, potete pur sempre usare questo!

Audiodescrizione dei video
E' l'argomento che conosco meno, quindi passerò oltre in fretta.

L'audiodescrizione si occupa dei soggetti non vedenti o ipovedenti. Non fermatevi a questa frase pensando che se il vostro video ha una traccia audio basti il sonoro del video stesso... questo può essere vero per alcuni tipi di filmati (mi permetto di dire a istinto che per un video contenente un'intervista non sia necessaria nessuna descrizione aggiuntiva), ma non è una regola generale.
L'audiodescrizione è un'ulteriore traccia audio che si sovrappone alla prima (ovviamente, senza inficiarne la comprensibilità) e che commenta, magari nelle pause del testo parlato, che cosa succede a video. E' l'audio per le scene dove l'audio non è sufficiente a capire cosa succede.

Non conosco le caratteristiche tecniche sul come realizzare un'audiodescrizione ma credo sia la cosa più complessa da fare per rendere un video accessibile, sia dal punto di vista del tempo investito che per la tecnologia richiesta (soprattutto se il video ha già in effetti una sua traccia audio).
Potrei sbagliare, e nel caso vi invito a correggermi.

I sottotitoli del video
Per qualche motivo più diffusi e conosciuti al grande pubblico (forse siamo tutti figli della pagina 777 di televideo), chi beneficia dei sottotitoli sono soggetti non udenti o in generale con disabilità all'udito che non permettono loro di comprendere i suoni e il parlato.

La soluzione a questo tipo di disabilità sono appunto i sottotitoli. La sottotitolazione di un video è più semplice dell'audiodescrizione, forse perché è più semplice anche da comprendere che cosa va scritto effettivamente scritto.
Le risorse sono anche più diffuse, cito ad esempio l'interessante progetto Universal Subtitles.

Tornando al nostro compagno collective.flowplayer, esiste un ulteriore plugin di Flowplayer per poter visualizzare i sottotitoli nei video: il captions plugin.
Ancora una volta la sua integrazione con Plone è stata piuttosto semplice: lo sviluppo di collective.flowplayercaptions non ha richiesto enormi sforzi se non comprendere bene le API del plugin (piuttosto confuse) e creare un'integrazione non troppo invasiva per i file Plone.

Questo prodotto non fa tutto: è comunque il redattore che deve fornire il file contenente i sottotitoli (supportato è il formato RST).

Il costo in termini tecnologici per ottenere i sottotitoli e basso, ma c'è un certo sforzo in termini di tempo.

La trascrizione testuale del video
La trascrizione video è l'alternativa dove cadono tutti quelli che vogliono tentare di rendere il proprio sito accessibile. E' già qualcosa, ma non si potrebbe fare di meglio.

Chi beneficia della trascrizione video è l'utente sordocieco, che per ovvi motivi non può trovare né beneficio dall'audiodescrizione né dai sottotitoli.
Con la completa trascrizione del contenuto del video, compresi di dialoghi e descrizioni, può invece (sempre attraverso dispositivi hardware specifici) "leggere" il testo scritto tradotto in Braille.

Dal punto di vista tecnico, Plone può fornire una trascrizione testuale ad un video tramite un semplice contenuto correlato, magari ad una semplice pagina. E' ovvio che il redattore deve inserire nel CMS questo documento, ma la sua realizzazione spaventa meno che non fornire un'audiodescrizione o un supporto ai sottotitoli. Per di più si potrebbe pensare "se con questa alternativa supero ben due disabilità, tanto vale limitarsi a questa"! Vero... ma non molto giusto.

E' ovvio che un utente non udente o un non vedente possono accedere beneficiare della trascrizione testuale, ma l'esperienza vissuta è assai limitata. A questo punto perché non rimuovere il video per tutti e fornire solo le trascrizioni?! Vi piacerebbe?

Accessibilità delle risorse esterne
Risolvendo un problema, ne introduco un altro. Possiamo sentirci tranquilli se un video preso da YouTube e inserito nel nostro sito Plone non è accessibile? Dopo tutto la colpa è di YouTube, giusto?

Questo scaricabarile non dovrebbe farci sentire meglio, e per un ente pubblico questa non può essere una scusa valida. Rendere anche i video presi da YouTube (e probabilmente da altri servizi) accessibili si può, ma richiede uno sforzo aggiuntivo.

Un documento con vari interessanti spunti è "Captioning YouTube Video and Providing Accessible Controls".

Conclusioni
I video in Plone, integrati o inseriti come contenuti, sono possibili, che sia un semplice video di pochi secondi ad un intero sito dedicato ai contenuti multimediali.

L'accessibilità dei video è una sfida reale. E' possibile, ma non nascondiamo che sia costosa in vari termini.

Primo post (e funzionalità di blogger)

Ebbene, questo primo post sarà completamente neutrale a qualunque tecnologia, e non vuole nemmeno presentare lo scopo del blog in se.

La mia preoccupazione nel creare un blog era poter mantenere un canale inglese e uno italiano, e contemporaneamente poter segnalare ad una paio di collettori di blog esterni un feed RSS che filtri solo alcuni argomenti di questo blog (in pratica, vorrei poter generare un feed per i tag Plone e Italiano, e Plone e English.

Questo stesso approccio lo abbiamo usato in azienda nel blog di RedTurtle... ed ha funzionato bene a mio parere.

E' possibile fare questo con Blogger di Google? Pare di sì.

La funzionalità non è immediata ma l'ho dovuta cercare in rete. In pratica si tratta di fornire due URL così composti:

• http://blog.keul.it/feeds/posts/default/-/plone/italiano
• http://blog.keul.it/feeds/posts/default/-/plone/english

Il gioco è fatto. Ora come ora i due URL qui sopra saranno vuoti, quindi per dovere di cronaca ne fornisco almeno uno che funzioni:
http://blog.keul.it/feeds/posts/default/-/google/italiano

Ciao a tutti!