# 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 : - Une base de données structurée (environ 300 tables préfixées `llx_`). - Un système d'utilisateurs avec gestion fine des permissions. - Une gestion multicompany permettant à plusieurs entités juridiques de cohabiter sur la même installation. - Un système de constantes pour le stockage des configurations. - Des classes métier réutilisables : `Product`, `Societe`, `Contact`, `User`, `CMailFile`, `Translate`, etc. - Un système de traductions par fichiers `.lang`. - Des mécanismes d'extension par hooks et triggers.

**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 : - Création d'une entrée dans la table `llx_website` contenant la référence, le virtualhost et les langues. - Stockage des pages dans la table `llx_website_page` avec leur contenu HTML. - Génération d'un fichier `page.tpl.php` sur le disque. - Création des wrappers Apache `.php` qui redirigent vers le bon template. - Prise en charge du multilingue via le mécanisme de pages sœurs.

**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 : - Le scanner de slots qui détecte automatiquement les zones éditables. - L'éditeur en trois colonnes accessible depuis l'interface Dolibarr. - La bibliothèque de médias mutualisée. - Le système de traductions, synchronisé avec les fichiers `.lang` de Dolibarr. - Le catalogue produit dynamique, qui transforme la table `llx_product` en pages publiques. - Le mécanisme de brouillons et de publication. - La génération automatique du sitemap et des balises hreflang. - Le système de gabarits permettant aux éditeurs de créer leurs propres pages. **Note — Ce qu'InfraSStudio ne fait pas** - Il ne sert pas les pages publiques. Cette fonction est assurée par Apache et le module Website. - Il ne stocke pas les pages elles-mêmes, qui restent dans `llx_website_page` et leurs templates correspondants. - Il ne gère pas les utilisateurs ni les permissions globales : ce sont les utilisateurs Dolibarr qui sont autorisés via les permissions du module. ### 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.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.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//medias///`
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 : - L'édition d'une fiche produit (libellé, prix, catégories, photos rattachées) reste l'usage standard de la fiche produit Dolibarr. Le module InfraSStudio n'édite que les extrafields traduisibles et leurs versions linguistiques, qui se synchronisent automatiquement avec la fiche native. - La gestion des tiers, des contacts, des devis et des factures s'effectue via les modules natifs Dolibarr. - L'administration des utilisateurs et des permissions reste dans l'interface d'administration Dolibarr. - La création d'un nouveau site Website (référence, virtualhost, langues principales) se fait dans l'administration du module Website. InfraSStudio prend ensuite le relais pour l'édition du contenu. - La sauvegarde de la base et des fichiers suit la procédure standard de 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 - **L'éditeur ne peut pas altérer la mise en page** Il modifie uniquement les zones identifiées comme slots. Les conteneurs, les classes CSS et l'ordre des sections lui sont totalement inaccessibles. - **Le design peut évoluer indépendamment du contenu** Une refonte ne casse pas les contenus existants. Les valeurs des slots sont conservées et viennent simplement remplir la nouvelle structure. - **La maintenance reste compréhensible dans la durée** 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. ```

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

``` 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 : - Le développeur peut consulter et modifier le template sans craindre une pollution par les modifications de l'éditeur. - Si vous purgez la table des slots, le site affichera simplement les valeurs par défaut, sans cesser de fonctionner. - L'export du code d'un site et l'export de son contenu sont deux opérations distinctes, ce qui simplifie les migrations. #### 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 - Modifier rapidement un texte ou une image, sans craindre d'altérer la mise en page. - Visualiser immédiatement le résultat de vos modifications. - Travailler sans dépendance technique : ne pas avoir à solliciter un développeur pour chaque ajustement. - Gérer les versions linguistiques sans dupliquer les pages. - Préparer plusieurs modifications avant publication, et tout publier en une fois. ##### 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 - Conserver la maîtrise complète du HTML, du CSS et de la structure des pages. - Permettre à votre client d'éditer ses contenus sans solliciter votre intervention. - Réutiliser une même structure pour des pages similaires. - Afficher des données Dolibarr (produits, catégories, informations société) sans dupliquer ces informations. - Livrer un site dont la maintenance courante ne vous incombe pas. ##### 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 - Installer le module sans surprise et de manière reproductible. - Vérifier que l'intégration est complète : versions compatibles, tables créées, hooks en place, tâches planifiées actives. - Distribuer les permissions selon les rôles de chacun. - Disposer de points de vérification clairs en cas de problème. - Maîtriser les mises à jour sans interruption du site public. ##### 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. ```

Bienvenue sur notre site

{{slot:hero_title|type=text|default=Bienvenue sur notre site}}

``` 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.