Written by IL ÉTAIT UNE FOIS…
J’ai commencé à écrire des pages HTML dans les années 1998 – 1999. A cette époque, les choses étaient simples, on codait des pages .htm ou .html statiques à l’aide du bloc-note, (de Front Page ou Dreamweaver pour les plus chanceux). La plupart du temps on apprenait (vite) à organiser les chiers .css rudimentaires en arborescence plus ou moins structurée, les plus rigoureux disposaient les chiers d’images (à l’époque .gif et .jpg) dans une structure qui nous était personnelle.
IL ÉTAIT UNE FOIS…
J’ai commencé à écrire des pages HTML dans les années 1998 – 1999. A cette époque, les choses étaient simples, on codait des pages .htm ou .html statiques à l’aide du bloc-note, (de Front Page ou Dreamweaver pour les plus chanceux). La plupart du temps on apprenait (vite) à organiser les chiers .css rudimentaires en arborescence plus ou moins structurée, les plus rigoureux disposaient les chiers d’images (à l’époque .gif et .jpg) dans une structure qui nous était personnelle. L’ajout de chiers .js dans les années suivantes (javascript c’était le diable !) a conduit par la force des choses à structurer et normaliser encore plus l’administration des sites. Vers 2000 – 2001 le passage à des chiers, toujours statiques, mais gérant du contenu dynamique (asp et php) n’a pas fondamentalement bouleversé la donne. Pas de types de présentations multiples de type blog ou autre, pas de réseaux sociaux, et bien souvent graphiste et webmaster était une seule et même personne. Structurer les chiers physiques en suivant l’ordre des menus – sous-menus était pratique, simple et de bon aloi. La méthode n’avait nalement qu’un seul vrai défaut : remodeler le rendu d’un site en changeant la ligne graphique ou en modi ant l’organisation des menus était très compliqué et générait des erreurs 404 (page inexistante) à foison. Mais globalement un simple coup d’œil sur les répertoires et chiers du serveur internet permettait de s’y retrouver assez facilement.
L’ajout de fichiers .js dans les années suivantes (javascript c’était le diable !) a conduit par la force des choses à structurer et normaliser encore plus l’administration des sites. Vers 2000 – 2001 le passage à des fichiers, toujours statiques, mais gérant du contenu dynamique (asp et php) n’a pas fondamentalement bouleversé la donne.
Pas de types de présentations multiples de type blog ou autre, pas de réseaux sociaux, et bien souvent graphiste et webmaster était une seule et même personne. Structurer les fichiers physiques en suivant l’ordre des menus – sous-menus était pratique, simple et de bon aloi. La méthode n’avait finalement qu’un seul vrai défaut : remodeler le rendu d’un site en changeant la ligne graphique ou en modifiant l’organisation des menus était très compliqué et générait des erreurs 404 (page inexistante) à foison. Mais globalement un simple coup d’œil sur les répertoires et fichiers du serveur internet permettait de s’y retrouver assez facilement.
Les temps modernes
L’arrivée des CMS et Joomla! n’échappe pas à la règle, a bouleversé ce semblant d’ordre. Plus de sauvegarde physique des pages html, au niveau de l’architecture du serveur mais au contraire : structuration du contenu dans une base de données et génération dynamique des pages affichables à la demande. Cette façon de procéder présente un gros, bien que peu visible, avantage : il n’est plus nécessaire d’accorder aux webmasters, des droits physiques sur les répertoires et fichiers, Joomla! a juste besoin de gérer les droits fonctionnels d’accès aux données.
Par contre le webmaster débutant ou venant des méthodes de développement plus classiques n’y trouve pas forcément son compte et est en droit de se poser une question cruciale : Où sont donc passées mes données ? Plus du tout ou en tous cas beaucoup moins d’accès aux données par FTP interposé : impossible d’ouvrir un fichier pour modifier une virgule mal placée, difficile de trouver les fichiers de styles impliquées dans la mise en page … Alors même que par rapport aux temps anciens, la rigueur s’est imposée, le néophyte Joomla!, ne sait plus très bien où retrouver ses petits.
Un SGBDR pour centraliser l’information.
Pour autant, le fait que Joomla! stocke une grande partie des informations que vous lui confiez dans une base de données relationnelles, va simplifier grandement votre tâche. De fait à part quelques paramètres de configuration, et la totalité des images que vous publiez dans les pages de votre site, tout ce que vous ferez au cours de votre carrière de webmaster Joomla! sera intégré dans cette base relationnelle. Si, comme nous l’avons déjà dit il est devenu impossible de modifier une virgule mal placée en ouvrant un fichier, il est devenu a contrario tout à fait possible de le faire à coup de requêtes SQL. Et bien plus encore ! Imaginez devoir chercher et modifier dans vos fichiers html : un mot, un nom de marque, une url particulière, une balise HTML spécifique ou même toutes les balises d’un type donné juste pour avoir la liste des articles qui les référencent ou plus fort encore pour remplacer ces occurrences par une autre valeur, nécessitait dans les temps anciens, d’être un excellent spécialiste de l’outil grep . Il vous faudra désormais être un spécialiste SQL ou utiliser quelque outil qui écrira ces requêtes pour vous.
Autant il était difficile d’utiliser pour un non expert les outils de gestion de répertoire et de fichiers unix ou linux de faire des statistiques sur les pages html, leur date de création, de publication, de modification etc… autant il est facile, en quelques requêtes SQL réutilisables, de faire ces mêmes traitements lorsque l’information est centralisée dans une telle base de données relationnelles.
Note : Nous pourrions parler SQL plus longtemps, cela est intéressant, mais nous allons essayer de rester en superficie, les requêtes SQL feront l’objet d’un prochain article.
La preuve par l’image.
Pour voir comment opère la magie, partons d’un site Joomla! 3.4 tout neuf avec ses données de démonstration, installées avec le choix ci-après :
Une fois le site de démonstration installé, prenons bien soin dans un premier temps de désactiver le mode SEF, à seule fin de suivre le cheminement de la méthode Joomla!, pour cela dans les pages de configuration, adoptons les paramètres SEO qui vont bien :
La base de données du site fraîchement installé contient des articles présentant Joomla! en nombre suffisant pour notre propos. C’est ainsi qu’en examinant cette base de données, l’on trouve pour la table ##_content des données telles que :
La table ##_content, a pour destinée de stocker le contenu des articles du site, dans ses colonnes elle contient bien d’autres informations, mais parmi celles qui peuvent nous intéresser au premier abord, on peut noter les champs :
id : c’est l’index majeur de la table, identifiant de manière univoque l’article concerné.
asset_id : c’est une référence vers une table de définition des droits d’accès associés à l’article, c’est par ce biais que Joomla! décidera si l’utilisateur connecté peut ou ne peut pas afficher, voire modifier ou supprimer l’article concerné.
alias : mnémonique utilisé par Joomla! pour générer automatiquement une url SEF (Search Engine Friendly).
title : c’est ce qui apparaîtra dans le navigateur comme nom de l’article et garnira la balise du code HTML de votre page, à ne pas confondre avec le contenu d’une balise .
introtext : malgré son nom, c’est dans cette colonne SQL que vous trouverez la totalité du contenu de votre article. Si vous utilisez l’attribut Joomla! [Lire la suite] (une balise portant l’id ‘ system-readmore ‘), votre article sera découpé en deux parties, la suite étant stockée dans la colonne ‘fulltext’. Vous pouvez constater sur la copie d’écran ci-dessus, qu’il s’agit du contenu HTML de la balise de votre article.
catid : c’est cette fois une référence vers une table de définition des catégories, permettant de structurer les articles stockés par Joomla!. Chaque article doit obligatoirement appartenir à une catégorie et à une seule, par défaut la catégorie : ‘non catégorisé’. Les catégories peuvent être imbriquées et présenter une forme d’arborescence, mais l’article n’est rattaché qu’à une et une seule catégorie.
state : c’est l’état à un instant donné de l’article : publié, non publié, archivé, supprimé.
featured : c’est le statut de l’article : en vedette ou non.
hits : le nombre de fois que le document a été affiché.
Comment cela fonctionne-t-il dans la pratique ?
Du fait des relations établies avec d’autres tables de la base de données, il est vite évident que le contenu des articles doit être généré en interne depuis Joomla!. Si dans le passé, on pouvait facilement taper son code html manuellement et le sauvegarder physiquement, cela n’a plus aucun sens dans un tel environnement, taper du code et le sauvegarder dans une colonne de la base de données est non seulement insensé mais extrêmement dangereux. Les fondateurs de Joomla! qui en étaient d’ailleurs bien conscients ont intégré dès l’origine dans Joomla! un éditeur HTML : tinyMCE. L’éditeur WYSIWYG (What You See Is What You Get) tinyMCE, est certes basique, mais c’est celui fourni par défaut lors de l’installation, il en existe bien d’autres, plus complets ou plus ergonomiques et conviviaux comme le très utilisé et très fameux JCE.
Dans la vue de la table ##_content de l’image précédente, l’article dont le titre est ‘Comment débuter ?’ peut être affiché dans le frontend du site en cliquant sur le menu :
Ce qui a pour effet de générer dans le navigateur l’url (en mode non SEF) :
http://sitedemo.fr/index.php?option=com_content&view=article&id=22&Itemid=437
La première tâche de Joomla! lorsqu’une url lui est soumise est d’analyser son contenu et de déterminer ce qu’il doit en faire et quelle partie de Joomla! est la mieux à même d’effectuer la tâche demandée. Ainsi en ce qui concerne l’url précédente, le noyau de Joomla! va extraire les éléments qui doivent participer à la magie des opérations. C’est un composant de Joomla! appelé le routeur (JRouter) qui effectue ce travail :
Etape 1 : JRouter analyse l’url et détermine que le module qui doit être utilisé par Joomla! est com_content (c’est lui qui est chargé d’afficher des données provenant de la table ##_content), il utilisera dans ce cadre une vue de type article, l’id de l’objet à afficher est 22, l’architecture de la page à générer est celle correspondant à l’Itemid 437.Une fois les informations requises récoltées par le module JRouter , qui ? com_content, quoi ? l’article d’id 22, comment ? sous forme d’article avec la présentation Itemid 437, Joomla! peut passer à la phase suivante :
Etape 2 : Sachant désormais dans le détail ce qu’il a à faire et avec quoi, Joomla! commence par exécuter la requête SQL nécessaire à la récupération des données de la table ##_content et des tables liées relationnellement (il faut vérifier les droits, récupérer le nom de l’auteur etc etc …) depuis la base de données du site.
Etape 3 : Joomla! transmet ces données au template associé à l’article (celui du site par défaut), c’est lui qui ‘sait’ comment doit être présentée la page affichable, l’article d’id 22 n’est qu’un des éléments de cette page, les autres éléments qui doivent être présents sur cette page sont associés au menu qui a déclenché l’affichage de l’article (l’id du menu est contenue dans l’information Itemid passée dans les paramètres de l’url). Vous noterez qu’au cours de cette phase, votre article est inséré à l’emplacement, tel que vous l’avez déterminé dans le paramétrage de votre template et que la partie comprise entre les balises et est générée automatiquement en partie par Joomla! (vos paramètres de configuration), partie par votre template. Y accéder pour y mettre votre grain de sel, n’est plus aussi facile que dans les temps anciens. C’est toutefois toujours possible, mais, c’est une autre histoire …
Enrichissons le modèle …
Voilà, très succinctement, le cheminement suivi par Joomla! pour afficher un article en partant d’une url, mais puisque les données de l’article sont stockées dans la base de données, nous pouvons étendre le modèle et déterminer que désormais pour modifier l’affichage de la page, il suffit :
de changer le composant dans l’étape 1 et / ou
de changer la requête SQL dans l’étape 2 et / ou
de changer les modules du template dans l’étape 3
Cela peut se faire simplement en créant un nouveau menu sur notre site de démonstration, par exemple en ajoutant dans le menu ‘A propos de Joomla’ un nouveau sous-menu de type blog d’une catégorie avec comme paramètre la catégorie ‘Joomla!’ (catid = 19) ou encore un sous-menu de type liste des articles d’une catégorie toujours avec comme paramètre la catégorie ‘Joomla!’, ce qui permet , toujours avec les mêmes articles de présenter d’une autre manière les articles déjà saisis et enregistrés dans notre base de données.
Dans le premier cas (menu de type blog d’une catégorie), le navigateur verra passer une url telle que :
http://sitedemo.fr/index.php?option=com_content&view=category&layout=blog&id=19&Itemid=473
et dans le second (menu de type liste des articles d’une catégorie)
http://sitedemo.fr/index.php?option=com_content&view=category&id=19&Itemid=474
Que s’est il passé ? Ce sont toujours les mêmes articles qui sont affichées (ouf !), mais sous une autre forme, notre article ‘Comment démarrer ?’ est toujours affiché dans notre site et l’examen des urls montre que c’est toujours le composant com_content qui travaille, la vue (view) est passée de la valeur article à category, avec dans le premier cas en plus un mode de présentation (layout) sous forme de blog (en fait dans le second cas, le layout : list est implicite). La valeur id représente désormais celle de la catégorie au lieu de celle de l’article et le mode de présentation Itemid est lui toujours présent avec un id de menu différent bien entendu. En fait l’étape 2 présentée ci-dessus a utilisé une autre requête SQL, pour le même composant et les mêmes données afin d’obtenir une présentation visuelle totalement différente.
On peut également, pour des besoins précis, sans changer les paramètres du composant dans les urls, modifier le composant lui-même, cela s’effectue (assez) facilement en surchargeant la présentation du module concerné (com_content) dans le template du site comme l’a démontré Christian Bardin dans le n° 0 du magazine, début Juillet.
Dans tous ces cas de figure, vos données, stockées une fois et une seule en un emplacement unique (la base de données de Joomla!) peuvent être présentées de multiples façons sans jamais devoir ré-écrire une nouvelle page html, et c’est ce qui rend les CMS et Joomla! en particulier si avantageux à l’usage. Je n’ose imaginer la quantité de développement qui aurait été nécessaire en 2001-2002 pour réaliser les trois opérations ci-dessus : affichage d’un article, affichage en mode blog des articles de même catégorie et affichage d’une liste des articles relevant de cette même catégorie tout en s’assurant que la présentation restait cohérente d’une page html à l’autre et d’une modification à l’autre ….