# PARTIE V — Administration et maintenance
# CHAPITRE 27 — Mise à jour du module
Les mises à jour du module s'effectuent sans interruption visible côté visiteurs. Ce chapitre présente la procédure standard et les précautions à observer.
### Avant la mise à jour — liste de contrôle
**Sur une instance de production, ne sautez jamais ces étapes :**
- Sauvegarde complète de la base Dolibarr (mysqldump).
- Sauvegarde du dossier `htdocs/custom/infrasstudio/` existant.
- Sauvegarde des données : `DOL_DATA_ROOT//website/` et `medias/`.
- Lecture du changelog de la nouvelle version pour repérer d'éventuelles modifications majeures.
- Test de la mise à jour sur une instance de pré-production lorsque c'est possible.
### Procédure standard
##### **Étape 1 — Désactiver le module**
Configuration → Modules → InfraSStudio → cliquer sur **Désactiver**.
**Effet de la désactivation —** Les constantes du module sont sauvegardées sous le préfixe `INFRASSTUDIOBKP_`. Les tables et leurs données restent intactes. L'entrée Outils → InfraS disparaît.
##### **Étape 2 — Remplacer les fichiers**
Trois méthodes selon votre environnement :
**Via l'interface Dolibarr**
1. Configuration → Modules → bouton **« Déployer / installer un module »**.
2. Sélectionner la nouvelle archive `module_infrasstudio-X.Y.Z.zip`.
3. Confirmer le remplacement.
**Via SSH ou FTP**
```
cd /var/www/dolibarr/htdocs/custom/
mv infrasstudio infrasstudio.old.20260504
unzip /tmp/module_infrasstudio-1.9.0.zip
chown -R www-data:www-data infrasstudio/
```
**Via Git**
```
cd /var/www/dolibarr/htdocs/custom/infrasstudio
git fetch --tags
git checkout v1.9.0
```
##### **Étape 3 — Réactiver le module**
1. Configuration → Modules → InfraSStudio → cliquer sur **Activer**.
2. Le module exécute alors :
- la restauration des constantes `INFRASSTUDIOBKP_` vers `INFRASSTUDIO_`,
- l'application des migrations SQL nécessaires (fichiers `sql/update_X.Y.Z_*.sql`),
- le réenregistrement des hooks et triggers,
- la mise à jour de la constante `INFRASSTUDIO_MAIN_VERSION`.
##### **Étape 4 — Vérifier avec la page Diagnostic**
***Outils → InfraSStudio → Diagnostic***. L'ensemble des contrôles doit être au vert. La section Schéma SQL confirme en particulier que toutes les tables sont à jour.
##### **Étape 5 — Test fonctionnel**
Reproduisez trois actions courantes :
1. Ouvrir une page existante dans l'éditeur — l'aperçu doit se charger.
2. Modifier un slot — l'enregistrement automatique doit fonctionner (indicateur « Enregistré »).
3. Publier les modifications — vérifier que la version publique reflète bien la modification.
### Lire le changelog avant chaque mise à jour
Le changelog est accessible :
- Dans le module : `htdocs/custom/infrasstudio/docs/changelog.xml`.
- Dans l'administration : Outils → InfraSStudio → onglet Changelog.
##### **Lire les types de changement**
| Type
| Signification
|
|---|
| `fix`
| Correction d'une anomalie.
|
| `chg`
| Modification d'un comportement existant.
|
| `add`
| Nouvelle fonctionnalité ou option.
|
##### **Numérotation X.Y.Z**
| Composant
| Cas de modification
|
|---|
| **X (majeur)**
| La version Dolibarr minimale prise en charge change.
|
| **Y (mineur)**
| Une nouvelle fonctionnalité ou option utilisateur est ajoutée.
|
| **Z (correctif)**
| Corrections et modifications internes uniquement.
|
### Fréquence des mises à jour
Recommandations :
- **Correctif (Z)** : à appliquer rapidement, surtout si l'anomalie corrigée vous concerne.
- **Mineur (Y)** : à appliquer dans les une à deux semaines, après lecture du changelog.
- **Majeur (X)** : à tester en pré-production, à planifier dans une fenêtre de maintenance, à communiquer à votre équipe.
### Retour en arrière
Si une mise à jour pose problème :
1. Désactivez le module.
2. Restaurez le dossier `infrasstudio.old./` sauvegardé à l'étape 2.
3. Si une migration SQL a été appliquée, restaurez la base depuis le dump précédent.
4. Réactivez le module.
**Avertissement — Restauration SQL —** Une migration ajoute parfois des colonnes ou des tables. Si vous restaurez le dump pré-migration sans restaurer également les fichiers, le module détectera des structures manquantes et s'interrompra. Synchronisez toujours fichiers et base de données ensemble.
### Récapitulatif
**Vous savez désormais :**
- Préparer une mise à jour avec une liste de contrôle (sauvegarde base, fichiers, données).
- Suivre la procédure en cinq étapes (désactiver, remplacer, réactiver, diagnostic, test).
- Lire le changelog et comprendre la numérotation X.Y.Z.
- Appliquer la fréquence appropriée selon le type de version.
- Revenir en arrière en cas d'incident.
**Fin de la Partie V —** Vous savez gérer le module en tant qu'administrateur : permissions, configuration avancée, résolution des incidents, mises à jour. Le module est désormais entre des mains compétentes.
La Partie VI propose la référence pure du module : tableaux exhaustifs des constantes, des shortcodes, des hooks, des tables SQL et des scripts en ligne de commande. À garder à portée pour une consultation rapide.
# CHAPITRE 26 — Diagnostic et résolution des incidents
Lorsqu'un comportement inattendu apparaît, ce chapitre vous guide dans la résolution. Le réflexe à adopter est simple : commencer par la page Diagnostic, lire les journaux, et n'envisager une action plus radicale qu'en dernier recours.
### Toujours commencer par la page Diagnostic
***Outils → InfraSStudio → onglet Diagnostic***. Le contrôle visuel (vert, orange, rouge) couvre :
- Versions de Dolibarr et de PHP, présence des extensions PHP requises.
- État du module et de sa dépendance Website.
- Présence des cinq tables SQL du module.
- Permissions d'écriture sur `DOL_DATA_ROOT`.
- Hooks chargés, présence du trigger, déclaration des tâches planifiées.
- Pour chaque site géré : résolution du docroot, mode média, dossier de données.
**À retenir —** 80 % des incidents signalés sont en réalité une ligne rouge ou orange du Diagnostic ignorée. Demandez systématiquement à toute personne qui rapporte un dysfonctionnement de joindre d'abord cette capture.
### Lire les journaux Dolibarr
Le module utilise `dol_syslog()` pour tracer les opérations sensibles, avec le préfixe `infrasstudio`.
##### **Emplacement**
```
htdocs/documents/dolibarr.log
```
##### **Filtrer les entrées du module**
```
# Toutes les entrées du module
grep "infrasstudio" htdocs/documents/dolibarr.log
# Uniquement les erreurs
grep "infrasstudio.*LOG_ERR" htdocs/documents/dolibarr.log
# Suivi en temps réel pendant qu'un utilisateur reproduit le problème
tail -f htdocs/documents/dolibarr.log | grep infrasstudio
```
**Conseil — Activer le niveau DEBUG —** Pour traquer un incident subtil, augmentez temporairement le niveau de journalisation Dolibarr (Configuration → Sécurité → Système) à `LOG_DEBUG`. Pensez à le rabaisser une fois le diagnostic terminé.
### Incidents fréquents et solutions
##### **Le menu InfraS n'apparaît pas dans Outils**
| **Cause probable**
| L'utilisateur ne possède pas la permission
`paramMenu`
.
|
| **Solution**
| Onglet Permissions de l'utilisateur, cocher
`paramMenu`
dans la section InfraSStudio.
|
##### **Les modifications ne sont pas visibles publiquement**
| **Cause probable**
| Modifications restées en brouillon sans être publiées.
|
| **Solution**
| Cliquer sur « Publier les modifications » dans la barre d'outils. Voir le Chapitre 12.
|
##### **L'aperçu affiche une erreur 404**
| **Cause probable**
| La page possède un type\_container
`other`
,
`menu`
ou
`setup`
, et le filtre du noyau la bloque.
|
| **Solution**
| Le module corrige automatiquement ce comportement depuis la version 1.8.7. Vérifiez que vous êtes en version 1.8.7 ou supérieure.
|
##### **Erreur réseau dans l'éditeur (erreur AJAX)**
| **Cause probable**
| Session Dolibarr expirée, ou avertissement PHP émis avant les en-têtes HTTP.
|
| **Solution**
| Recharger la page Studio (F5). Si le problème persiste, consultez
`dolibarr.log`
pour identifier l'erreur PHP réelle.
|
##### **Les images téléversées ne s'affichent pas publiquement**
| **Cause probable**
| Lien symbolique
`medias`
manquant ou cassé en mode native.
|
| **Solution**
| Recréer le lien symbolique avec
`ln -sfn ...`
, ou basculer le site en mode média
`module`
.
|
##### **Les wrappers solution-\*.php ne se génèrent pas**
| **Cause probable**
| `INFRASSTUDIO_WEBSITE_KEY`
ou
`INFRASSTUDIO_PUBLIC_DOCROOT`
non configurées.
|
| **Solution**
| Configurer ces deux constantes dans Outils → InfraSStudio → Configuration → Wrappers.
|
##### **Les slots ne se mettent pas à jour après modification du tpl.php**
| **Cause probable**
| Le scanner n'a pas été lancé.
|
| **Solution**
| Outils → InfraSStudio → Contenu → bouton « Rescanner ». Ou en ligne de commande :
`php scripts/rescan_slots.php `
.
|
### Réinitialiser le module
Si le module se trouve dans un état incohérent (utilisation impossible, erreurs SQL persistantes), vous pouvez le réinitialiser :
1. ***Configuration → Modules → InfraSStudio*** → cliquer sur **Désactiver**.
2. Le module sauvegarde toutes ses constantes sous le préfixe `INFRASSTUDIOBKP_`.
3. Cliquer à nouveau sur **Activer**.
4. Le module restaure ses constantes, recrée les tables manquantes et réenregistre les hooks.
**Aucune perte de données —** Les valeurs de slot, les médias et les traductions sont conservés dans leurs tables respectives. La désactivation puis réactivation ne touche qu'au descripteur et aux hooks.
### Demander de l'aide
Si rien ne fonctionne, préparez ces trois informations avant toute demande d'aide :
1. Capture d'écran de la page Diagnostic complète.
2. Les vingt dernières lignes de `dolibarr.log` filtrées sur `infrasstudio`.
3. La version exacte du module et de Dolibarr (visibles en haut de la page Diagnostic).
Avec ces trois éléments, n'importe quel développeur connaissant le module peut établir un diagnostic en quelques minutes.
### Récapitulatif
**Vous savez désormais :**
- Lancer la page Diagnostic comme premier réflexe.
- Lire et filtrer les journaux Dolibarr.
- Identifier les sept incidents fréquents et leurs solutions.
- Réinitialiser le module proprement (désactivation et réactivation).
- Préparer un rapport d'incident efficace en trois étapes.
# CHAPITRE 25 — Configuration avancée (constantes)
Le module expose une vingtaine de constantes Dolibarr qui permettent d'ajuster son comportement. Ce chapitre les classe par catégorie d'usage avec les valeurs typiques.
### Sites gérés
| Constante
| Description
|
|---|
| `INFRASSTUDIO_MANAGED_SITES`
| CSV des identifiants de sites gérés. Exemple :
`1,2,5`
.
|
| `INFRASSTUDIO_SITE__MEDIA_MODE`
| Mode média par site.
`native`
(par défaut) ou
`module`
.
|
| `INFRASSTUDIO_SITE__BLOG_INDEX_PAGE`
| Identifiant de la page d'index du blog (active l'assistant « + Nouvel article »).
|
| `INFRASSTUDIO_SITE__DOCROOT`
| Surcharge du docroot Apache pour ce site spécifique.
|
### Portabilité du système de fichiers
Pour les hébergements aux configurations non standards :
| Constante
| Description
|
|---|
| `INFRASSTUDIO_DOCROOT_PATTERN`
| Modèle de chemin partagé utilisant le marqueur
`{ref}`
. Exemple :
`/srv/sites/{ref}`
.
|
| `INFRASSTUDIO_TEMPLATE_EXTRA_DIR`
| Dossier supplémentaire à scanner pour les gabarits de page.
|
**Note — Cascade de résolution —** Pour le docroot d'un site, l'ordre de recherche est : `INFRASSTUDIO_SITE__DOCROOT`, puis `INFRASSTUDIO_DOCROOT_PATTERN`, puis le repli sur `/var/www/| Constante
| Description
|
|---|
| `INFRASSTUDIO_WEBSITE_KEY`
| Référence du site cible des wrappers solution.
|
| `INFRASSTUDIO_PUBLIC_DOCROOT`
| Docroot Apache absolu où écrire les wrappers.
|
| `INFRASSTUDIO_PRODUCT_UNIVERS_MAP`
| Surcharge JSON de la cartographie catégorie vers univers.
|
| `INFRASSTUDIO_TRANSLATABLE_PRODUCT_FIELDS`
| CSV de slugs de champs personnalisés à déclarer comme traduisibles, en complément du registre par défaut.
|
| `INFRASSTUDIO_TRANSLATABLE_PRODUCT_FIELDS_JSON`
| Surcharge JSON complète du registre.
|
| `INFRASSTUDIO_SITE__WRAPPER_PREFIX`
| Préfixe des wrappers (par défaut
`solution-`
).
|
| `INFRASSTUDIO_SITE__WRAPPER_TEMPLATE_PAGEURL`
| Slug du gabarit (par défaut
`solution-detail`
).
|
### Apparence du Studio
| Constante
| Valeurs
| Par défaut
|
|---|
| `INFRASSTUDIO_UI_THEME`
| `light`
,
`dark`
| `light`
|
| `INFRASSTUDIO_UI_ACCENT`
| `indigo`
,
`ochre`
,
`plum`
,
`forest`
| `indigo`
|
### Multilingue côté gabarits
| Constante
| Description
|
|---|
| `INFRASSTUDIO_LANG_ISO`
| Force la langue active. Définie dynamiquement par les gabarits.
|
| `INFRASSTUDIO_LANG_COOKIE`
| Nom du cookie de persistance de la langue (par défaut
`infras_lang`
).
|
| `INFRASSTUDIO_LANG_MAP_JSON`
| Surcharge de la cartographie ISO2 vers locale (exemple :
`{"en":"en_GB"}`
).
|
| `INFRASSTUDIO_BLOG_FALLBACK_IMAGE`
| Image par défaut affichée lorsqu'un article ne possède pas d'image principale.
|
### Compatibilité et débogage
| Constante
| Description
|
|---|
| `INFRASSTUDIO_DOL_VERSION`
| Version de Dolibarr lors de l'activation du module. Géré automatiquement.
|
| `INFRASSTUDIO_MAIN_VERSION`
| Version du module. Géré automatiquement.
|
| `INFRASSTUDIO_DISABLE_CHECK_VERSION_MIN`
| À régler sur
`1`
pour contourner la vérification de version Dolibarr minimale (usage avancé).
|
### Définir une constante
##### **Méthode A — Via l'administration du module**
La majorité des constantes sont accessibles dans Outils → InfraSStudio → Configuration, dans la section dépliable « Réglages avancés ». Le formulaire valide les saisies et affiche des avertissements non bloquants en cas d'incohérence.
##### **Méthode B — Via SQL**
```
INSERT INTO llx_const (name, value, type, visible, entity)
VALUES ('INFRASSTUDIO_DOCROOT_PATTERN', '/srv/sites/{ref}', 'chaine', 0, 2);
```
##### **Méthode C — Via PHP en ligne de commande**
```
php -r "
require 'htdocs/master.inc.php';
\$conf->entity = 2;
dolibarr_set_const(\$db, 'INFRASSTUDIO_DOCROOT_PATTERN', '/srv/sites/{ref}',
'chaine', 0, '', 2);
"
```
### Vérifier la configuration
Après chaque modification de constante, lancez la page Diagnostic du module. Elle valide en direct l'existence des chemins, la cohérence des modèles, etc.
### Récapitulatif
**Vous savez désormais :**
- Identifier les vingt constantes du module classées par usage.
- Comprendre la cascade de résolution du docroot.
- Configurer le catalogue produit (référence du site, docroot, préfixe, gabarit).
- Personnaliser l'apparence (thème, couleur d'accent).
- Définir une constante via l'administration, SQL ou ligne de commande.
- Valider une configuration via la page Diagnostic.
# CHAPITRE 24 — Permissions et rôles utilisateur
Le module expose sept permissions distinctes, attribuables finement aux utilisateurs Dolibarr. Ce chapitre vous indique les attributions à privilégier en fonction des rôles, dans l'esprit du principe de moindre privilège.
### Les sept permissions du module
| Permission
| Ce qu'elle autorise
|
|---|
| `paramMenu`
| Voir l'entrée InfraS dans le menu Outils. Sans cette permission, le module est invisible pour l'utilisateur.
|
| `readContent`
| Consulter le contenu (pages, slots, médias) en lecture seule. Aucune modification possible.
|
| `editContent`
| Modifier les valeurs des slots (textes, images, couleurs, etc.) en brouillon.
|
| `editTranslations`
| Saisir et modifier les traductions (slots et fiches produit).
|
| `editMedias`
| Téléverser, modifier et supprimer des médias dans la bibliothèque.
|
| `publish`
| Publier les brouillons en attente, mettre en ligne ou retirer des pages.
|
| `admin`
| Configurer le module (sites gérés, constantes), supprimer des pages, accéder au Diagnostic.
|
**Note —** Un utilisateur portant le drapeau Dolibarr « Super-administrateur » contourne toutes les permissions du module. Ce comportement est volontaire pour rester cohérent avec la philosophie de Dolibarr. Pour tester finement les permissions, utilisez un compte non administrateur.
### Les rôles types
Plutôt que d'attribuer les permissions une à une à chaque utilisateur, il est préférable de définir des profils que vous applique ensuite aux comptes.
##### **Lecteur**
Pour une personne qui consulte le site sans le modifier (commercial, support, juriste relisant la conformité).
##### **Rédacteur**
Pour une personne qui modifie les contenus mais ne publie pas seule (mise en place d'un circuit de relecture).
##### **Traducteur**
Pour une personne qui n'effectue que des traductions (souvent un prestataire externe).
##### **Rédacteur autonome**
Pour une personne qui rédige et publie seule (équipe restreinte, indépendant, etc.).
##### **Administrateur du module**
Pour le développeur de l'agence ou le responsable technique du site.
| Toutes les permissions
| Oui
|
### Attribuer les permissions à un utilisateur
1. Rendez-vous dans Accueil → Utilisateurs et Groupes → Liste des utilisateurs.
2. Sélectionnez l'utilisateur cible.
3. Cliquez sur l'onglet **Permissions**.
4. Faites défiler jusqu'à la section **InfraSStudio**.
5. Cochez les permissions à attribuer.
6. Enregistrez.
**Conseil — Utilisez les groupes —** Si vous administrez plusieurs rédacteurs, créez un groupe Dolibarr (par exemple « InfraS Rédacteurs ») et attribuez-lui les permissions. Les utilisateurs ajoutés au groupe en héritent automatiquement.
### Mettre en place un circuit de relecture
Voici comment exploiter les permissions pour un circuit de relecture propre :
| Acteur
| Permissions
| Tâche
|
|---|
| Rédacteur
| `readContent`
+
`editContent`
+
`editMedias`
| Modifie les slots et prépare les brouillons.
|
| Relecteur
| `readContent`
| Consulte les brouillons dans l'aperçu, valide ou demande des modifications.
|
| Publicateur
| `readContent`
+
`publish`
| Publie les brouillons après validation du relecteur.
|
### Récapitulatif
**Vous savez désormais :**
- Identifier les sept permissions du module.
- Définir cinq rôles types (lecteur, rédacteur, traducteur, rédacteur autonome, administrateur).
- Attribuer les permissions à un utilisateur ou à un groupe Dolibarr.
- Mettre en place un circuit de relecture à plusieurs.