Mettre des photos de chatons dans son site web en développement, ça rend heureux.
C’est bien beau avoir un couteau suisse, mais si tu n’es pas capable d’en sortir la grande lame, il perd un peu de son utilité.
C’est un peu le constat que je fais face à Joomla. Après xyz heures de perdues à essayer de faire fonctionner des modules, j’ai malheureusement adopté l’attitude « utiliser ce qui est là pour obtenir ce qu’on veut ».
Une section du site sur lequel je travaille doit comporter une gallerie photo. Rien de bien compliqué, vous en conviendrez. Il doit bien y avoir un module qui sert à cela… Je débute donc mes recherches.
On peut dès le départ diviser les modules en deux groupes : les payants, et les libres de droits. Travaillant dans une OSBL, on devine bien de quel côté je me dirige.
Par la suite, il faut trouver le module qui convient à nos besoins. Deuxième constat : les modules sont soit beaucoup trop simplistes (ne font pratiquement rien ou ne répondent pas aux besoins), ou beaucoup trop complexes (« Vraiment? Un tapis sauve-pantalons dans mon couteau suisse? »).
Une fois le module qui convient à peu près à nos besoins trouvé, il faut l’installer et le configurer. Mais la configuration n’est jamais bien adéquate : il faut donc aller jouer dans le code pour adapter le tout à nos besoins. On fait donc une croix sur les éventuelles mises à jour…
Puis, rendu dans le code, c’est bien souvent complexe. Je lève mon chapeau aux développeurs de modules Joomla; je n’ose pas m’avancer sur mes capacités à le faire. Cependant, on dirait qu’il y a toujours quelque chose qui accroche : si ce n’est pas le balisage HTML généré qui ne fait aucun sens, c’est le code spaghetti qui fait rouler le module, ou celui-ci qui décide tout simplement de ne pas fonctionner du tout sans aucune raison, ou encore la documentation disponible seulement en Allemand…
Si au moins c’était en portugais, je pourrais en profiter pour apprendre.
Donc au final, la solution qui se présente à nous est d’utiliser ce qui est là de base et de détourner son usage normal pour obtenir ce que l’on veut. Débrouillardise 101. Ce que j’ai fait pour ma gallerie photo.
En gros, chaque gallerie photo est un article (voyez la logique…) qui contient une liste à puces peuplée d’images. Puis, c’est l’extension jQuery bxSlider et un peu de JavaScript maison qui se charge de transformer le tout en galerie interactive.
Ça peut sembler adéquat comme solution pour l’instant, mais il faut penser au maintien futur du site : avec cette solution, un administrateur sans vraiment de connaissances en HTML pourrait éprouver quelques difficultés à ajouter, supprimer ou modifier une galerie de photos.
Et pourquoi donc utilise-t-on un SGC? Pour faciliter la gestion du site…
Je songe déjà à écrire une manuel d’utilisation pour le site que je conçois, question d’assurer une certaine pérennité à celui-ci. Car je ne serai plus là dans quatre mois…
La morale de cette histoire, question de finir sur une bonne note : quand vient le temps de planifier le développement d’un site web et de choisir un SGC, il est important de bien évaluer les besoins du site. Qu’est-ce qui se retrouvera sur le site ? Comment les informations seront-elles organisées? Qui s’occupera de la mise à jour? Est-ce qu’un SGC maison ne serait pas plus approprié?
Mais évidemment, dans tout ce processus, certaines réponses pourront avoir plus de poids que d’autres…
