Le tour du propriétaire
Créer le premier compte, parcourir les écrans fournis et mettre une première page en ligne, sans écrire de code.
Le projet tourne, la base est initialisée. Avant de lire une ligne de configuration, autant voir ce qui est déjà là. Cette page ne fait écrire aucun code : elle crée un compte, fait le tour des écrans fournis et met une page en ligne.
1. Le premier compte
Ouvrir http://localhost:3000/auth.
La base est vide, donc la page affiche le formulaire Première configuration : nom, courriel, mot de passe. Le mot de passe fait de 8 à 128 caractères, avec au moins une majuscule, une minuscule et un chiffre.
Le compte créé reçoit le rôle admin. Son courriel est marqué vérifié sans qu'aucun message parte, ce qui tombe bien : aucun fournisseur de courriel n'est configuré à ce stade. La session s'ouvre et le navigateur arrive directement sur l'administration.
Ce formulaire ne revient plus une fois le compte créé. Sept pages prennent alors le relais, sur /auth/login, /auth/register, /auth/forgot, /auth/reset, /auth/confirm, /auth/setup et /auth/logout. Le projet ne les déclare pas une par une : une seule route les sert toutes. Les comptes créés ensuite par /auth/register doivent vérifier leur courriel avant de se connecter.
2. L'administration
L'administration est à http://localhost:3000/admin.
C'est l'état réel d'une installation neuve. La barre latérale est courte : le tableau de bord, et la section des utilisateurs qui mène aux comptes et aux rôles. Tout ce qui s'y ajoutera viendra des modules et des extensions.
| Écran | Ce qu'il fait |
|---|---|
/admin/dashboard | Le tableau de bord et ses widgets. Il est presque vide au départ, chaque module et chaque extension y ajoute les siens. Les tuiles de santé et de version du core n'apparaissent qu'en cas d'anomalie ou de mise à jour en attente. |
/admin/users | La liste des comptes, la création et l'invitation par courriel. |
/admin/roles | Les rôles et les permissions qu'ils accordent. Les modules y ajoutent les leurs à l'installation. |
/admin/profile | Le profil du compte courant, sa photo, sa sécurité, ses sessions actives et son apparence. Il s'ouvre depuis le menu du compte, en haut à droite. |
Les rôles ne partent pas de zéro :
admin porte toutes les permissions du core et c'est celui qu'a reçu le premier compte créé. user n'en porte aucune. Les deux sont marqués système, ils ne se suppriment pas. Chaque module installé ajoutera ses propres permissions à cette liste, et c'est là qu'on les accorde.
L'écran se lit en trois zones : une barre latérale à gauche avec le logo et la navigation, une barre supérieure avec le fil d'Ariane et le compte, et le contenu au centre.
Le point à retenir pour la suite : cette navigation n'est écrite nulle part. Elle est calculée à partir d'un registre que les modules et le projet alimentent au démarrage. Le fil d'Ariane vient du même endroit. Ajouter une entrée suffit donc à la faire apparaître aux deux endroits.
3. Le site public
http://localhost:3000 affiche la page d'accueil du gabarit, app/(public)/page.js. Elle vous appartient : aucun module ne la remplace, et c'est voulu.
Le reste du domaine, en revanche, est ouvert. Une route attrape toutes les autres URL et demande aux modules de contenu si l'un d'eux sait répondre. Pour l'instant aucun n'est installé, donc tout répond 404.
4. Une première page en ligne
Le module Pages sert du contenu éditable à la racine du domaine. Son installation ne demande aucun code, parce que le gabarit fournit déjà la route et le template.
npm i @lrvo/module-pagesAjouter le drapeau d'activation au .env :
LRVO_MODULE_PAGES=trueSans ce drapeau, le module est ignoré : aucune table, aucune route, aucune entrée d'admin. Créer sa table, puis redémarrer :
npx lrvo-db init
npm run devlrvo-db init est idempotent : il crée ce qui manque et laisse le reste intact. La régénération des manifestes, elle, est déjà faite, puisque le script dev est préfixé par lrvo-modules sync.
Une section Pages apparaît dans la barre latérale. Ouvrir /admin/pages, créer une page, lui donner un titre et un slug, ajouter quelques blocs, la passer en visible, enregistrer. L'URL publique complète est affichée sous le champ slug, et le bouton de lien de la liste l'ouvre dans un nouvel onglet.
La page est en ligne. Le détail de l'écran est dans Administration du module Pages, et les variantes d'installation dans Installation.
Ce qui vient de se passer
Trois commandes et une variable d'environnement ont ajouté une table, des permissions, une section d'admin et une famille d'URL publiques. Aucun fichier du projet n'a été modifié.
C'est le mécanisme central de la plateforme : le module a été découvert par scan des dépendances, puis s'est déclaré au démarrage dans les registres que le core relit à chaque rendu. Comment ça fonctionne en donne le déroulé complet.
Étape suivante
Configuration reprend le .env par groupes et explique ce que chaque service active.