- PHP 49.7%
- Svelte 22.8%
- TypeScript 12.6%
- Python 10.7%
- JavaScript 2.1%
- Other 2%
| Filename | Latest commit message | Latest commit date |
|---|---|---|
|
All checks were successful
Intégration continue / ci (push) Successful in 2m22s
nobase/tests 1510 vérification(s) réussie(s), 0 échec(s) ; NON EXÉCUTÉ : webauthn : navigateur headless inutilisable pour WebAuthn sur cet hôte : ERREUR (environnement de test) : bibliothèques système manquantes pour chrome-headless-s | mobile : navigateur headle
Publication d'une version / release (push) Successful in 2m20s
L'alerte comptait les jours depuis la dernière sauvegarde réussie : un site resté inchangé (sauvegardes sautées, only_if_changed) puis modifié alertait juste avant la sauvegarde de rattrapage. Le délai part désormais de la première modification non sauvegardée (data/backups/.dirty) ; update-history.json et theme-updates.json (tenue de registre du CMS) ne comptent plus comme des modifications. Test : étape access. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> |
||
| .forgejo/workflows | ||
| admin-src | ||
| docker | ||
| docs | ||
| tools | ||
| www | ||
| .env.example | ||
| .gitignore | ||
| CHANGELOG.md | ||
| docker-compose.yml | ||
| LICENSE | ||
| Makefile | ||
| README.md | ||
| VERSION | ||
NoBaSe — CMS PHP à fichiers plats
NoBaSe (No · Ba · Se : nobélium, baryum, sélénium — « no base », pas de base de données)
est un CMS écrit en PHP, sans base de données, conçu pour un hébergement mutualisé
(Apache + .htaccess, PHP ≥ 8.1, aucun processus permanent) et qui fonctionne aussi dans
Docker derrière un reverse proxy. Son back-office est une application Svelte 5 / TypeScript.
Le cœur (www/app/) ne contient rien de propre à un site : l'apparence vient d'un
thème (www/themes/), et ce qui est propre à une installation (nom, langues, modèle de
contenu, scripts) d'un profil du site (www/site/). Chaque site garde son profil et son
thème à part et reçoit le cœur par des mises à jour signées.
Fonctionnalités
- Fichiers plats : chaque contenu, média, compte, redirection est un fichier JSON, écrit
de façon atomique avec verrous ; un seul dossier à sauvegarder,
www/data/. - Installation guidée
/installprotégée par un jeton à usage unique : nouveau site vierge ou restauration d'une sauvegarde ; ou sans navigateur (variables d'environnement, ligne de commande). - Back-office multi-utilisateurs : rôles cumulables (administrateur, éditeur, rédacteur…), révisions, détection des modifications concurrentes, interface en français et en anglais, installable (PWA).
- Modèle de contenu en données : types et champs définis dans le back-office (texte riche, images, galeries, fichiers, références, liens, FAQ, coordonnées…), adresses configurables, contenus multilingues reliés entre eux.
- Thèmes avec héritage parent → enfant, aperçu avant activation, réglages personnalisables, import d'archive avec analyse du code ; thème de base Vierge qui affiche tout type de contenu.
- Langues, menus, SEO : préfixes d'adresse par langue,
hreflang, menus multilingues, balises SEO et JSON-LD, plan du site, redirections 301, anciennes adresses WordPress reconnues. - Images : optimisation à l'envoi (métadonnées et position GPS retirées, redimensionnement),
miniatures WebP/AVIF servies par
<picture>. - Calendriers de disponibilité au demi-jour (statuts propres au site, publics ou privés), affichés dans une page par un champ « Calendrier », accessibles sans JavaScript.
- Sécurité au centre : pare-feu applicatif et blocage par IP, double authentification, verrouillage des comptes, mots de passe compromis refusés, scanner d'intégrité et de logiciels malveillants, journal d'audit, alertes e-mail et notifications push, CSP stricte.
- Sauvegardes complètes ou partielles construites par tranches, téléchargement protégé, restauration vérifiée avant toute modification.
- Tout se règle dans le back-office, y compris les réglages du serveur (adresse publique, hôtes autorisés, HTTPS, reverse proxy, sessions, canal de mise à jour…) : page Réglages système, protégée par la double authentification et une confirmation d'identité ; aucun fichier de configuration à écrire.
- Mises à jour signées sans FTP (Ed25519, repli ECDSA P-256) : téléversement ou canal HTTPS, vérification complète, sauvegarde, bascule, migrations, contrôle de santé et retour automatique.
- Statistiques d'audience intégrées, sans cookie, et Google Analytics facultatif avec bannière de consentement ; site privé pour une préproduction ; cache de pages.
Démarrage rapide (Docker)
Prérequis : Docker avec Docker Compose, Node.js LTS maintenu (22, 24 ou 26 ; la forge utilise 26) et npm ≥ 10 (le paquet npm 9 de Debian ne convient pas), Python 3.
git clone https://forge.lequen.fr/jlequen/NoBaSe.git && cd NoBaSe
make admin # compile le back-office (admin-src/ → www/admin/)
make up # conteneur Apache + PHP 8.5 : http://localhost:8080/
make token # affiche un jeton d'installation
Ouvrez http://localhost:8080/install, saisissez le jeton, puis choisissez « Nouveau site » : nom, langues, adresse publique et hôtes autorisés, premier administrateur. Le back-office est ensuite sur http://localhost:8080/admin/ ; les réglages du serveur s'y font dans Réglages système (aucun fichier de configuration).
Variante sans navigateur : copiez .env.example en .env et renseignez CMS_ADMIN_EMAIL et
CMS_ADMIN_PASSWORD (12 caractères au moins) avant make up ; CMS_PORT change le port.
Installer sur un hébergement
make dist # dist/nobase-<VERSION>.zip : paquet générique, sans aucune donnée, vérifié
Déposez le contenu de www/ du paquet à la racine du site (FTP/SFTP, fichiers cachés compris),
ouvrez https://votre-domaine/install et saisissez le jeton indiqué dans INSTALLATION.txt.
Détails (OVH mutualisé, VPS, reverse proxy, HTTPS, vérifications) :
docs/installation.md.
Arborescence
NoBaSe/
├── www/ ← ce qui est déposé sur l'hébergement
│ ├── index.php contrôleur frontal (API, site public, miniatures)
│ ├── .htaccess réécritures, en-têtes, protection de app/, data/, site/ et du code des thèmes
│ ├── app/ cœur (interdit au web) : lib/, api/, cli/, lang/, migrations/, update-keys.json
│ ├── assets/ scripts publics du cœur (statistiques, consentement, installation)
│ ├── site/ profil du site — neutre ici (config.php)
│ ├── themes/vierge/ thème de base
│ ├── admin/ back-office compilé (make admin, non versionné)
│ └── data/ données du site (créé au premier lancement, non versionné)
├── admin-src/ sources du back-office (Svelte 5, TypeScript, Vite)
├── docs/ documentation
├── tools/ paquet (dist.py), versions signées (release.py), publication du canal
│ (publish.py), auto-test du scanner, audit de thème
├── docker/, docker-compose.yml environnement de test
└── Makefile, VERSION, LICENSE
Commandes utiles
| Commande | Effet |
|---|---|
make admin, make check |
compiler le back-office ; vérifier ses types |
make up, make logs, make token |
environnement de test Docker |
make scan-selftest |
le code livré ne déclenche aucune signature du scanner |
make check-clean |
le dépôt ne contient ni nom de site client, ni secret, ni donnée, ni fichier > 1 Mo |
make dist, make dist-src |
paquet d'installation sans données (avec les sources du back-office) |
make keygen |
clé de signature des versions (privée hors dépôt) |
make release, make release-index |
paquet de mise à jour signé et index du canal ; re-signature de l'index |
make publish, make publish-index |
publication du canal dans la branche updates de la forge |
make ci-keys, make ci-secret |
clé CI + clé de secours pour la publication automatique ; valeur du secret de la forge |
make fetch-updates, make dist-public |
récupérer le canal publié ; paquet d'installation public sans jeton |
Publier une version
Automatique, par la forge (docs/publication-automatique.md) :
# VERSION = X.Y.Z et section « ## [X.Y.Z] — date » en haut de CHANGELOG.md
git commit -am "Version X.Y.Z" && git push origin main # intégration continue, sans secret
git tag vX.Y.Z && git push origin vX.Y.Z # construit, vérifie, signe, publie
La forge (Forgejo Actions, runner YunoHost en mode host) vérifie que l'étiquette correspond à
VERSION, compile, contrôle (php -l, scanner, dépôt), produit le paquet d'installation public
et le paquet de mise à jour signé, les vérifie, puis publie la release et le canal
updates ; l'index est re-signé tous les 10 jours. Mise en place une fois : make ci-keys sur
votre poste (clé CI pour le secret de la forge + clé de secours hors ligne), secrets
NOBASE_SIGNING_KEY et FORGEJO_RELEASE_TOKEN, protection des étiquettes v* et de la branche
updates. Secours : make dist, make release, make publish restent utilisables à la main.
Mises à jour
Les sites reçoivent les nouvelles versions par le canal officiel, publié dans la branche
updates de ce dépôt ; son adresse se règle dans back-office → Réglages système → Mises à jour
(canal et mode de mise à jour) :
https://forge.lequen.fr/jlequen/NoBaSe/raw/branch/updates/latest.json
Voir docs/mises-a-jour.md (administrateur du site et mainteneur).
Documentation
Sommaire complet : docs/index.md.
- Exploitation : installation, configuration, reverse proxy, sauvegarde et restauration, mises à jour, publication automatique, sécurité, notifications, rôles et droits, performances et cache, images, site privé, statistiques, dépannage
- Développement : thèmes et leurs mises à jour (et www/themes/vierge/README.md), types de contenu, langues, menus, API de publication (jetons), migrer depuis un autre CMS
- Utilisateurs : guide du back-office
Licence
Copyright (C) 2026 Julien Lequen.
NoBaSe est un logiciel libre distribué sous la licence GNU Affero General Public License
version 3 (SPDX : AGPL-3.0-only) : voir LICENSE. En particulier, si vous
modifiez NoBaSe et le faites fonctionner sur un serveur accessible à d'autres personnes, vous
devez leur donner accès au code source de votre version modifiée.
Les dépendances tierces du back-office (admin-src/package.json) restent soumises à leurs
propres licences.