Limitaciones de la versión 1

Esta página existe para que decidas antes de construir sobre Kevin CMS, no después. Son seis, y cada una está comprobada contra el código, no contra una hoja de ruta.

Si alguna de ellas es un requisito de tu proyecto, la versión 1 no te sirve. Es mejor saberlo ahora.

1. No hay control de acceso por roles

Y hay una consecuencia menos evidente: la API local no comprueba access en absoluto. Astro.locals.cms lee y escribe siempre. Ese control vive solo en la capa REST, así que una página tuya que exponga una escritura tiene que poner su propia guarda.

2. No hay borradores ni versiones

Guardar publica. No hay copia de trabajo, ni historial, ni «volver a la versión de ayer»: lo que escribes en el editor es lo que hay en la base en cuanto pulsas guardar, y lo anterior no se guarda en ninguna parte.

Lo que sí puedes hacer es un campo select con draft y published y filtrar por él en tus consultas, que es lo que hace Tu primera colección. Es un estado que tú controlas, no un sistema de borradores: el documento es uno solo, y editarlo cambia lo que ve todo el mundo. Ver El editor.

3. No hay localización

Un documento tiene un idioma: el que escribiste. No hay campos por idioma, ni versiones traducidas de un mismo documento, ni rutas por locale.

El ajuste locale de los ajustes del sitio existe, se guarda y se sirve, pero hoy no hace nada. El panel está en español y tampoco se traduce. Ver Lo que todavía no hay.

4. No hay rich text

No existe un tipo de campo de texto enriquecido. Los tipos son nueve —text, textarea, number, checkbox, date, select, json, relationship y upload— y el texto largo se escribe como Markdown dentro de un textarea, que tu plantilla convierte a HTML al pintarlo.

Eso significa que quien escribe teclea Markdown a pelo: no hay barra de herramientas, ni negrita con ⌘B, ni previsualización. Si tu redacción no va a aceptar eso, es un problema real y no un detalle. Ver Fuera de la versión 1.

5. No hay campos `array` ni `blocks`

No se puede declarar una lista repetible de subcampos, ni un constructor de bloques por página. Para estructuras a medida está json: entra cualquier cosa serializable y vuelve tal cual, anidamiento incluido.

El precio es que json se tipa como unknown, así que lo estrechas tú, y que el panel lo edita como texto validado, no como un formulario con sus campos. Una lista de tres enlaces cabe perfectamente; un modelo de contenido entero, no.

6. No hay GraphQL, ni va a haberlo

La única API sobre HTTP es la API REST, con sus seis endpoints por colección. No está previsto añadir GraphQL: dentro de una plantilla de Astro la API local ya llega tipada desde el codegen y sin salto de red, que es la mitad del problema que GraphQL resuelve.

Tampoco hay transformaciones de imagen. Los ficheros salen de R2 tal y como entraron; para redimensionar y recortar está Cloudflare Images.

Dónde está el detalle

Cada una de estas páginas mantiene su propia tabla de lo que le falta, y esa es la que manda:

El administrador — proveedores sociales, invitar a un segundo usuario, pantalla de cuenta, barra de progreso al subir.
Autenticación — pantallas de verificación y restablecimiento, invitaciones por correo, Google y GitHub.
Ajustes — credenciales de OAuth, y más campos que los seis que hay.
Ficheros — lo que no cubre la subida a R2.