L’Interfaccia utente completamente ridefinita, con ancora maggiore attenzione ad usabilità ed accessibilità, è solo il più evidente dei molti vantaggi della prossima versione di Plone.
Abbiamo riunito tutti gli RSS che parlano di Plone.
Vuoi aggiungere il tuo blog al planet? Invia una mail alla lista italiana.
Ultimo aggiornamento: 01/08/2014 13:45:15
Il video del Plone Open Garden 2014: tutto il PLOG in 2 minuti
Giunto alla sua ottava edizione, anche quest’anno il Plog, che si è tenuto a Sorrento dal 22 al 26 Aprile 2014, ci ha regalato grandi soddisfazioni
Manuale Plone 4
Il manuale per editori e manager di contenuti del nostro CMS di riferimento, nel comodo formato ePub
Plone e risorse JavaScript/CSS: alcuni consigli per buone prestazioni
Di recente siamo stati incaricati di occuparci dell'ottimizzazione di front-end di un sito Plone. Il lavoro è stato svolto sotto molti aspetti, ma nel seguito di questo articolo mi occuperò solo di uno dei recenti mantra che sta imperversando nel web relativamente all'ottimizzazione del front-end: limitare il numero di connessioni HTTP della pagina.
Perché? In poche parole: per quanto la risorsa sia piccola o grande, il problema è la connessione alla risorsa e i tempi di latenza che questa introduce.
Stato del sito
Il sito in questione ha una storia piuttosto lunga, è in produzione da anni; questo si traduce spesso in una lunga lista di prodotti aggiuntivi installati e modifiche varie effettuate al tema grafico o ai prodotti aggiuntivi stessi.
Altra caratteristica importante: è un Plone 4.2, ma la sua storia è iniziata con la versione 3.3. Si è passati attraverso un processo di migrazione della versione di Plone.
Infine: il tema grafico, anche se migrato a Plone 4, è fondamentalmente fedele al vecchio stile della realizzazione Plone 3 (in due parole: no Diazo).
Strumenti utilizzati
Per testare le prestazioni di front-end di un sito (qualunque sia la tecnologia) ci sono vari strumenti disponibili sia come estensioni dei più noti browser (YSlow, Google PageSpeed), sia come strumenti online (GTMetrix, PageSpeed Insights).
Il primo consiglio che posso darvi è: provateli tutti, e magari utilizzatene più di uno.
In forma diversa, tutti questi strumenti testano più o meno le stesse best practice, indicando un voto per ognuno dei punti verificati e fornendo delle spiegazioni sul problema rilevato e su come affrontarlo.
Solitamente alcuni punti sono considerati ad alta priorità (quindi errori gravi o accorgimenti che possono dare grandi benefici), mentre altri possono essere considerati peccati veniali.
Tornando all'argomento di questo articolo: questi strumenti avevano individuato un problema relativo all'eccessiva presenza di risorse CSS e JavaScript caricate.
Stiamo parlando di:
- 22 CSS
- 14 JavaScript.
ResourceRegistries
Che siano amati od odiati (varie persone nella comunità Plone pensano che la loro introduzione non sia stata una grandissima idea), ad oggi l'uso dei tool portal_css e portal_javascript è il metodo principale per permettere a prodotti aggiuntivi e temi grafici di registrare risorse.
L'uso di Diazo dovrebbe mitigare notevolmente questa necessità, ma credo che nel futuro prossimo questi due tool rimarranno comunque qualcosa con cui dovremmo convivere.
Il loro lavoro è piuttosto importante:
- raccolgono tutti i JavaScript/CSS registrati, rispettando un dato ordine
- permettono di includere delle condizioni di inclusione basate sullo stato di autenticazione dell'utente ("Restrict to authenticated users?")
- permettono di inserire condizioni di inclusione basate su un'espressione ("Condition")
- permettono di fornire i commenti di inclusione condizionali (funzionalità utilizzabile solo da Internet Explorer)
- permettono di specificare se la risorsa può essere messa nella cache del browser utente ("Caching allowed")
- effettuano una minificazione della risorsa ("Compression type", seppur non ottimale se confrontata con altri servizi)
- permettono di specificare il tipo di media e il rel type (solo CSS)
- permettono di specificare la modalità di inclusione nella pagina ("Render type" per CSS e flag "Inline rendering" per JavaScript)
- raggruppano più risorse per poter fornire un'unica risorsa da scaricare, riducendo le connessioni HTTP effettuate (flag "Merging allowed")
- Permettono di definire dei "bundle" logici di risorse ("Bundle").
... aspettate! Ma quindi dove starebbe il problema? Non basta verificare che il flag "Merging allowed" sia sempre attivo? Fantastico!
Limiti dei ResourceRegistries
Com'era possibile che, seppur utilizzando questi due tool, le risorse richieste dalla home page del sito fossero così tante? Il raggruppamento quindi non funziona?
Il problema nasce da alcune delle funzionalità che portal_javascript e portal_css offrono e che ho messo in evidenza nelle immagini sopra, aggiungendovi un numero in rosso. Chiamiamole "configurazioni cruciali" da qui nel seguito, e con questo intendiamo che tali configurazioni possono influire sul numero di risorse fornite.
Vediamo come.
La regola principale di questi due tool sta nel rispettare l'ordine delle risorse fornite: che siano fogli di stile o sorgenti JavaScript, l'ordine di esecuzioni conta (soprattutto per gli script, dove la questione diventa delicata).
In una situazione semplice/ideale, quando abbiamo qualcosa come cinque risorse tutte egualmente configurate, il raggruppamento funziona senza problemi.E' sempre possibile tenere sotto controllo lo stato del raggruppamento dal tab "Merged CSS Composition" e "Merged JS compisition" dei due tool.
La logica del raggruppamento è però applicabile solo se c'è eguaglianza delle condizioni delle risorse registrate. Se, all'interno della sequenza di risorse fornita, una di queste ha una delle configurazioni cruciali differente, la sequenza viene spezzata.
Facciamo un esempio: se una risorsa è definita come non gestibile dalla cache del browser (ma lo stesso vale per tutte le altre configurazioni cruciali), questa dovrà essere inviata al browser con un header HTTP differente dalla sequenza di risorse che la precedono o che la seguono. Questo spezza la sequenza.
Ammettendo di avere una serie di 5 risorse come in figura, se la risorsa numero 3 ha una configurazione differente dalle altre quattro presenti, ResourceRegistries non potrà fare altro che generare ben 3 risorse differenti:
- una prima risorsa contenente l'unione tra 1 e 2
- una seconda risorsa contenente la sola 3
- una terza risorsa contenente 4 e 5.
Da qui è facile capire come si possa arrivare a un alto livello di frammentazione, visto l'alto numero di configurazioni cruciali presenti e le loro possibili combinazioni.
Problemi comuni riscontrati
Dei molti possibili scenari che l'analisi sopra può avervi suggerito, vale la pena sottolinearne alcuni che reputo quantomeno interessanti.
Risorse per utenti autenticati o con condizioni
In linea di principio la restrizione delle risorse dovrebbe migliorare le performance: sembrerebbe logico supporre che sia inutile fornire a un utente anonimo un pezzo di codice JavaScript/CSS (che il suo browser interpreterà), se questo poi non verrà effettivamente utilizzato.
Eppure questo può non essere vero e può addirittura peggiorare le performance per utenti anonimi e autenticati!
Tornando alle 5 risorse dell'esempio sopra, se ammettiamo che la ricorsa C abbia il flag per la restrizione a utenti autenticati attivo, gli utenti autenticati otterranno 3 risorse differenti... e gli utenti anonimi 2.
Perché gli anonimi non ricevono una sola risorsa? Il ResourceRegistries non è così avanzato da "unire" due gruppi (AB + DE) se la risorsa che ha spezzato il flusso non viene nei fatti fornita; questo significherebbe avere configurazioni differenti potenzialmente per ogni utente.
Fate quindi attenzione: non sempre vale la pena impostare condizioni per evitare che la risorsa arrivi all'utente finale. Tenete presente sempre che la risorsa potrebbe essere compressa e accorpata con altre risorse e l'effettivo guadagno sarebbe quindi minimo, estremamente inferiore al dover scaricare una risorsa aggiuntiva (ricordate che la latenza è il nemico).
- Se la risorsa è un CSS: forse vale la pena scrivere un CSS sempre incluso, ma con delle regole tanto specifiche da applicarsi solo ai template corretti (le classi aggiuntive aggiunte al tag BODY aiutano moltissimo).
- Se la risorsa è un JavaScript la questione è più delicata, ma si potrebbe lavorare per interrompere in fretta l'esecuzione di codice costoso se non applicabile alla pagina corrente, o usare altri meccanismi di lazy loading.
Nessuna delle regole sopra va presa come oro colato... la valutazione dei costi e benefici dipende dalla vostra installazione e dalle risorse in esame.
Uso di "import" come "Render type"
I tutorial in rete che dicono di non usare la direttiva @import per includere i CSS si sprecano. Per ragioni che si perdono nelle nebbie del tempo, Plone 3 utilizzava massivamente questo modo di includere CSS, mentre recenti prodotti aggiuntivi e versioni di Plone preferiscono (giustamente) link.
Come già detto, il sito in esame veniva da una migrazione da Plone 3. Ci si è quindi accorti che la migrazione non aveva modificato il render type: ci siamo trovati con un uso massiccio di @import... Anche ignorando i consigli di evitare l'uso di @import, ricordate che il rendering type è una delle configurazioni cruciali!
Quindi, non mischiate import e link: l'unico effetto che otterrete è quello di spezzare la sequenza.
Risolvere i problemi del sito
Il lavoro svolto per ridurre quel grande numero di connessioni è stato prettamente manuale e di analisi:
- si è tentato di ridurre al minimo le condizioni di inclusione
- si è tentato di riordinare le risorse (con le dovute attenzioni) perché ci fossero due blocchi di risorse: una per tutti e una per gli autenticati
- altre condizioni di inclusione particolari sono state valutate meglio, ed eliminate
- sono stati modificati i render type dal misto di @import e link al solo uso di link.
Il risultato finale? Riferendosi alla sola homepage del sito sì è passati da 22 a 2 CSS, e da 14 a 2 JavaScript!
Ma un Plone "base" come si comporta?
Ci si potrebbe aspettare che i problemi del sito in esame fossero dovuti alla sua lunga storia e all'alto numero di prodotti aggiuntivi, e questo è innegabile.
Un Plone 4.3 "base", appena uscito dalla fabbrica, sarà ovviamente tutt'altro che mal configurato, giusto?
Eppure anche qui non mancano le sorprese!
CSS
Come si vede nella figura precedente, ci sono 7 CSS... eppure sarebbe possibile fare di meglio!
- Se member.css fosse incluso prima del reset.css, quest'ultimo si accorperebbe col blocco che segue
- plone.app.jquerytools.dateinput.css delle jQueryTools usa il metodo di inclusione import e non link
- ploneCustom.css deve sempre essere l'ultimo della sequenza... ma se non lo usate (non avete modifiche TTW attive): perché non disattivarlo?
- RTL.css è il supporto per le lingue arabe e si attiva solo in ben determinati casi, ma verificare che venga incluso dopo plone.app.jquerytools.dateinput.css così da non interrompere il suo accorpamento
- IEFixes.css: verificate che non rompa nessuna sequenza.
Così facendo potremmo migliorare la situazione come segue:
JavaScript
La situazione dei JavaScript di un sito Plone 4.3 base è già ottimale!
Dall'accorpamento otteniamo solo due JavaScript, col secondo blocco riservato agli utenti autenticati, ma i problemi potrebbero iniziare molto presto, non appena l'installazione dei prodotti aggiuntivi ha inizio.
Se un prodotto registra un nuovo JavaScript lo metterà probabilmente in fondo (comportamento di default) e se questo fosse ad uso di tutti gli utenti, verremmo a creare un terzo blocco. In questo caso andrebbe invece spostato alla fine del primo blocco.
Conclusione
L'ottimizzazione di front-end di un sito Plone è un'attività tutto sommato semplice, ma come avrete capito è qualcosa che va mantenuto e monitorato nel tempo.
Spero di avervi incuriosito abbastanza da farvi correre a controllare lo stato del vostro sito! Potreste individuare in fretta ampi margini di miglioramento :)
Report dal Plone Mosaic sprint di Barcellona, ecco i risultati.
Mosaic vuole offrire a utenti e sviluppatori del cms Plone un modo di composizione delle pagine più potente e flessibile.
Breve resoconto dal PLOG 2014
Alla sua ottava edizione, il Plone Open Garden ha visto una grande partecipazione della comunità internazionale, che ha dato vita a cinque giorni intensi di talk, sprint e open space.
Il World Plone Day 2014 a Bologna
Un breve resoconto del WPD che si è tenuto a Bologna. Un evento incentrato sull'uso di Plone
nella Pubblica amministrazione.
Il mio World Plone Day 2014
Per il quarto anno consecutivo la regione Emilia Romagna ha organizzato il World Plone Day e quest’anno, per la prima volta, ho partecipato anch’io all’evento presentando il caso d’uso dell’Università di Bologna.
“Pubblica amministrazione” è la parola d’ordine nel World Plone Day bolognese; gli interventi sono infatti incentrati su questo argomento e vengono presentati diversi casi sull’utilizzo di Plone nella pubblica amministrazione italiana.
La giornata è divisa in due sessioni: la prima comincia alle 9:30 alla “Terza torre” in Fiera a Bologna ed è la parte dedicata ai Talk.
La Regione Emilia Romagna, fedele da diverso tempo a Plone, ci racconta i suoi pensieri e l’importanza del software libero e della community, anticipando quelli che poi saranno gli argomenti principali nel pomeriggio.
Segue il talk di Unibo, cioè il mio, dove presento l’esperienza della nostra Università che ha adottato Plone con successo dal 2012. Attualmente Plone è utilizzato su un’ottantina di siti dell’ateneo, tra cui il portale principale.
Continuamo con MoInMo un’applicazione presentata dal comune di Modena per la valorizzazione del centro storico della città.
Un ottimo Coffee break per fare due chiacchiere e poi si ricomincia.
E’ il turno di RedTurtle che presenta iopartecipo+ un servizio realizzato per la Regione Emilia Romagna, in cui Plone si tinge di social per il confronto tra i cittadini su diverse tematiche.
GisWeb ci racconta del servizio realizzato per il comune di La Spezia con cui gli utenti possono segnalare disagi e problemi in giro per la città.
E’ il turno di Abstract che ci parla di migrazioni con 70000 oggetti migrati all’interno di un portale Plone nel loro caso d’uso su ISPRA,.
I talk si concludono con la presentazione del regalo che tutti noi vorremmo sotto l’albero di Natale quest’anno: Plone 5.
Dopo un pranzo veloce si comincia con la sessione pomeridiana in cui RedTurtle cambia la parola d’ordine in “Community”.
Vengono raccontati quali sono i luoghi, reali o virtuali, in cui si può incontrare la comunità Plone, come interagire, come documentarsi, come partecipare e quali sono in vantaggi di avere una community solida come la nostra.
Il tutto si conclude con un ottimo aperitivo :)
Ringrazio sia la regione che RedTurtle per l’organizzazione dell’evento.
Ci vediamo al prossimo World Plone Day.
Le slide del mio intervento le trovate a questo link: http://www.slideshare.net/valentinabolognini1/plone-alluniversit-di-bologna-il-portale-e-il-multilingua
Come riscaldare la cache del nostro CMS con collective.warmup
collective.warmup è uno strumento che consente di riscaldare la cache di un sito web leggendo un file di configurazione e passando in rassegna una serie di pagine in maniera automatizzata.
Webinar 1 - Introduzione a Plone, il CMS scritto in Python
Il primo webinar Abstract del 2014, dedicato al nostro amato CMS Plone.
Gestione avanzata keyword con Plone - appendice (molte keyword)
Appendice finale alla serie di articoli "Gestione avanzata keyword con Plone". Argomento: grossi portali e widget autocomplete
[solved] AttributeError: type object ‘IThemeSpecific’ has no attribute ‘isOrExtends’
Il Grande Capo Estiqaatsi direbbe: – eh, grosso problema ora c’è -“. Il problema si manifesta nel caso in cui disinstallate un prodotto del quale avevate customizzato una sua viewlet… qualcosa del tipo: 1) installo mio.prodotto 2) customizzo da zmi -> portal_view_customizations una viewlet di mio.prodotto 3) disinstallo il mio.prodotto (ach! ho dimenticato di cancellare […]
Il Grande Capo Estiqaatsi direbbe: – eh, grosso problema ora c’è -“. Il problema si manifesta nel caso in cui disinstallate un prodotto del quale avevate customizzato una sua viewlet… qualcosa del tipo: 1) installo mio.prodotto 2) customizzo da zmi -> portal_view_customizations una viewlet di mio.prodotto 3) disinstallo il mio.prodotto (ach! ho dimenticato di cancellare […]
Migrazioni e sorprese: cose che bisogna saper gestire
Oggi voglio condividere con voi un piccolo problema e relativa soluzione capitati pochi giorni fa lavorando a una migrazione da Plone 3 a Plone 4
Diversi giorni dopo aver terminato la migrazione, preparando i contenuti per il nuovo portale, mi sono ritrovato a navigare un'area di contenuti basati sullo stesso tipo di documento di altrettanti già verificati, per cui non mi aspettavo nulla di strano e problematico. Invece...
Il problema
Invece mi sono trovato sul monitor una pagina bianca con scritto (riassumendo) "broken object"! Cosa può essere successo? Problemi nella migrazione? Codice non aggiornato correttamente alla versione Plone 4? Codice completamente mancante per quei tipi di oggetto?
Nel mio caso, si trattava di una versione non aggiornata del prodotto "incriminato": durante il porting a Plone 4, non essendo presente la classe da cui è stato istanziato l'oggetto in questione, il risultato è stato una procedura di migrazione che non ha prodotto errori (non bloccanti quantomeno, magari qualcosa nei log era indicato) e un oggetto corrotto nel sito.
L'errore
In console, in corrispondenza della navigazione sull'oggetto corrotto, l'unica cosa che ho potuto vedere è stata:
Traceback (innermost last): ....... Module plone.app.folder.base, line 65, in index_html Module plone.folder.ordered, line 202, in __contains__ TypeError: argument of type 'NoneType' is not iterable
Mentre cercando di visitare la stessa sezione in zmi:
Traceback (innermost last): .......... Module Products.BTreeFolder2.BTreeFolder2, line 332, in objectCount TypeError: 'NoneType' object is not callable
Bene. L'errore indica un problema con oggetti di tipo folderish e come ben sappiamo (o dovremmo sapere) ci sono stati profondi cambiamenti nella struttura delle cartelle da Plone 3 a Plone 4.
Questo mi ha indicato che il problema risiedeva proprio nell'implementazione delle nuove cartelle e nel fatto che quelle corrotte nel sito non sono state migrate correttamente.
Facciamo pulizia
Vediamo come fissare la situazione. Uno degli step di migrazione da Plone 3 a Plone 4 è, appunto, la migrazione delle cartelle.
Controllando il codice, si può verificare che questa migrazione è ottenuta chiamando una vista sulla radice del sito: "@@migrate-btrees" presente dentro al pacchetto plone.app.folder.
Questa vista, fra l'altro, non è necessario chiamarla nella radice del sito perché, come si può vedere nel codice, l'analisi degli oggetti viene fatta a partire dal contesto in cui la vista viene chiamata.
....
for path, obj in findObjects(self.context): if isinstance(obj, BTreeFolder): if self.migrate(obj): processed += 1 cpi.next() self.postprocess(obj)
....
Una volta terminato il processo di migrazione delle cartelle, queste ancora non compariranno navigando il sito, ma il più è fatto. A questo punto, infatti, basta fare un update del catalogo oppure indicizzare nuovamente almeno i contenuti di quella cartella.
Immagini di http://www.flickr.com/photos/photowest/
Integrazione degli Icon Font in Plone, in modo accessibile
Sempre più i siti Web moderni abbandonano l'uso indiscriminato di icone per sostituirle con la tecnica degli icon font.
Guardiamo ad esempio la barra dei comandi di GitHub (un sito sempre aggiornato per quanto riguarda le tecniche di front-end). Credete ci sia anche solo un'immagine qui?
Da profano, posso spiegarvi la tecnica in due parole: sfruttare CSS (e la direttiva font-face) per mostrare un carattere Unicode all'interno del testo.
Dato che si parla di Unicode, ci sono centinaia di simboli che possono sembrare icone, eppure dopo tutto stiamo pur sempre parlando di caratteri! ☼ ✰ ⌂ ♥
Bello, eh?
La mia (inizialmente poca) attenzione sull'argomento parte col rilascio del prodotto di integrazione tra Plone e FontAwesome.
Il prodotto di per sé non fa molto, se non registrare in Plone i CSS di FontAwesome all'interno di Plone, e nulla più.
Sta poi allo sviluppatore/grafico utilizzare o meno queste nuove regole nei propri template, mentre non c'è nessun supporto all'abilitazione di questi nuovi stili all'interno di TinyMCE.
E' l'accessibilità?
Qualche tempo fa mi sono imbattuto nell'articolo Bulletproof Accessible Icon Fonts in cui si parla dei problemi di accessibilità che questa tecnica può introdurre (e qui la mia attenzione si è fatta più viva!).
Il problema è fondamentalmente legato a come gli screen reader interpretano questi caratteri. Vediamo un esempio:
<p>E' nata una <span class="icon-star">stella</span></p>
Il carattere "stella" () potrebbe semplicemente venire letto come "Black Star" ed essere quindi completamente incomprensibile e al di fuori di ogni contesto.
Se questo utilizzo ha una funzione puramente decorativa, lo screen reader dovrebbe passare oltre. Purtroppo pare che il supporto alla regola CSS "speak: none" sia ancora molto limitato.
Ci sono alternative?
L'articolo descrive come strada meglio percorribile l'uso di ARIA, nello specifico l'applicazione di aria-hidden. Lo scopo dell'attributo è marcare in modo esplicito l'elemento come "nascosto" e la tecnologia assistiva (se supporta ARIA, cosa a dire il vero non scontata) lo ignorerà.
<p>E' nata una <span aria-hidden="true" class="icon-star">stella</span></p>
E ora torniamo a Plone!
Dopo aver letto l'interessante articolo mi sono chiesto come poter rendere accessibile il prodotto collective.fontawesome con la tecnica qui sopra descritta.
Pare che le cose da fare non siano poche, quindi prendete il codice che seguirà come un "proof-of-concept" piuttosto che qualcosa di definitivo!
Aggiunta di stili a TinyMCE
Innanzitutto, come detto poco fa, collective.fontawesome si limita all'aggiunta dei CSS in Plone, ma non c'è nessun aiuto per l'utente che utilizza l'editor TinyMCE di Plone per poter usare questi nuovi stili.
La soluzione in questo caso è semplice: aggiungere alcune nuove opzioni nella configurazione degli stili del sito:
Fatto questo, gli utenti potranno selezionare del testo dell'editor ed assegnargli lo stile voluto.
Intercettare e correggere l'uso di icone
Per sistemare l'accessibilità del testo andrebbe quindi applicato l'attributo ARIA a questi elementi. L'idea è quella di intercettare le modifiche fatte al testo (evento onChange di TinyMCE), ma purtroppo in Plone tutto questo non è molto semplice.
L'inizializzazione dell'editor (fatta dal Products.TinyMCE) non permette facilmente di aggiungere dei callback agli eventi lanciati dall'editor.
Dobbiamo quindi modificare il codice di Products.TinyMCE perché venga lanciato l'evento, oppure (in modo meno invasivo) agganciare l'evento con questi semplici comandi JavaScript:
$('.mce_editable').tinymce().onChange.add(monitorTinyMCEIconFont)
monitorTinyMCEIconFont è una funzione JavaScript che si occupa di:
- analizzare il codice HTML dell'editor
- trovare tutti gli elementi che usano uno stile di icon font
- aggiungere a questi (se non già presente) l'attributo aria-hidden
- aggiornare il contenuto dell'editor (solo se è stato modificato).
Segue la definizione:
function monitorTinyMCEIconFont(ed, l) {
var changesDone = false,
doc = $('<div id="fakeContainer">' + l.content + '</div>');
for (var i=0;i<classes_to_monitor.length;i++) {
doc.find('.' + classes_to_monitor[i] + ':not([aria-hidden="true"])').each(function() {
var element = $(this);
element.attr('aria-hidden', 'true');
changesDone = true;
});
}
if (changesDone) {
ed.setContent(doc.html());
}
};
Da notare il riferimento alla struttura dati classes_to_monitor, un array per limitare il numero di stili supportati.
Vista la configurazione lato server che introdurremo tra poco, definiamo l'array in questo modo:
var classes_to_monitor = ['icon-star', 'icon-envelope', 'icon-user', 'icon-ok', 'icon-remove'];
Attributi permessi di TinyMCE
Sebbene la configurazione dei filtri HTML di Plone non contenga nulla di particolare contro l'attributo aria-hidden, l'approccio qui sopra non funziona ancora: l'attributo viene eliminato senza pietà!
Il problema è (di nuovo) in TinyMCE (...tu quoque, Tiny...).
Per quanto gli unici elementi di configurazione che trattano attributi siano relativi ad "Attributi eliminati" (quindi una black-list di attributi), la configurazione di default di TinyMCE permette comunque solo un certo insieme di attributi.
Troviamo questa configurazione nella definizione della ITinyMCE utility. Se prendiamo ad esempio come riferimento l'elemento SPAN che stiamo usando.
Troviamo:
...
'span': COMMON_ATTRS.copy(),
...
Dove COMMON_ATTRS risulta essere:
...
CORE_ATTRS = set('id style title class'.split())
I18N_ATTRS = set('lang dir'.split())
COMMON_ATTRS = CORE_ATTRS | I18N_ATTRS
...
Come potete capire quindi, per l'elemento span tutti gli attributi non compresi in questa lista verranno eliminati dall'editor.
La nostra unica possibilità è modificare l'utility (definendone una nuova) che cambi questo comportamento:
CORE_ATTRS = set('id style title class'.split())
I18N_ATTRS = set('lang dir'.split())
ACCESSIBILITY_ATTRS = set('aria-hidden'.split() )
COMMON_ATTRS = CORE_ATTRS | I18N_ATTRS | ACCESSIBILITY_ATTRS
...e anche questo problema è risolto.
Effetto finale
Non è stato esattamente semplice ma siamo arrivati a una soluzione!
Ecco come viene infine generato il nostro HTML:
Alla prossima!
Easter egg
In questo articolo è nascosto un messaggio segreto! Riuscite a capire cosa dice?!
RedTurtle al Plone Cathedral Sprint: verso la prima release di Plone 5
Da anni RedTurtle punta molto su Plone, glorioso gestore di contenuti open source.
Grazie alla scelta open, RedTurtle ha potuto beneficiare del lavoro di una delle comunità più competenti del mondo, comunità nella quale essa stessa è sempre più presente e attiva.
Lo sviluppo di Plone è caratterizzato da eventi chiamati "Sprint": riunioni nelle quali sviluppatori di tutto il mondo lavorano in "full immersion" per conseguire gli obiettivi che si sono preposti prima del loro incontro.
La settimana scorsa Andrew, Giacomo e io abbiamo partecipato, insieme a una folta schiera di Plonisti, al "Cathedral Sprint" di Colonia.
L'evento, che prende il nome dalla cattedrale gotica che domina il panorama della città tedesca, è stato organizzato con lo scopo di accorciare i tempi necessari al prossimo rilascio della nuova versione di Plone, la numero 5.
Plone 5 si sta per presentare al mondo con una interfaccia utente completamente rinnovata, disegnata seguendo i più moderni standard del web, contenente automatismi che facilitano l'utente nel lavoro e che permette un utilizzo efficace anche con i dispositivi mobili. Tutto questo senza dimenticare di garantire, come sempre accade per Plone, la piena accessibilità.
In questo sprint ho lavorato molto sui test delle nuove interfacce utente, utilizzando Robot Framework: un programma che “prende possesso” del browser simulando l'utilizzo del sito da parte di un utente allo scopo di verificare l'effettiva funzionalità dell'applicazione.
Anche i miei colleghi si sono focalizzati sull'interfaccia utente. Andrew si è dedicato principalmente al componente per l'inserimento, la modifica e la formattazione dei testi, Giacomo si è adoperato per rendere più semplice e funzionale le personalizzazioni di elementi chiave del sito come la testata e il piè di pagina.
Purtroppo la settimana a Colonia è passata davvero in fretta e come al solito si torna a casa con l'amara consapevolezza di dover aspettare ancora settimane prima di incontrare nuovamente la magnifica comunità dei Plonisti.
Prima di concludere, un sentito grazie a Timo Stollenwerk per la magnifica organizzazione e a GFU Cyrus AG per l'ospitalità. Tutto era perfetto ed è stato davvero facile essere operativi sin da subito.
Vi lascio con il link a Twitter dedicato allo sprint e con qualche immancabile immagine di quello che sarà il futuro Plone.
Credits
La foto di gruppo è di Wolfgang Thomas.
La mascotte di Robot Framework è presa da Twitter.
Immagini di testata e per Facebook prese da Wikipedia.
