Contrairement aux autres articles de ce site, aucune référence hyper-texte ne sera indiquée dans cet article, surtout pas vers toutes les pages de ce site SPN qui détaillent déjà depuis longtemps tous les points abordés ci-dessous : c’est volontairement à l’image du comportement proposé dans notre ’cas d’école’ !
Plantons le décor
Plutôt que de récapituler tous les besoins de communications ou de documentation partagée dans l’équivalent d’un Cahier des Charges, partons du site public initial : WordPress est reconnu comme un excellent outil pour mettre rapidement en place un site-vitrine, aussi qualifiée de site institutionnel, qui garantit et étaye un espace de présentation de la structure visible sur le monde Internet. D’ailleurs la plus grande force de WP se trouve dans la multitude de thèmes de présentations graphiques disponibles ou payants sans efforts, pour avoir belle gueule à l’écran. Cumulant 43% des sites au niveau mondial, une telle majorité [1] ne saurait se tromper...
Toute la difficulté a commencé quand des besoins autres sont apparus : on espère bien sûr une solution ’Clic and play’ comme dans une impression 3D ! Faute d’outil ou d’addon disponible pour dépasser un simple système de publication statutaire (d’ailleurs fort délaissé car non pratiqué), on se lance à d’autres logiciels (évidemment libres) qui fleurissent dans les écosystèmes associatifs voisins, avec la fiabilité et la pérennité qui vont avec, bien sûr sans documentation explicite, ni formation, ni même administration du fait d’une rotation régulière des administrateurs successifs qui n’arrivent même plus à informer les nouveaux adhérents des possibilités à utiliser, voire simplement à les inscrire. A chacun de découvrir comme il peut (ou pas)... Il est vrai que dans l’activité de cette association, contrairement à ce que pourrait laisser imaginer son image au public, tout projet commence par la construction de fichiers informatiques avec divers logiciels plutôt spécialisés, là aussi à "découvrir librement" sans piste, ni tutorat ni aide....
Rappelons les bases d’un site Web
Le fonctionnement basé sur un serveur sera abordé plus loin, quand l’administrateur voudra mettre les mains dedans, excellent démarche d’un maker pour savoir "faire" !
Dans un site public dynamique comme WP ou SPIP, les pages sont des fichiers affichables, calculés par un programme exécutable sur un serveur à partir de données mise en tables informatiques au moment de l’édition-préparation de la page.
Dans SPIP comme dans WP, on a d’abord une table des auteurs (ou users) qui stocke les identifications des personnes habilitées à intervenir, mais SPIP est pluspermet de gérer des statuts d’édition.
Ensuite on a une table d’enregistrement des paramètres internes (options pour WP ou métas pour SPIP), la table des contenus (posts pour WP, Articles pour SPIP), une table des réactions (commentaires pour WP ou forums pour SPIP), et puis....
Déjà SPIP intègre dès ses débuts les tables de Documents (gérer les fichiers joints, juste stockés dans des dossiers mensuels en WP) et les Mots-clés (nativement gérés par groupes en SPIP, alors que les taxonomies, d’étiquettes ou de catégories ont été rajoutées par les thèmes de WP).
Deux architectures à l’opposé
L’organisation [2] commence nettement à diverger :
Alors que SPIP adoptait d’entrée une architecture globale de structuration et gestion des tables organisant auteurs et articles autour d’une arborescence de rubriques (récursive, c’est-à-dire se hiérarchisant sans limite de niveaux), et un processus de modélisation des pages d’affichage généralisable (et généralisé) en squelettes, autour de boucles autonomes, WP se bâtit autour d’une boucle unique intégrée à l’affichage de la page type [3].
De même la définition du modèle de page par l’utilisateur webmestre obéit à deux approches très différentes, même si les deux outils proposent un éditeur interne, des constructeurs de pages par blocs, et la gestion de thèmes colorés : en pratique dans un des cas, le webmestre doit interagir avec les fichiers d’origine, modifiés en-ligne, et mêlant HTML, CSS, shortcodes, et PHP au risque de planter tout le site en cas d’erreur de syntaxe informatique dans l’un de ces nombreux langages [4], tandis que SPIP propose de base un fichier uniquement HTML/CSS pour chaque page-type, et force une copie préalable pour toute version modifiée, qu’il suffit de supprimer pour revenir au fonctionnement nominal sécurisé !
La page présentée doit servir à afficher des données lues dans la table des contenus, choisies avec des critères de sélections : là aussi, alors que WP nécessite des circonlocutions, ses ’shortcodes’ ou des fonctions PHP spécialement adaptées à chaque cas, SPIP se satisfait d’introduire, pour lire toute donnée, juste deux types d’expressions HTML [5] de balises, qui sont : une balise de <BOUCLE_..> suivi du nom de table ciblée (Articles, Auteurs, Rubriques ou toute autre définie) pour dire ce que l’on cherche (on précisera l’écriture des critères après), et une balise au seul nom de chaque champ de table affiché [6].
Pour résumer en une comparaison concrète, WP propose rapidement une maison de plein-pied, lumineuse et aux couleurs interchangeables, mais on ne peut y rajouter un étage ; à contrario, la structure native de SPIP [7] offre la possibilité d’entasser étages et extensions, toujours compatibles.
Là où cette architecture devient réellement intéressante, c’est qu’elle s’appliquera aussi à toute nouvelle table créée pour gérer un autre objet ou information... sans aucune autre déclaration ; encore plus fort, si on veut relier plusieurs tables pour effectuer une recherche (comme de rechercher les documents de type image jpg utilisés dans les articles d’une rubrique écrits par l’un des auteurs parmi une liste ...) il suffit d’adapter la page-type, en ajoutant des tables cibles dans le texte de boucle, sans même devoir en détailler tous les critères en corrélation..
Sécurité d’extensions et personnalisations
Étendre les fonctionnalités d’un site Internet implique de nouvelles pages-type, mais surtout de nouvelles données à saisir par des formulaires à développer : si malgré leurs architectures opposées les deux produits offrent des facilités de création de page par blocs sans programmation, la situation change pour la saisie en ligne. SPIP intègre la création de formulaires comme ajouts de champs dans les pages-type, gage de sécurité et de robustesse, avec l’automatisation proposé par une Fabrique générant les plugins à la bonne forme.
Coté performances et sécurité, ce produit logiciel français est aussi certifié et suivi que els plus grands ; d’ailleurs son architecture de cache compilé à deux niveaux (étendu sans programmation à toute extension) promet une bonne fluidité d’usage, maintenue même en cas de panne de la base de données (au prix d’une consommation supplémentaire d’espace disque).
Ajoutons des facilités d’analyse tournées vers le webmestre développeur, dont on commence seulement à voir apparaitre des équivalents en WP, et il est reconnu que la courbe d’apprentissage de SPIP est plus progressive et sans paliers d’arrêt à franchir, l’appropriation d’un outil francophone est facilitée.
la discussion s’interrompit pour mettre en œuvre sur PC portable l’installation par spip_loader en local...à suivre ?
Article publié le 9 février, et actualisé en février 2024 .
Répondre à cet article