Référence du schéma

Tout ce que vous créez dans Chinaski (pages, posts, images, formulaires, utilisateurs, réglages) est stocké dans un unique fichier de base de données à côté de votre site. Cette page explique ce que contient la base de données et quelques-uns de ses comportements dignes d'être connus en tant qu'administrateur.

Comment fonctionne la base de données

• La base de données est un unique fichier SQLite. Toutes les données vivent dans ce seul fichier, et les backups (manuels ou planifiés) le capturent depuis là.
• Les relations de contenu permises sont imposées par la base de données elle-même : supprimer une page, un post, un formulaire ou un stack retire aussi les enregistrements qui y pendouillent, comme ses submissions de formulaire, ses blocks et ses éditions en brouillon.
• Supprimer la plupart des contenus est un soft delete. Les pages, posts, blocks, snippets, media, catégories, formulaires, documents et stacks supprimés sont marqués, pas effacés, de sorte que la recovery et l'historique restent possibles. Ils disparaissent des listes et du site publié immédiatement. Le nettoyage dur se produit automatiquement pendant le fonctionnement normal.
• La base de données démarre avec des défauts sensés déjà en place : un site en langue anglaise, le thème par défaut intégré (The Letterbox), et un premier compte « admin » dont le mot de passe est inutilisable tant que vous n'avez pas terminé la configuration du premier démarrage.
• Les réglages sont stockés comme de simples paires nom/valeur, si bien que les options du site que vous voyez dans Settings sont enregistrées individuellement. À chaque sauvegarde des réglages, un snapshot de toutes les valeurs est stocké, donnant un historique des changements de configuration.

Le contenu que vous rédigez

• Les pages et les posts stockent chacun leur propre titre, body et slug. Chaque version linguistique d'une page ou d'un post est son propre enregistrement indépendant ; un slug peut exister dans une langue, plusieurs ou toutes, et rien n'oblige chaque langue à exister.
• Les pages et les posts portent les champs que vous voyez dans l'éditeur : titres et descriptions SEO, champs de partage social, image mise en avant (avec point focal), réglages de publication/planification, statut de review, contrôles de sitemap, et un mot de passe optionnel pour les pages protégées.
• Les pages peuvent détenir des données structurées pour les listes de produits et d'événements (nom, prix, disponibilité, dates, lieu) ; les posts partagent le type de données structurées mais pas ces jeux de champs.
• Les blocks sont des composants réutilisables, uniques par nom et langue, détenant leur propre texte, leurs boutons, leurs couleurs et leur style. Ils sont attachés aux pages et aux posts, avec des overrides optionnels par emplacement.
• Les stacks sont des collections nommées et ordonnées de blocks. Un stack peut être assigné à des pages ou des posts, peut s'empiler dans un autre stack, peut avoir des overrides par langue, et peut hériter d'un autre stack. La zone admin utilise aussi quelques tables compagnons internes pour montrer où un block est utilisé, traduire le contenu des stacks, et rapporter la santé de build et les performances de chaque stack.
• Les catégories sont gérées par langue ; un post sauvegardé avec une valeur de catégorie est ajouté automatiquement à la liste des catégories gérées.
• Les items FAQ et les étapes HowTo vous permettent d'attacher des Q&R structurées et des listes d'étapes aux pages ou aux posts pour des résultats de recherche plus riches.
• Les auteurs vous permettent de maintenir des signatures : des profils avec bio, avatar et liens sociaux, assignés à un nombre quelconque de posts ou de pages.
• Les custom fields détiennent des données clé/valeur supplémentaires sur toute page ou post, avec des types pour texte, nombres, booléens, dates et JSON.
• Les brouillons sauvegardent automatiquement vos éditions en cours sur le serveur, si bien qu'une longue session d'édition survit à la fermeture du navigateur. Un brouillon par utilisateur par élément.
• Les révisions sont des snapshots de chaque page, post, block, snippet, document, image, stack et formulaire pris juste avant chaque sauvegarde : c'est ce qui alimente l'historique des versions et le rollback.
• Les notes internes peuvent être laissées sur un post sans être visibles des lecteurs.

Media et documents

• Le media est la bibliothèque de fichiers : les images détiennent des dimensions plus le texte alt, la légende et le crédit ; les téléversements enregistrent qui les a téléversés et dans quel dossier ils vivent. Les fichiers identiques ne peuvent pas être téléversés deux fois, et les tailles d'images générées sont suivies par fichier.
• Les documents gèrent des PDF avec leurs propres URL, dossiers, tags et planification de publication/dépublication.
• Les documents supportent des versions avec un statut d'approbation : les brouillons traversent under review, approved, rejected ou published.
• Les documents privés peuvent être partagés via des liens spéciaux avec expiration optionnelle et limite de téléchargement ; tous les téléchargements sont journalisés avec l'heure, l'IP et le navigateur.

Utilisateurs, connexion et sécurité

• Les utilisateurs sont des comptes admin ou editor. Un compte peut être suspendu, a une langue et un thème admin préférés, et peut être restreint à certaines entités et langues.
• Les sessions de connexion sont suivies, de sorte que les pages de compte peuvent montrer les appareils actifs et les administrateurs peuvent déconnecter un utilisateur partout.
• Un enregistrement est conservé de chaque tentative de connexion : succès, échec ou blocage.
• Les liens de réinitialisation de mot de passe sont stockés sans exposer le token lui-même et cessent de fonctionner une fois utilisés ou expirés.
• Trois petits enregistrements de rate limiting suivent les tentatives de connexion échouées répétées, les tentatives d'inscription et les demandes de mot de passe oublié par adresse IP. C'est ce qui alimente les délais de lockout décrits sur la page Passwords.
• Les clés API (stockées hachées, jamais en clair) authentifient l'API REST publique, chacune avec ses propres permissions et expiration optionnelle.
• Les journaux d'audit et d'événements enregistrent chaque changement de contenu (qui a fait quoi à quel élément) et les événements système aux niveaux info/warn/error, si bien qu'il existe une piste durable de ce qui s'est passé et quand.

Formulaires et submissions

• Les formulaires définissent vos formulaires de contact : champs, comportement de page de succès, emails de notification, protection anti-spam et webhooks optionnels.
• Les champs de formulaire contrôlent chaque entrée : type, flag requis, placeholder, options, affichage conditionnel et limites de validation.
• Les submissions stockent les données saisies, l'IP du visiteur (sauf si vous l'avez désactivé), un token de reçu montré au soumetteur, et, là où il a été fourni par le visiteur avec son consentement, l'attribution marketing telle que le référent de landing-page, les paramètres UTM et les identifiants de clic publicitaires courants. Marquer une submission comme lue est estampillé sur l'enregistrement.
• Les réponses des submissions sont aussi normalisées en une ligne par champ, de sorte que les résultats des formulaires peuvent être filtrés et triés par n'importe quel champ unique.

Configuration et structure du site

• La navigation est une liste par langue de liens d'en-tête, supportant les liens externes et les sous-menus imbriqués.
• Les redirections sont créées automatiquement quand vous renommez le slug d'une page ou d'un post publié, gardant les anciennes URL fonctionnelles ; chaque enregistrement compte les visites reçues.
• Les thèmes sont enregistrés auprès du site ; changer de thème se souvient duquel était actif.
• Les design tokens détiennent les valeurs de couleur/style qui sont transformées en custom properties CSS au moment du build.
• Les design briefs stockent des documents de référence utilisés lors de la génération des thèmes.

Builds et travail d'arrière-plan

• Le journal de build enregistre chaque build du site statique : quand, issue, fichiers écrits, sortie capturée, résultats de validation et durées.
• La progression de build est une unique ligne de statut en direct mise à jour pendant qu'un build tourne ; c'est elle qui alimente l'indicateur de progression de build.
• Les jobs d'arrière-plan suivent les opérations longues (comme les imports) avec des compteurs de progression et des résultats.

Webhooks

• Les webhooks de post sont des endpoints sortants que vous définissez et qui sont notifiés quand un post est publié, mis à jour ou supprimé.
• Le journal de livraison enregistre chaque tentative de webhook : payload, cible, réponse et état des retries.
• Les circuit breakers arrêtent les livraisons vers les endpoints qui échouent répétitivement, les mettant en pause un moment au lieu de marteler une destination cassée.

Monitoring

• Le journal 404 agrège les rapports de pages manquantes de l'hôte statique ou du processeur de logs, comptant combien de fois chaque chemin a été demandé et quand il a été vu pour la dernière fois.
• Les exécutions de backup enregistrent chaque tentative de backup : s'il était manual, scheduled, fait depuis une API ou poussé ; le fichier résultant et sa taille ; et si le contrôle automatique de vérification de restore a passé.