Hecho con Chinaski

Referencia de Schema

Todo lo que creas en Chinaski, páginas, posts, imágenes, forms, usuarios, settings, se almacena en un único archivo de base de datos junto a tu site. Esta página explica qué contiene la base de datos y algunos de sus comportamientos que conviene conocer como administrador.

Cómo funciona la base de datos

  • La base de datos es un único archivo SQLite. Todos los datos viven en ese archivo, y los backups (manuales o programados) lo capturan desde allí.
  • Las relaciones de contenido permitidas se aplican por la propia base de datos: borrar una página, post, form o stack también elimina los registros que cuelgan de él, como sus form submissions, blocks y edits de draft.
  • Borrar la mayoría del contenido es un soft delete. Las páginas, posts, blocks, snippets, media, categorías, forms, documentos y stacks borrados se marcan, no se borran, así que la recuperación y el historial siguen siendo posibles. Desaparecen de las listas y del site publicado de inmediato. La limpieza dura sucede automáticamente durante la operación normal.
  • La base de datos empieza con defaults sensatos ya en su lugar: un site en inglés, el theme default integrado (The Letterbox), y una primera cuenta "admin" cuya contraseña es inutilizable hasta que completas el setup de primera ejecución.
  • Las settings se almacenan como pares simples nombre/valor, así que las opciones del site que ves en Settings se registran individualmente. Cada vez que se guardan las settings, se almacena un snapshot de todos los valores, dando un historial de cambios de configuración.

Contenido que autoras

  • Páginas y posts almacenan cada uno su propio título, body y slug. Cada versión de idioma de una página o post es su propio registro independiente, un slug puede existir en un idioma, en varios, o en todos, y nada obliga a que exista cada idioma.
  • Páginas y posts cargan los campos que ves en el editor: títulos y descripciones SEO, campos de social share, featured image (con punto focal), ajustes de publish/schedule, estado de review, controles de sitemap y una contraseña opcional para páginas gated.
  • Las páginas pueden contener datos estructurados para listados de producto y evento (nombre, precio, disponibilidad, fechas, venue); los posts comparten el tipo de datos estructurados pero no esos conjuntos de campos.
  • Blocks son componentes reutilizables, únicos por nombre e idioma, con su propio texto, botones, colores y estilo. Se adjuntan a páginas y posts, con overrides opcionales por placement.
  • Stacks son colecciones ordenadas y con nombre de blocks. Un stack puede asignarse a páginas o posts, puede apilarse dentro de otro stack, puede tener overrides por idioma y puede heredar de otro stack. El área de admin también usa unas pocas tablas compañeras internas para mostrar dónde se usa un block, traducir contenido de stacks y reportar la salud de build y el rendimiento de cada stack.
  • Categorías se gestionan por idioma; un post guardado con un valor de categoría se añade a la lista de categorías gestionadas automáticamente.
  • FAQ items y HowTo steps te permiten adjuntar listas estructuradas de Q&A y pasos a páginas o posts para resultados de búsqueda más ricos.
  • Authors te permiten mantener bylines: perfiles con bio, avatar y links sociales, asignados a cualquier número de posts o páginas.
  • Custom fields contienen datos extra clave/valor en cualquier página o post, con tipos para texto, números, booleanos, fechas y JSON.
  • Drafts auto-guardan tus edits en progreso en el servidor, así que una sesión larga de edición sobrevive al cierre del navegador. Un draft por usuario por ítem.
  • Revisions son snapshots de cada página, post, block, snippet, documento, imagen, stack y form tomados justo antes de cada guardado, esto es lo que alimenta el version history y el rollback.
  • Internal notes pueden dejarse en un post sin que sean visibles a los lectores.

Media y documentos

  • Media es la biblioteca de archivos: las imágenes guardan dimensiones más texto alt, caption y credit; los uploads registran quién los subió y en qué carpeta viven. Los archivos idénticos no pueden subirse dos veces, y los tamaños de imagen generados se rastrean por archivo.
  • Documents gestionan PDFs con sus propias URLs, carpetas, tags y programación de publish/unpublish.
  • Los documentos soportan versiones con un estado de approval: los drafts avanzan por under review, approved, rejected o published.
  • Los documentos privados pueden compartirse por links especiales con expiración opcional y un límite de descargas; todas las descargas se loguean con hora, IP y navegador.

Usuarios, login y seguridad

  • Users son cuentas de admin o editor. Una cuenta puede suspenderse, tiene un idioma y theme de admin preferidos, y puede restringirse a ciertas entidades e idiomas.
  • Las sesiones de login se rastrean, así que las páginas de cuenta pueden mostrar dispositivos activos y los administradores pueden desloguear a un usuario en todas partes.
  • Se conserva un registro de cada intento de login, éxito, fallo o bloqueado.
  • Los links de reset de contraseña se almacenan sin exponer el token mismo y dejan de funcionar una vez usados o expirados.
  • Tres pequeños registros de rate limiting rastrean los intentos de login fallidos repetidos, los intentos de registro y las peticiones de forgot-password por dirección IP, esto es lo que alimenta las esperas de bloqueo descritas en la página de Passwords.
  • API keys (almacenadas con hash, nunca en texto plano) autentican la API REST pública, cada una con sus propios permisos y expiración opcional.
  • Audit y event logs registran cada cambio de contenido (quién hizo qué a qué ítem) y los eventos de sistema a niveles info/warn/error, así que queda una huella duradera de qué pasó y cuándo.

Forms y submissions

  • Forms definen tus formularios de contacto: campos, comportamiento de página de éxito, correos de notificación, protección anti-spam y webhooks opcionales.
  • Form fields controlan cada input: tipo, flag requerido, placeholder, opciones, visualización condicional y límites de validación.
  • Submissions almacenan los datos introducidos, la IP del visitante (a menos que la hayas deshabilitado), un receipt token mostrado al remitente y, donde fue suministrada por el visitante con su consentimiento, atribución de marketing como el referrer de la landing page, parámetros UTM y IDs de clic de anuncios comunes. Marcar una submission como leída se estampa en el registro.
  • Las respuestas de submission también se normalizan en una fila por campo, así que los resultados del form pueden filtrarse y ordenarse por cualquier campo individual.

Configuración y estructura del site

  • Navegación es una lista por idioma de links de header, soportando links externos y submenús anidados.
  • Redirects se crean automáticamente cuando renombras el slug de una página o post publicado, manteniendo las URLs viejas funcionando; cada registro cuenta los hits que ha recibido.
  • Themes se registran con el site; el cambio de themes recuerda cuál estaba activo.
  • Design tokens contienen los valores de color/estilo que se convierten en CSS custom properties al momento del build.
  • Design briefs almacenan documentos de referencia usados al generar themes.

Builds y trabajo en segundo plano

  • Build log registra cada build del site estático: cuándo, resultado, archivos escritos, output capturado, resultados de validación y timings.
  • Build progress es una única fila de estado vivo actualizada mientras corre un build, esto alimenta el indicador de progreso de build.
  • Background jobs rastrean las operaciones más largas (como importaciones) con contadores de progreso y resultados.

Webhooks

  • Post webhooks son endpoints salientes que defines los cuales se notifican cuando un post se publica, actualiza o borra.
  • Delivery log registra cada intento de webhook: payload, destino, respuesta y estado de reintento.
  • Circuit breakers detienen las entregas a endpoints que fallan repetidamente, pausándolos un rato en lugar de golpear a un destino roto.

Monitoreo

  • 404 log agrega los reportes de páginas faltantes desde el host estático o el procesador de logs, contando con qué frecuencia se pidió cada path y cuándo se vio por última vez.
  • Backup runs registran cada intento de backup: si fue manual, programado, hecho desde una API o empujado; el archivo y tamaño resultantes; y si la verificación automática de restore-verification pasó.
Lee este sitio en