Pages
Pages CMS hiérarchiques rendues à la racine du site, éditées au BlockEditor et rendues par des templates fournis par le projet.
@lrvo/module-pages ajoute une section « Pages » à l'admin et rend chaque page publiée à la racine du site, à l'URL construite depuis sa chaîne de parents. Le contenu est édité au BlockEditor du core et rendu par un template fourni par le projet hôte.
Le module est indépendant de @lrvo/module-posts. Les deux peuvent cohabiter : pages sert de repli sur toute URL non réclamée, posts réserve son préfixe.
La liste range chaque page sous son parent, décalée d'un cran par niveau, et affiche sous le titre le chemin public reconstruit depuis la chaîne des parents. La colonne SEO n'apparaît que si LRVO_SEO est actif. Le détail de l'écran est dans Administration.
Pages de cette section
| Page | Contenu |
|---|---|
| Installation | Installer le module, créer la table, brancher le rendu public. |
| Configuration | Variables d'environnement, permissions, entrée d'admin. |
| Administration | Liste arborescente, formulaire, parent, dates et enregistrement. |
| Modèle de données | Table lrvo_pages_page, hiérarchie, règles de slug et de visibilité. |
| Templates | Écrire un template de page et les propriétés qu'il reçoit. |
| API | Routes HTTP et fonctions serveur importables. |
Ce que le module apporte
| Élément | Détail |
|---|---|
| Table | lrvo_pages_page, une seule, préfixée au module. |
| Entrée d'admin | Section et item « Pages », icône File02Icon, ordre 60. |
| Permissions | pages.view et pages.manage. |
| Routes API | 7 routes d'admin, 2 routes publiques. |
| Rendu public | Un résolveur enregistré dans core/public-content à la priorité 0. |
| Templates | Templates de kind: 'page' dans core/templates. |
Positionnement dans le rendu public
Le résolveur du module est enregistré à la priorité 0, la plus basse. Il sert donc de repli : toute URL qu'aucun autre résolveur ne réclame est tentée comme page CMS. Un module qui veut réserver un préfixe, comme posts avec /<type>/<slug>, s'enregistre à une priorité plus élevée et passe avant.
Ce choix a une conséquence pratique : une page CMS ne peut jamais masquer le contenu d'un autre module, alors que l'inverse est possible.
Notes
- Une route statique du projet gagne toujours sur une page CMS de même chemin. Le catch-all Next.js n'intercepte que ce qu'aucun fichier de route ne résout. Ce n'est pas un défaut du module.
- Aucune page CMS ne peut servir la racine
/. Le résolveur renonce sur une liste de segments vide, et l'accueil du site resteapp/(public)/page.jsdu projet. - Le champ
versiondu manifeste du module vaut1.0.0et ne suit pas la version du package. Se fier àpackage.json.