10 Errori più comuni nello sviluppo Joomla!

(e come aggiustarli)

Errori tipici nelle estensioni, come correggerli o aggirarli.

Quando usiamo estensioni di terza parte o anche alcuni componenti Joomla! sul nostro sito, spesso troviamo che non si comportano come ci aspetteremmo, o che gli manca il supporto per alcuni standard che ne rendono difficile l'uso.

In questo articolo elenco i problemi più comuni che incontrerete, e indicazioni per una soluzione rapida.

Come utente, tutto quello che potete fare è contattare il supporto clienti.  Ma - in particolare nel caso delle estensioni gratuite - questo può essere non disponibile o troppo lento per gestire un problema su un sito in produzione.

Come sviluppatore, osserverai che alcune linee guida fondamentali sono spesso ignorate.  Usando componenti di altri - e con una minima dimestichezza con il php - è normalmente piuttosto semplice correggere / adattare / estendere queste estensioni per soddisfare le vostre esigenze.  Eccoci alla lista:

1. Manca il supporto per layout o classi personalizzate

Layout

Nei componenti e moduli normalmente viene realizzata una sola vista ed un solo layout: default.php.  Ma visto che il 95% delle modifiche richieste dagli utenti hanno a che vedere con la grafica, questo è il singolo elemento che verrà più cambiato / esteso dagli utenti.

Per permettere agli utenti di usare un layout alternativo, tutto ciò che devi fare è aggiungere il parametro layout alla configurazione della estensione, e assicurarti che venga usato quando si esegue la vista.

Classi aggiuntive (CSS)

Sia i componenti che i moduli possono accettare una classe personalizzata che - a seconda del template - può essere aggiunta o unita alle classi standard.  Come sopra, il nome standard del parametro per la class è moduleclass_sfx, una volta inserito questo sarà disponibile nelle opzioni del modulo o del componente, che potrà essere personalizzato individualmente.

3. Supporto per la cache mancante / incompleto / difettoso

La cache di Joomla! è fantastica.  Permette diversi livelli di cache, velocizza il sito e alleggerisce il carico sul server.  Joomla gestisce la cache efficientemente anche se il programmatore non ha nemmeno preso in considerazione questo aspetto; tuttavia, nel caso in cui dobbiamo visualizzare due moduli sulla stessa pagina, con parametri differenti, potremmo trovarci con lo stesso contenuto se la configurazione della cache del modulo non prende in considerazione i parametri. 

Puoi approfondire la questione nell'articolo dedicato.

4. Traduzioni mancanti

E' una responsabilità del programmatore estrarre le stringhe dal codice e localizzarle almeno in inglese.

I file di lingua possono trovarsi in due posti, sotto /language/en-GB oppure /module/mod_yourmod/language, il secondo è il modo preferito in Joomla! 1.6+ in quanto permette di tenere tutti i files dell'estensione in un unico posto.

E' inoltre possibile caricare i file di traduzione di un'altra estensione, questo è un sistema molto efficiente quando si distribuisce un pacchetto per evitare la duplicazione e ridurre la manutenzione al minimo; gli unici elementi che dovranno essere localizzati per ciascuna estensione sono le voci di menù ed il nome, che sono usati anche all'esterno.

Quindi, anche se non usate l'inglese, il primo passo è di spostare tutte le stringhe di testo in un file en-GB.extension_name.ini assegnando una costante (che inizi con il nome dell'estensione!) ad esempio:

MOD_MYMODULE_HELLO_TEXT="Hello"

Il nome della costante deve essere in inglese.  Ora salvate il file e siete pronti ad usarlo: JText::_("MOD_MYMODULE_HELLO_TEXT") restituirà il testo localizzato.

5. Carica jQuery. Un'altra volta.

Se ti piacciono le animazioni e una attiva interazione con l'utente, è probabile che alcune delle estensioni che hai scelto facciano uso di qualche versione di jQuery, senza darti la scelta se usare un'altra versione magari già caricata dal template.

La migliore opzione è inserire jQuery direttamente a livello del template, e rimuoverla (manualmente ove necessario) dalle altre estensioni.

Per trovare queste occorrenze, una veloce ricerca per  jquery.*\.js le dovrebbe trovare tutte..

Una alternativa semplice è usare il nostro plugin  "toomanyfiles", che si occupa di rimuovere i duplicati di jQuery.

6. Caricare molti files piccoli.

Il numero di risorse separate (files) ha un impatto maggiore sul tempo di download che il loro peso in bytes.  Vengono spesso incluse per ridurre le dimensioni dell'HTML (un ottimo proposito).  Ma se finiamo con 12 file css e 16 librerie javascript, dobbiamo procedere con un po' di ottimizzazione.

Unire a mano queste risorse comporta però alcuni problemi: perdiamo la comodità e la semplicità di manutenzione di avere ogni risorsa collegata all'estensione che la usa, e ci ritroviamo con files di notevoli dimensioni, più difficili da gestire.  Comprimere le risorse ne riduce la dimensione ma non il numero.  La soluzione più semplice è il plugin "too many files", che unisce le risorse e le comprime in maniera trasparente.

Stili definiti solo per alcuni browser

Spesso si includono (@include) fogli di stile CSS specifici per alcuni browser che non supportano gli standard ma che purtroppo hanno una grande diffusione.  E' molto conveniente includere le regole specifiche con modernizr invece di realizzare files separati.

Print @media

Le risorse incluse con il media Print vengono scaricate dai browser quando visualizziamo una pagina.  Quindi è conveniente includere una sezione @media print nel file principale piuttosto che tenerlo separato.

Sprites

Vedi il numero 8. più sotto

7. Ricaricare jQuery sotto altro nome

jQuery è uno standard de facto, non si discute.  E naturalmente ne esistono diverse versioni.

Per risolvere alcune incompatibilità o prevenirle, troppi sviiluppatori decidono di rilasciare componenti che usano una versione personalizzata di jQuery in cui viene modificato il nome jQuery con uno di fantasia.

Nella maggior parte dei casi questa è una precauzione non necessaria per il funzionamento dell'estensione; ma l'effetto devastante è che state costringendo ogni utente a scaricare 60Kb per avere una copia in più.

Risolvere questo problema richiede una certa attenzione: è necessario verificare che il codice dell'estensione funzioni correttamente dopo aver eliminato la loro versione personalizzata.  Quindi aggiungete una versione recente di jQuery (da una CDN per piacere!), quindi create un sinonimo: ad esempio in cometchat jQuery viene rinominata jqcc; in Jomsocial, joms.jquery.  Nei componenti di scroll di YTC, ytc_query e così via.

Prima di tutto, trovate dove vengono istanziati questi alias e rimpiazzateli con:

ytc_query = jQuery;

joms.jquery = jQuery;

Questo è tutto quel che serve, visto che tutti gli usi successivi di queste variabili faranno riferimento al jQuery originale, senza appesantire i tuoi utenti con un download extra.

Il plugin toomanyfiles gestisce automaticamente molti alias comuni di jQuery.

8. Sprite mancanti

La tecnica degli sprite è molto efficace nel ridurre il numero di files scaricati.  Combinando in un'unica immagine tutte le icone e le piccole immagini del nostro sito otterremo una riduzione misurabile dei tempi di download.  Le regole nel foglio di stile dovranno essere aggiornate utilizzando gli attributi background-position e (ove opportuno) background-size in modo che visualizzino per ciascun elemento solo la parte dell'immagine pertinente.

Inoltre, quando si carica un'immagine alternativa sul mouseover di un bottone, normalmente si associa l'immagine alla regola :hover dell'elemento.  Ma questo ha un effetto molto lento, visto che l'immagine viene caricata solo quando si fa l'hover; usare la tecnica degli sprite in questo caso rende istantaneo l'effetto :hover visto che il file è già caricato.

9. Routing incompleto / difettoso / mancante

L'indirizzo di una pagina di solito è composto di diversi elementi:

option	com_content	Il nome del componente
task	display	Il nome della funzione del controller che viene invocata
view	default	Il nome della vista
tmpl		Il nome del template. Può essere impostato su "component" per visualizzare solo l'output del componente, invece della pagina intera, e corrisponde al file component.php nella root del componente.
format	json, raw	Di solito si usa per le richieste ajax

E' molto sbagliato basare la strategia del router.php sul numero di parametri; mentre può portare ad una buona ottimizzazione nella lunghezza del percorso, può rapidamente diventare un incubo per la manutenzione ed il debug.  E facilmente si può rompere se usate chiamate ajax (che di solito aggiungono un parametro).  Visto che il router.php è spesso molto complesso (un migliaio di righe è una dimensione comune), ed il suo funzionamento interno non sempre è facile da capire alla prima lettura, dovrebbe sempre esser trattato con la dovuta riverenza.

 E' possibile invocare una vista nascosta passando il nome nella url, e anche selezionare un task (metodo del controller), una vista o un layout semplicemente con parametri nella url: quindi è importante capire quali sono gli elementi che più variano nelle vostre url, e creare casi speciali solo per quelle funzioni più importanti da un punto di vista di marketing/indicizzazione, e per il resto usate un gergo comune tipo /task/view/id.  Questo renderà molto più semplice la implementazione e la sua manutenzione.

10. Codice o stili che rompono il layout (regole sbagliate)

A volte gli sviluppatori di estensioni - inclusi gli sviluppatori di moduli - pensano di poter usare classi super-generiche o addirittura applicare regole agli elementi come p, div o span.  Inutile dirlo, questo romperà gli stili su tutto il resto del sito; per risparmiare tempo la soluzione più rapida è aggiungere un contenitore con nome (es. div id="mycomponentname") e usarlo come prefisso in tutte le regole css definite quindi

p

diventa

#mycomponentname p

Altra questione piuttosto comune è la mancanza di div (aperti e mai chiusi o viceversa).  Potete riscontrare questi errori validando le pagine.  Trovare il pezzo di codice che offende può essere difficile, visto che il browser integra i tag mancanti quindi firebug non vedrà esattamente il markup.  Provate a spubblicare i moduli - uno per uno- fino a scoprire qual è il responsabile.

11. Validazione dell'input mancante

Anche se eseguite validazione lato client (sul browser), tutti i parametri devono essere filtrati.  Usare le classi JRequest::get* oppure JInput::get* appropriate, indicando il tipo di dati che vi aspettate di ricevere.

Due tipi di parametrii in particolare devono _sempre_ essere validati: quelli che andranno a comporre una query sul database (usando $db->quote) e quelli che vanno ad essere inseriti in javascript (quantomeno per controllare che non introducano errori nel codice).

Questi due errori possono esporre il vostro sito a rischi notevoli, andate quindi su joomlaextensionsblacklist.com e assicuratevi che le vostre estensioni non soffrano di queste vulnerabilità.  Seguite gli sviluppatori delle estensioni che usate su twitter / feed / mailing list per sapere tempestivamente quando una nuova versione viene rilasciata.

12. Peggiori abitudini

• L'istruzione !important nel css, oppure regole specifiche di qualche browser (quelle che iniziano con -webkit... -moz...
• La view esegue operazioni sul db (ovvero c'è una istruzione sql  SELECT in una view o ancora peggio in un layout)
• Il controller o il modello scrivono html (eccetto per gli helper html)

...la lista è lunga.  Al di là delle ovvie questioni stilistiche, architetturali, dei problemi di manutenibilità, efficienza e riutilizzabilità del codice, questi sono difetti che non pongono il nostro sito a rischio, solo lo stomaco di chi deve manutenere il codice.