Installation

Cette page couvre l'installation de @lrvo/module-pages dans un projet déjà structuré par @lrvo/start. Le module n'est jamais déclaré à la main : il est découvert au boot par scan des dépendances, comme décrit dans Cycle de vie d'un module.

Prérequis

• Un projet généré par npx @lrvo/start, avec @lrvo/core installé.
• L'accès au registre privé configuré. Voir Installation.

Installer

npm i @lrvo/module-pages

Ajouter la variable d'activation au .env :

#------ MODULE - PAGES ------#
LRVO_MODULE_PAGES=true

Sans ce drapeau, le module est ignoré : aucune table, aucune route, aucune entrée d'admin. Le détail des variables est dans Configuration.

Régénérer les manifestes puis créer la table :

npx lrvo-modules sync    # déclenché automatiquement au postinstall
npx lrvo-db init         # crée lrvo_pages_page

lrvo-db init est idempotent. Sur une base qui possède déjà la table, il applique les migrations de schéma en attente sans toucher aux données. Voir Modèle de données.

Brancher le rendu public

Le start template officiel monte un seul catch-all qui interroge le registre de contenu public :

app/(public)/[...slug]/page.js

Ce fichier itère les résolveurs de core/public-content. Le module y enregistre le sien au boot, à la priorité 0. Il n'y a donc rien à importer : l'installation suffit.

Le catch-all ne couvre pas la racine /. L'accueil du site reste app/(public)/page.js du projet, et aucune page CMS ne peut le remplacer.

Projet sans catch-all dynamique

Si le projet n'utilise pas le registre de résolveurs, la vue publique se re-exporte directement :

// app/(public)/[...slug]/page.js
export { default, generateMetadata } from '@lrvo/module-pages/public';

Cette forme court-circuite le registre. Elle rend uniquement des pages CMS, et aucun autre module de contenu ne pourra répondre sur ces URL.

Fournir le template default

Le module n'embarque aucun template. Il résout page.template, et retombe sur l'identifiant default quand la valeur ne correspond à rien.

Le template default est fourni par le projet hôte dans components/lrvo/templates/default.js, et enregistré au boot par le manifeste que génère lrvo-modules sync. Le start template en fournit un. Sans aucun template enregistré, le module rend les blocs bruts via BlockListRenderer du core, sans mise en page.

Voir Templates pour en écrire un.

Vérifier

1. La connexion à la base répond :

   npx lrvo-db test

2. Pages apparaît dans la barre latérale de l'admin.
3. Créer une page depuis /admin/pages, la laisser en visibilité publique, puis l'ouvrir à /<slug>.

Les permissions du module sont enregistrées et attribuées au rôle admin pendant lrvo-db init. Un module ajouté après coup n'a donc besoin que d'un npx lrvo-db init pour que pages.view et pages.manage apparaissent dans /admin/roles.

Mettre à jour

npx lrvo-update

Le module déclare la version minimale de @lrvo/core dont il a besoin. Un npm i @lrvo/module-pages@latest sur un projet dont le core est trop ancien produit un ERESOLVE au message peu parlant : lrvo-update résout au contraire le core et les modules ensemble, et laisse en place tout module qu'il ne peut pas monter.

Les notes de version sont livrées avec le package, dans node_modules/@lrvo/module-pages/CHANGELOG.md.

Notes

• Le module dépend de @lrvo/core en peerDependency. Il n'embarque pas sa propre copie du core.
• Les blocs image utilisent le registre de médias du core. Si @lrvo/module-medias est installé, le sélecteur d'image et l'image de partage Open Graph deviennent disponibles dans l'éditeur.
• Désinstaller le module ne supprime pas la table. dropTables est exporté depuis @lrvo/module-pages pour le faire explicitement.