Skip to main content

WordPress: Tema o Plugin non più funzionanti? Attenzione ai riferimenti JS o CSS duplicati

Ormai sappiamo tutti come funzionano le tipiche installazioni di WordPress: si inizia con un Tema che sembra particolarmente efficace, si aggiunge una manciata di Plugin indispensabili come Jetpack, Contact Form 7, il pacchetto YOAST per gestire Google Analytics e la parte SEO e grossomodo si pensa che sia finita lì. Dopo tutto abbiamo bisogno di un semplice blog, giusto? Inutile appesantirlo con roba superflua.

Poi si comincia a riflettere sul fatto che sarebbe bello dotare i nostri utenti di una newsletter: per fortuna esiste MailPoet, che si occupa proprio di questo. E non passa molto tempo prima che arrivi la voglia di inserire qualche galleria di immagini qui e là, esigenza che viene facilmente soddisfatta dalle miriadi di plugin che offrono ogni sorta di slider e carousel con cui arricchire pagine e articoli. E cosa c’è di meglio di BuddyPress per gestire la community, o di WooCommerce per vendere prodotti? E a chi non interessa poter dare ai propri utenti la possibilità di accedere ai file condivisi tramite Google Drive o Dropbox sfruttando uno dei tanti Download Manager a disposizione?

Tanto vale ammetterlo: nessuno installa WordPress per fare un semplice blog. Al contrario, il motivo per cui si sceglie WordPress è proprio perché si ha l’esigenza di mettere in piedi un sito dalle funzionalità complesse mantenendole sotto controllo grazie a una piattaforma robusta e modulare. C’è forse qualcosa di male in questo? Assolutamente no. Tranne quando, tra i numerosi plugin che si andrà inevitabilmente ad installare, ve ne saranno alcuni che aggiungeranno le medesime librerie js o css di uso comune (jQuery, Bootstrap, MooTools etc.) al nostro sito.

Approfondisci

Aggiungere un namespace a un foglio di stile per evitare conflitti tra file CSS

La crescente necessità di sviluppare siti responsive nel più breve tempo possibile ha provocato la comparsa e la diffusione, nel corso degli ultimi anni, di una serie di framework e/o boilerplate CSS avanzati come Bootstrap, Foundation, GumbyYAML, Skeleton solo per citare alcuni tra i più noti. Ciascuno di essi mette a disposizione dello sviluppatore un ampio ventaglio di classi predefinite che consentono di ottenere rapidamente lo scopo: rendere il proprio sito adatto alla visualizzazione su qualsiasi piattaforma e dispositivo mantenendo la piena compatibilità con tutti i browser desktop.

Un traguardo ideale… a patto che le classi non entrino in conflitto tra loro e/o con classi già definite all’interno altri fogli di stile.

Il problema.

Analizziamo, a titolo di esempio, un estratto delle classi messe a disposizione dal framework Bootstrap, ad oggi senz’altro il più noto e utilizzato:

… e la lista potrebbe continuare.

Inutile dire che ciascuna di queste classi presenta al suo interno numerose impostazioni che saranno con tutta probabilità incompatibili con classi aventi lo stesso nome definite in altri fogli di stile, siano essi creati da noi, parte di qualche plugin JQuery o portati in dote da qualsiasi altra libreria o modulo client-side.

La soluzione.

Il metodo più intuitivo per evitare problemi di questo tipo è rinominare le classi in conflitto, iniziando dalle proprie e, se la situazione lo richiede, proseguendo eventualmente con quelle dei plugin/moduli accessori. Tale approccio può essere preso in considerazione nel caso di un piccolo sito, ma è ben lungi dall’essere ideale nel caso di portali di dimensioni medio/grandi.

WHY.Jesse.Pinkman

L’approccio di tipo “search & replace” è in molti casi un’operazione delicata: effettuarla in modo automatico è estremamente rischioso, soprattutto in casi come questo dove si richiede un notevole livello di attenzione. Il sito potrebbe prevedere plugin, moduli o funzioni Javascript che utilizzano selettori di classe per svolgere il loro lavoro e che potrebbero sfuggire a una prima occhiata, come nell’esempio seguente:

In tutti i casi in cui l’approccio del “search & replace” rischia di  rivelarsi troppo oneroso è opportuno orientarsi verso una soluzione più robusta e a prova di errore. Quella che vi presentiamo consente di incapsulare qualsiasi foglio di stile – non importa se creato da voi, incluso nel framework o parte dei plugin installati – all’interno di un vero e proprio Namespace. Per far questo in modo efficiente dovremo utilizzare un pre-processore CSS tra quelli attualmente disponibile: i più noti e diffusi sono SASS, diffuso soprattutto in ambiente Linux, e LESS, particolarmente adatto per chi lavora Windows per via della integrazione con Visual Studio 2012 (e superiori) grazie all’ottima estensione Web Essentials.

Cos’è un pre-processore CSS? In estrema sintesi, si tratta di un compilatore che produce un foglio di stile .css partendo da un file .scss o .less : questo file non è altro che un foglio di stile arricchito da caratteristiche aggiuntive ottenute grazie a una sintassi proprietaria, che il compilatore si occupa di “riscrivere” in modalità compatibile CSS2/CSS3.

Ecco un breve esempio di come si presenta un file .less:

Ed ecco il file .css prodotto a seguito della sua compilazione:

Per una guida completa alla sintassi dei due pre-processori vi rimandiamo alle guide ufficiali presenti sui rispettivi siti:

In questo articolo ci limiteremo a mostrare la sintassi necessaria per creare il nostro namespace. Per nostra fortuna è del tutto identica per entrambi i linguaggi, con la sola eccezione dell’estensione dei file che cambia a seconda del pre-processore scelto.

Nell’esempio che segue abbiamo utilizzato .less:

Una volta compilato, questo file includerà l’intero contenuto dei due file .less menzionati al suo interno avendo cura di aggiungere la classe .namespace-name all’inizio di qualsiasi selettore contenuto. Questo significa che ciascuno di essi verrà preso in considerazione soltanto se utilizzato all’interno di un elemento contenitore (DIV, BODY o qualsiasi altro) recante la classe .namespace-name.

Una volta compreso l’esempio, vediamo come possiamo creare un namespace per le classi CSS fornite con il framework Bootstrap:

Le prime 5 regole di stile (quelle prima dei due @import) sono le stesse che il file bootstrap.css applica all’elemento BODY della pagina, e quindi potenzialmente ereditate da tutti gli altri elementi. Il modo migliore per riprodurre lo stesso identico effetto è quindi aggiungerle direttamente al nostro namespace.

IMPORTANTE: Come si può vedere, è necessario che anche i file oggetto dell’importazione abbiano l’estensione corrispondente a quella riconosciuta dal pre-processore utilizzato. Se volete importare dei normali file .css basterà rinominarli in tal senso: del resto, come abbiamo detto, i file .scss e .less non sono altro che fogli di stile “arricchiti”. Se avete optato per .less potete risparmiarvi il rename: basterà utilizzare @import (less) in luogo di @import, come spiegato qui.

Felice sviluppo!

Utilizzare JQuery UI e Bootstrap nella stessa pagina web

Gli ultimi mesi hanno visto una diffusione capillare del framework Bootstrap, una libreria CSS/JS che consente di dotare qualsiasi sito web di tutte le funzionalità necessarie per rendere le proprie pagine mobile-friendly e, cosa ancor più importante, pienamente compatibili con tutti i device. Il Framework, oggi giunto alla versione 3.3.1, è dotato di una serie di plugin javascript che richiedono JQuery v1.9.0 o superiore: è quindi facile immaginare come si sia diffuso principalmente sui siti che includono quest’ultimo, i quali non di rado ospitano anche JQuery UI.

Utilizzare questi due framework insieme è possibile, ma occorre fare attenzione ad almeno due conflitti presenti tra le due librerie e che rischiano di produrre errori JS e/o di compromettere alcune funzionalità del sito. Si tratta dei plugin tooltip e button, entrambi presenti (con il medesimo nome) in ciascuna delle librerie.

Il Problema.

Prendiamo come esempio il plugin tooltip. Andiamo sul sito http://jqueryui.com/tooltip/ e diamo un’occhiata al codice di esempio (view source) per la creazione di un tooltip con JQuery UI:

Il testo evidenziato presenta una chiamata alla funzione tooltip che JQuery UI aggiunge a livello runtime per ogni oggetto JQuery. La stessa operazione viene effettuata da Bootstrap come si può vedere analizzando il codice del relativo tutorial:

Questo conflitto di nomi, oltre ad impedire a entrambi i plugin di funzionare, provoca una serie di errori Javascript variabili a seconda di quale libreria viene eseguita prima. Nel caso in cui Boostrap sia inserito dopo JQuery UI, ad esempio, l’errore che vedremo nella nostra Console Javascript sarà con tutta probabilità il seguente:

Uncaught TypeError: Cannot read property ‘documentElement’ of null

Dovuto al fatto che la sintassi del plugin di JQueryUI, solitamente utilizzato a livello di $(document), viene utilizzata per eseguire il plugin di Bootstrap.

 La Soluzione.

Il modo migliore per far convivere le due librerie risolvendo “in positivo” i conflitti di nomi è utilizzare il plugin $.widget.bridge che consente di poter ridefinire a piacimento questi ultimi. Il plugin è fortunatamente incluso all’interno di JQuery UI, quindi non appesantirà ulteriormente il nostro sito. Il suo utilizzo è molto semplice:

Queste istruzioni vanno ovviamente inserite nella pagina in modo sincrono dopo aver incluso il riferimento alla libreria JQueryUI e prima dello script di Bootstrap. Nell’esempio seguente vediamo un esempio completo di implementazione nel blocco <head> di una pagina web:

In conseguenza di questa operazione i metodi tooltip e button diventeranno una prerogativa di Bootstrap, mentre per utilizzare gli omonimi plugin offerti da JQuery UI sarà necessario utilizzare i nuovi alias uitooltip e uibutton.

Riferimenti:
http://stackoverflow.com/a/27745464/1233379 (la mia risposta sul sito StackOverflow che ha ispirato questo post).

Close