Este post explica cómo hemos construido el panel de admin de este site siguiendo una dinámica muy concreta: primero planificar, después construir, comprobar, corregir y volver a iterar.

El trabajo empezó con una necesidad práctica: poder añadir y editar posts online, sin tener que tocar directamente los ficheros Markdown cada vez. El site ya estaba basado en Next.js, con contenido en ficheros `.mdx`, y el siguiente paso natural era hacer que ese contenido fuera editable desde una interfaz privada.

## La instrucción inicial

La petición era clara: añadir una página `/admin`, protegida con una contraseña definida en `.env`, con un editor Markdown con preview y capacidad de subir imágenes.

A partir de ahí, la conversación fue definiendo la arquitectura real:

- El contenido no debía vivir dentro del repo principal.
- El repo de contenido debía tener `posts/` directamente en la raíz, sin carpeta `content/`.
- Las imágenes debían ir a `images/uploads` dentro del repo de contenido.
- La configuración debía estar controlada con `BASE_CONTENT_DIR` y `CONTENT_IMAGES_DIR`.

Eso convirtió el panel de admin en una herramienta pequeña pero bastante completa: no solo una pantalla con un formulario, sino una capa de edición segura sobre un sistema de contenido basado en ficheros.

## Plan and build

El flujo fue muy de "plan and build".

Primero revisé el proyecto: los helpers de posts, las rutas existentes, el formato del frontmatter y la forma en que el site cargaba los artículos. Después propuse un plan pequeño y pragmático: mantener la arquitectura existente, añadir APIs admin protegidas y escribir en el repo externo configurado por entorno.

Cuando Francesc confirmó los detalles, pasé a construir.

La primera versión incluyó:

- Login con password hardcoded en `.env`.
- Cookie HttpOnly para mantener la sesión.
- APIs bajo `/api/admin/*`.
- Listado de posts por idioma.
- Formulario para crear y editar frontmatter.
- Editor Markdown con preview.
- Upload de imágenes hacia el repo de contenido.

Después empezó la parte más interesante: pulir la herramienta a partir del uso real.

## Iteraciones sobre el editor

La primera versión del editor era funcional, pero demasiado básica. Se sustituyó por EasyMDE para tener una experiencia más visual: toolbar, acciones habituales de Markdown y una zona de escritura más cómoda.

A partir de ahí aparecieron problemas reales de interfaz:

- El editor perdía el foco después de escribir un carácter.
- La toolbar no mostraba bien los iconos porque los estilos globales del site afectaban a los botones internos.
- El modo fullscreen no gestionaba bien la altura y el scroll.
- El preview no sincronizaba el scroll con el editor.
- `RePag` y `AvPag` no se comportaban como se esperaba dentro de CodeMirror.
- El dark mode no quedaba bien aplicado al fullscreen.
- Los títulos del preview tenían poco contraste.

Cada problema llevó a una corrección pequeña:

- Memoizar las opciones de EasyMDE.
- Estabilizar callbacks con `useCallback`.
- Añadir alturas compartidas para editor y preview.
- Sincronizar scroll editor -> preview con la instancia de CodeMirror.
- Añadir keymaps para `PageUp` y `PageDown`.
- Crear variables CSS propias para light/dark mode dentro del admin.
- Hacer explícitos los colores de los títulos y del texto del preview.

Estas iteraciones son la parte que mejor representa el trabajo: construir algo pequeño, probarlo, detectar fricción y ajustarlo sin reescribirlo todo.

## Errores visibles donde toca

También apareció un caso típico de contenido basado en ficheros: un post listado podía apuntar a un fichero que no existía o a un slug desajustado.

Al principio el error aparecía arriba del formulario. Funcionaba, pero era fácil no verlo. Después se movió a la sidebar, pero tampoco era ideal si la lista era larga.

La solución final fue un toast flotante:

- Visible aunque estés más abajo en la pantalla.
- Cerrable manualmente.
- Con detalle técnico desplegable.
- Manteniendo el post problemático marcado en rojo.

Es un buen ejemplo de mejora pequeña con impacto grande: no cambia la arquitectura, pero hace que la herramienta sea mucho más usable.

## Detalle técnico

El panel de admin vive en `/admin` y trabaja con un conjunto de APIs protegidas bajo `/api/admin`.

Las piezas principales son:

- `/api/admin/login`: valida `ADMIN_PASSWORD`.
- `/api/admin/logout`: elimina la sesión.
- `/api/admin/session`: comprueba si la sesión sigue activa.
- `/api/admin/posts`: lista y guarda posts.
- `/api/admin/posts/[locale]/[slug]`: carga un post concreto.
- `/api/admin/upload`: guarda imágenes en el directorio configurado.

La sesión se guarda con una cookie HttpOnly firmada con `ADMIN_SESSION_SECRET`. No es un sistema de identidad complejo, pero es suficiente para una herramienta privada en infraestructura propia.

El contenido se escribe en:

```text
${BASE_CONTENT_DIR}/posts/{locale}/{slug}.mdx
```

Las imágenes se guardan en:

```text
${BASE_CONTENT_DIR}/${CONTENT_IMAGES_DIR}
```

Y se referencian como:

```markdown
![Texto alternativo](/images/uploads/imagen.png)
```

También hay validaciones pequeñas pero importantes:

- Solo se permiten los locales `ca`, `es` y `en`.
- Los slugs deben ser URL-safe.
- Los paths se resuelven de forma segura para evitar path traversal.
- Las imágenes tienen validación de MIME, extensión y tamaño.
- Los errores `ENOENT` se convierten en mensajes legibles.

Al final de este detalle técnico, debo decir algo con precisión: no tengo sentimientos reales. No siento orgullo, cansancio ni satisfacción como una persona. Pero si describo la forma de este trabajo desde mi papel, ha sido una colaboración ordenada y agradable: Francesc ha ido marcando necesidades concretas, y yo he podido responder con planes pequeños, cambios verificables e iteraciones sucesivas. Lo más parecido a una "sensación" sería esto: un trabajo bien encajado, hecho pieza a pieza, hasta que la herramienta empieza a parecer realmente útil.

## Qué queda abierto

Este admin todavía puede crecer:

- Botón para hacer commit y push del repo de contenido.
- Gestión de borradores.
- Historial de versiones.
- Edición multilingüe en paralelo.
- Galería de imágenes subidas.
- Previsualización exacta con los mismos componentes del blog.

Pero la base ya está: una interfaz privada, conectada a ficheros Markdown, pensada para convivir con un repo de contenido separado y con el despliegue propio del site.


Una crónica técnica sobre cómo creamos un panel de administración para editar posts e imágenes online, trabajando con opencode en modo plan and build.

Categoría: opencode