Conceptos Fundamentales
La arquitectura y el modelo de contenido debajo de Chinaski: el modelo mental que vale cuarenta minutos antes de construir algo sustancial. Todo en esta sección refleja cómo se comporta realmente el sistema; la sección de Autoría cubre el trabajo diario de clics.
En esta sección
- Arquitectura: el diseño de dos programas: un CMS en Perl que posee la capa de administración, un proceso builder separado que produce el sitio público, y un servidor web que sirve archivos planos.
- El Pipeline de Build: lo que ocurre en cada build: staging, verificaciones, firma, promoción, y por qué un build aterriza por completo o no aterriza.
- Modelo de Contenido: páginas, posts, bloques, snippets, categorías, medios, documentos: qué es cada tipo y las propiedades que comparten (idioma, papelera, revisiones, auditorías).
- Estructura de Salida: cómo se ve el sitio compilado en el disco: árboles por idioma, archivos index, los archivos de redirección, sitemaps y feeds.
- La Base de Datos: un archivo SQLite como única fuente de verdad; por qué una base de datos embebida es la decisión correcta aquí y qué significa operativamente.
- Instancias: ejecutar varios sitios Chinaski independientes en un servidor, y las convenciones de nombres/rutas que lo hacen seguro.
- Tareas en Segundo Plano: la cola de trabajo asíncrona detrás de las tareas de administración de larga duración.
- Papelera: el modelo de borrado suave: qué se mueve a la papelera, cuánto tiempo permanece allí y cómo restaurarlo.
- Búsqueda del Sitio: cómo se genera y se consulta el índice de búsqueda integrado.
Las ideas que vale interiorizar
- El sitio es la salida del build. El sitio que ve el navegador son archivos estáticos; cualquier edición es invisible hasta que corre un build, y un build o se completa (y promociona atómicamente) o preserva lo que ya estaba live.
- Una base de datos, árboles por idioma. Todo el estado vive en
chinaski.db; la salida es una función pura de esa base de datos más tus themes y ajustes, y eso es lo que hace que los respaldos sean tan simples y los rebuilds tan seguros. - El servidor web y el CMS solo se encuentran de forma deliberada. Las solicitudes estáticas nunca tocan la aplicación; solo los formularios, las descargas de documentos y el admin la tocan.
- El aislamiento de instancias permite a una máquina muchos sitios no relacionados con bases de datos, usuarios y programaciones separados.
También en Conceptos Fundamentales
Chinaski se divide deliberadamente en unas pocas piezas pequeñas en movimiento en lugar de un gran servidor siempre encendido. Esta página explica las cuatro.
Cuando presionas Build, un proceso en segundo plano convierte la base de datos en el sitio estático y, solo cuando todo tiene éxito, intercambia los archivos.
Todo en un site de Chinaski es uno de un conjunto pequeño de tipos de contenido. Cada tipo tiene su propio comportamiento, sus propias pantallas de administr.
Cada build produce un árbol de directorios plano de archivos. Esta página mapea qué vive dónde, para que sepas exactamente qué pasa a live.
Chinaski guarda todo en un solo archivo SQLite por instancia, sin servidor de base de datos, sin credenciales, sin protocolo de red, y mantiene su esquema .
Una instancia de Chinaski es un sitio completo: su propio proceso de aplicación, su propia base de datos, sus propios archivos, su propio conjunto de respald.
Para lotes de contenido muy grandes o cientos de páginas, posts o inserciones de bloques. La API de creación síncrona no es la herramienta adecuada. Chinask.
Cada eliminación en Chinaski aterriza primero en la Papelera. Una página, post, bloque o formulario eliminado, o cualquier otra cosa cubierta por la papeler.
Los sites built incluyen una página de búsqueda funcional en /search/. Generada por idioma en build time, respaldada por un índice JSON estático, y buscada .