Partie I — Comprendre InfraSStudio

CHAPITRE 4 — InfraSStudio dans l'écosystème Dolibarr

Pour utiliser le module efficacement, il est utile de comprendre son positionnement par rapport à Dolibarr et au module Website natif. Ce chapitre présente la répartition des rôles, les dépendances et les limites de la responsabilité du module.

Une analogie pour introduire

L'écosystème Dolibarr et ses extensions peuvent être comparés à un musée et sa galerie d'exposition.

Composant

Rôle

Dolibarr ERP

Le musée. Il abrite les collections (produits, tiers, médias), les notices (libellés multilingues) et les registres (ventes, factures).

Module Website

La galerie d'exposition. Elle définit l'espace et l'éclairage où les œuvres choisies sont présentées au public.

InfraSStudio

Le commissaire d'exposition. Il choisit la mise en valeur des œuvres existantes, sans intervenir sur les œuvres elles-mêmes. Il rédige les notices et organise les parcours.

Lorsqu'une nouvelle œuvre rejoint les collections du musée, elle est automatiquement présentée dans la galerie selon la mise en page prévue. C'est le rôle du catalogue produit dynamique, présenté en détail au Chapitre 15.

Une architecture en trois couches

Le module fonctionne dans un système composé de trois couches superposées, chacune avec un rôle précis.

Couche

Rôle

InfraSStudio

Édition des slots et des médias, gestion des traductions, catalogue produit dynamique, fonctionnalités de blog, outils de référencement.

Module Website (natif Dolibarr)

Stockage des pages, génération des fichiers Apache, gestion des virtualhosts, support multicompany.

Dolibarr ERP

Tiers, produits, factures, utilisateurs, permissions, traductions, base de données, médias.

Chaque couche s'appuie sur celle qui se trouve en dessous, sans la remplacer ni la dupliquer.

Dolibarr ERP, la couche fondamentale

Dolibarr ERP constitue le socle. Il fournit l'ensemble des services dont les couches supérieures ont besoin :

Recommandé — Le module s'appuie systématiquement sur les classes natives de Dolibarr lorsque c'est possible. Cette approche garantit la cohérence avec le reste de l'instance et limite les divergences en cas de mise à jour de Dolibarr.

Le module Website, la couche d'hébergement

Le module Website est livré nativement avec Dolibarr. Pour chaque site qu'il prend en charge, il assure les fonctions suivantes :

Important — Le module Website est l'hôte d'InfraSStudio. Sans lui, le module n'a rien à éditer. La dépendance est inscrite dans le descripteur : InfraSStudio refuse de s'activer si le module Website ne l'est pas.

Le module InfraSStudio, la couche d'édition

InfraSStudio ajoute par-dessus le module Website l'ensemble des fonctionnalités nécessaires à un usage par des utilisateurs non techniques :

Note — Ce qu'InfraSStudio ne fait pas

Le déroulement d'une requête publique

Pour clarifier le rôle de chaque couche, suivons le parcours d'une requête HTTP de bout en bout :

  1. Le visiteur demande une URL, par exemple https://exemple.com/page1.php.
  2. Apache reçoit la requête. Le virtualhost pointe vers le docroot du site.
  3. Le wrapper page1.php, généré par le module Website, inclut le fichier master.inc.php local et amorce Dolibarr.
  4. Le wrapper inclut ensuite le fichier page<N>.tpl.php correspondant.
  5. Le template produit le HTML, contenant encore les tokens {{slot:...}} et {{shortcode:...}}.
  6. InfraSStudio intercepte le HTML via le hook completeHtmlOutput et résout chaque token : valeurs courantes des slots filtrées par la locale du visiteur, données Dolibarr lues en direct.
  7. Apache transmet au navigateur le HTML final, dépourvu de tout token.

Résultat — Du point de vue du navigateur, la page est un document HTML standard. Aucun token n'est visible et aucun traitement JavaScript spécifique n'est nécessaire.

L'emplacement des données

Pour comprendre le module en profondeur, le tableau ci-dessous récapitule où chaque type de donnée est stocké.

Donnée

Emplacement

HTML d'une page (avec tokens)

Disque (

page<N>.tpl.php

) et base (

llx_website_page.content

)

Métadonnées de page (titre SEO, description)

llx_website_page.title

,

description

,

keywords

,

image

Valeurs des slots

llx_infrasstudio_slot

Brouillons en attente de publication

llx_infrasstudio_slot.value_draft

Médias téléversés

DOL_DATA_ROOT/<entity>/medias/<type>/<site>/

Métadonnées des médias

llx_infrasstudio_media

Texte alternatif par locale

llx_infrasstudio_media_alt

Traductions natives produit

llx_product

(FR) et

llx_product_lang

(autres locales)

Traductions des extrafields produit

llx_product_extrafields

et

llx_infrasstudio_product_translation

Historique des modifications

llx_infrasstudio_revision

Configuration du module

llx_const

(constantes préfixées

INFRASSTUDIO_

)

Ce qui reste géré dans Dolibarr lui-même

Le module ne remplace aucun module Dolibarr existant. Les opérations suivantes continuent à se faire dans Dolibarr :

Recommandé — Le module ne crée aucun outil parallèle pour ces fonctions. Il s'appuie sur l'existant, ce qui simplifie la formation et limite la duplication d'information.

CHAPITRE 3 — Le principe de séparation entre contenu et design


Une analogie pour comprendre

Le rapport entre développeur et éditeur peut être comparé à celui qui unit un architecte et l'occupant d'un appartement.

Rôle

Responsabilité

L'architecte

Conçoit les murs, les ouvertures, les volumes, les circulations. Une fois le chantier livré, sa mission est terminée.

L'occupant

Choisit la peinture, le mobilier, l'agencement. Vit dans le logement et l'adapte à ses besoins, dans le respect des volumes existants.

InfraSStudio applique le même découpage à votre site. Le développeur conçoit la structure et la livre. L'éditeur en remplit les contenus, sans toucher aux volumes.

Cette discipline est la condition pour qu'un site reste maintenable et cohérent dans la durée.

L'approche fondamentale du module se résume à un principe simple :

Le design relève de la responsabilité du développeur. Le contenu relève de celle de l'éditeur. Les deux périmètres ne se superposent jamais.

Cette séparation détermine l'architecture du module, le fonctionnement de l'éditeur, le découpage des permissions et même les fonctionnalités qui ne sont volontairement pas implémentées.

Pourquoi cette séparation est essentielle

Dans la majorité des outils de gestion de contenu, les frontières entre contenu et structure finissent par s'estomper. Le rédacteur a accès au HTML, au CSS, à la mise en page. À l'usage, il modifie sans s'en rendre compte des éléments structurels — parce que les outils l'autorisent à toucher à ce qui ne devrait pas l'être.

InfraSStudio adopte la position inverse : la structure est verrouillée et seules les zones explicitement marquées comme éditables par le développeur sont accessibles à l'éditeur.

Bénéfices observés

Il modifie uniquement les zones identifiées comme slots. Les conteneurs, les classes CSS et l'ordre des sections lui sont totalement inaccessibles.

Une refonte ne casse pas les contenus existants. Les valeurs des slots sont conservées et viennent simplement remplir la nouvelle structure.

Plusieurs mois après la livraison, un autre développeur peut reprendre le code et identifier sans ambiguïté ce qui est éditable et ce qui ne l'est pas.

Les mécanismes qui matérialisent cette séparation

La séparation n'est pas une simple convention, elle est inscrite à plusieurs niveaux dans le fonctionnement technique du module.

Le HTML reste sous le contrôle du développeur

Le HTML d'une page Dolibarr Website est stocké dans deux emplacements synchronisés : la base de données et un fichier .tpl.php sur le disque. Le module ne propose à aucun moment d'éditer ce HTML. Il n'existe pas de bouton « voir le code source », pas d'éditeur de texte brut, pas d'option dissimulée. L'éditeur n'a accès qu'aux zones marquées comme slots, le reste lui demeure transparent.

Les slots sont détectés automatiquement

Lorsque le développeur ajoute un slot dans un template, aucune autre opération n'est nécessaire. Le module dispose d'un scanner qui parcourt les fichiers .tpl.php du site, détecte les tokens {{slot:...}}, les enregistre dans la table dédiée et génère l'interface d'édition correspondante.

<h2>{{slot:section_title|type=text|default=Nos services|label=Titre de la section}}</h2>

Au prochain rescan, manuel ou automatique, le slot apparaît dans le panneau d'édition. Aucune configuration intermédiaire n'est requise.

Le rendu public est transparent

Lorsqu'un visiteur consulte une page publique, le navigateur ne voit jamais de slot. Le module intercepte le HTML avant son envoi, remplace chaque token {{slot:...}} par sa valeur courante et transmet au visiteur un document HTML standard.

Cette substitution intervient au moment du rendu, jamais au moment de l'édition. Le fichier .tpl.php conserve toujours les tokens originaux, ce qui présente plusieurs avantages :

Les permissions traduisent la séparation

Le module définit sept permissions Dolibarr distinctes, qui permettent d'adapter précisément l'accès aux différents rôles :

Permission

Destinataire type

paramMenu

Tout utilisateur autorisé à voir le menu du module

readContent

Lecteur seul, par exemple un commercial qui consulte le site avant un rendez-vous

editContent

Rédacteur autorisé à modifier les slots de texte

editTranslations

Traducteur intervenant sur les versions linguistiques

editMedias

Gestionnaire des médias, autorisé à téléverser et remplacer des images

publish

Responsable de la publication finale des contenus

admin

Administrateur du module : configuration, sites gérés, gabarits

En pratique, un rédacteur reçoit en général readContent et editContent. Un traducteur reçoit editTranslations. L'intégrateur conserve admin. Aucune permission n'est attribuée au-delà du strict nécessaire.

Ce qui n'est volontairement pas proposé

Pour rester fidèle à ce principe, certaines fonctionnalités ne sont pas implémentées. Ce choix est délibéré.

Pas d'éditeur visuel par blocs

Il n'est pas possible de déposer des blocs à la souris pour composer une page. La structure reste codée par le développeur. Si une nouvelle section est nécessaire, deux options se présentent : utiliser un slot de type richtext, qui autorise une mise en forme limitée à l'intérieur d'une zone existante, ou demander au développeur d'ajouter un nouvel emplacement dans le template.

Pourquoi — Les éditeurs visuels par blocs produisent fréquemment des pages incohérentes lorsque l'utilisateur n'est pas formé à la mise en page. La structure verrouillée garantit la cohérence visuelle dans la durée.

Pas d'édition HTML brute

Même un éditeur expérimenté ne dispose pas d'un mode permettant de modifier le HTML directement. Les slots de type richtext proposent un éditeur visuel avec mise en forme (gras, italique, listes, liens, sous-titres) mais aucun bouton « source ».

Pourquoi — L'édition de HTML brut est la première source d'erreurs de mise en forme. Si une présentation spécifique est nécessaire, elle relève du CSS, et donc du développeur, non du contenu.

Pas de gestion de menus côté éditeur

Les menus de navigation (en-tête, pied de page) sont des pages Dolibarr Website particulières. Elles peuvent comporter des slots pour les libellés, le logo ou les liens sociaux, mais l'ordre des éléments et la structure restent codés dans le HTML.

Pourquoi — La navigation est un élément structurel du site, non un contenu éditorial. Sa modification doit être un acte délibéré du développeur, non un effet de bord d'une manipulation par l'éditeur.

Pas de logique conditionnelle dans les slots

Les slots ne portent aucune logique métier. Il n'est pas possible de définir une règle du type « afficher ce texte uniquement si l'utilisateur est connecté ». Les slots sont strictement des conteneurs de contenu.

Pourquoi — La logique relève du PHP, donc du développeur. Mêler logique et contenu rend les sites difficiles à maintenir au-delà de quelques années.

CHAPITRE 2 — À qui s'adresse le module


InfraSStudio s'adresse à trois publics qui collaborent autour d'un même site web. Identifier votre rôle vous aidera à repérer les sections de cette documentation qui vous concernent en priorité.

Le rédacteur ou utilisateur final

Vous êtes en charge de la rédaction ou de la mise à jour des contenus publiés sur votre site.

Conseil — Votre lecture prioritaire est la Partie III. Commencez par le Chapitre 9 pour le tour de l'interface, puis le Chapitre 10 pour vos premières modifications.

Vos attentes
Ce que le module vous apporte

Fonctionnalité

Avantages

Interface en trois colonnes

Liste des pages, aperçu en direct et formulaires d'édition rassemblés dans un seul écran.

Édition au clic

Cliquer sur un texte de l'aperçu ouvre directement le formulaire correspondant.

Bibliothèque média partagée

Réutilisation des images d'une page à l'autre sans téléchargement répété.

Mécanisme de publication

Les modifications restent privées tant qu'elles ne sont pas explicitement publiées.

Onglets de langue

Bascule rapide entre les versions linguistiques, avec drapeaux comme repères visuels.

Le développeur intégrateur

Vous êtes en charge de la conception ou de l'évolution technique d'un site Dolibarr Website.

Conseil — Votre lecture prioritaire est la Partie IV pour les aspects pratiques, complétée par la Partie VI en référence.

Vos attentes
Ce que le module vous apporte

Outil

Usage

Système de slots

Rendre éditable n'importe quelle balise HTML par l'ajout d'un token

{{slot:nom|type=...}}

.

Shortcodes

Insérer des données Dolibarr en direct :

{{product:ref=xxx.label}}

,

{{mysoc.name}}

, etc.

Catalogue de gabarits

Modèles de page réutilisables (page libre, article, landing produit) que vos clients peuvent instancier.

Génération automatique de pages produit

Un seul template pour N produits Dolibarr ; le module génère automatiquement les pages publiques.

Outils en ligne de commande

Scripts pour le rescan des slots, la génération de sitemap, les migrations, intégrables dans des pipelines.

L'administrateur Dolibarr

Vous êtes en charge de l'instance Dolibarr : installation, mises à jour, permissions, sauvegardes.

Conseil — Votre lecture prioritaire est la Partie II pour la mise en service, puis la Partie V pour la maintenance.

Vos attentes
Ce que le module vous apporte

Outil

Usage

Module Dolibarr standard

Installation par la procédure classique des modules externes Dolibarr.

Page Diagnostic

Vérification automatisée de tous les points d'intégration : versions, extensions PHP, tables, hooks, tâches planifiées, état des sites.

Permissions granulaires

Sept permissions distinctes pour adapter l'accès à chaque rôle.

Mécanismes de portabilité

Constantes de configuration permettant l'adaptation à différents types d'hébergement.

Historique des versions

Changelog au format XML standard Dolibarr, consultable depuis l'administration.

Le cas des équipes réduites

Sur de nombreuses installations, une seule personne porte plusieurs rôles. C'est typiquement le cas du consultant indépendant qui livre un site à un petit commerce, de l'agence où le développeur senior assure aussi l'administration, ou du dirigeant d'une jeune entreprise qui édite lui-même son site avant de pouvoir déléguer.

Recommandé — Si vous combinez plusieurs rôles, lisez la documentation dans l'ordre des parties. Le ton et le niveau technique évoluent progressivement, du général vers le spécifique.

CHAPITRE 1 — Qu'est-ce qu'InfraSStudio ?

Définition

InfraSStudio est un module d'édition de contenu pour Dolibarr. Il s'installe par-dessus le module Website natif de Dolibarr et permet aux utilisateurs non techniques de modifier les textes, les images et les données affichées sur leur site web public, sans manipuler de code HTML ni de base de données.

Le module est conçu pour s'intégrer dans le quotidien d'une équipe : le développeur livre la structure d'un site, l'éditeur en remplit les contenus, et chacun reste dans son rôle.

Le besoin auquel il répond

Dolibarr propose depuis plusieurs versions un module Website complet, capable de gérer des pages, des langues, des images et des virtualhosts. Toutefois, l'édition d'une page passe par la modification directe du HTML stocké en base. Pour un développeur, cette opération est triviale ; pour la personne chargée de rédiger des contenus marketing, d'actualiser des fiches ou d'ajuster une page de contact, elle constitue un obstacle.

Sans outil intermédiaire, le scénario qui se reproduit régulièrement est le suivant :

  1. Le développeur livre un site abouti.
  2. Plusieurs mois plus tard, un changement mineur est demandé par le client.
  3. Le client ouvre l'éditeur de Dolibarr, voit du HTML, hésite à modifier.
  4. Une demande est envoyée par e-mail au développeur.
  5. La modification, qui prend quelques minutes, est appliquée plusieurs jours plus tard, après deux ou trois échanges.

InfraSStudio interrompt ce cycle. Le développeur conserve la responsabilité du HTML, mais y insère des balises invisibles aux endroits qui doivent rester modifiables. Lorsque l'éditeur ouvre l'interface du module, il voit non plus du code, mais des champs de formulaire correspondant exactement aux zones éditables. Il modifie, il enregistre, le site est à jour.

Le principe de fonctionnement

L'unité de base du module est le slot. Un slot est un emplacement nommé dans une page, déclaré par le développeur dans le HTML, qui correspond à une zone éditable. Chaque slot possède un type (texte court, texte riche, image, lien, couleur, etc.) et, si nécessaire, une valeur par défaut.

<!-- Page non éditable -->
<h1>Bienvenue sur notre site</h1>

<!-- Page rendue éditable via InfraSStudio -->
<h1>{{slot:hero_title|type=text|default=Bienvenue sur notre site}}</h1>

Le HTML reste lisible pour le développeur. Lorsqu'un visiteur consulte la page publique, le module substitue le slot par sa valeur courante avant l'envoi au navigateur. Dans l'interface du module, l'éditeur ne voit pas le HTML mais un champ de saisie nommé « Hero Title » avec un bouton de validation.

Ce que le module n'est pas

Pour situer correctement InfraSStudio, il est utile de préciser ce qu'il ne cherche pas à être :

Ce n'est pas

Pourquoi

Un éditeur visuel par blocs (de type Elementor, Divi, WordPress Gutenberg)

La structure des pages reste codée par le développeur. L'éditeur remplit les emplacements prévus, sans réorganiser la mise en page.

Un thème prêt à l'emploi

Le module ne fournit pas de composants visuels, mais une couche d'édition pour le HTML que vous écrivez.

Un système de gestion de contenu autonome

Le module dépend de Dolibarr et du module Website. Il fonctionne comme une surcouche, non comme un remplacement.


Ce que le module apporte

Fonctionnalités

Avantages

Un éditeur de slots

Détecte automatiquement les zones éditables dans le HTML et génère l'interface de saisie correspondante.

Une bibliothèque de médias centralisée

Gère les images, vidéos et documents partagés entre les pages.

Un système de traduction local

Aligné sur les langues prises en charge par Dolibarr.

Un éditeur de fiches produit

Transforme le catalogue Dolibarr en pages web dynamiques.

Une gestion de blog

Repose sur les pages standard du module Website, sans table dédiée.

Un mécanisme de brouillons et de publication

Prépare plusieurs modifications avant de les rendre visibles.

Des outils de référencement intégrés

Offrent un aperçu des résultats Google ainsi que la génération de sitemap et de balises hreflang multilingues.


La promesse du module

Le développeur conserve le contrôle du HTML. L'éditeur conserve le contrôle du contenu. Chacun travaille dans son périmètre, sans empiéter sur celui de l'autre.