Show HN: Pages CMS – Un CMS para GitHub

Artículo original ↗ Discusión en Hacker News ↗

Un nuevo proyecto de código abierto, Pages CMS, ofrece un sistema de gestión de contenido basado en GitHub que se sitúa sobre generadores de sitios estáticos existentes como Jekyll, Hugo, Eleventy, Astro y Next.js, con el objetivo de recrear una experiencia de edición estilo WordPress sin encerrar a los usuarios en un proveedor de alojamiento específico. Los comentaristas elogian su UX más simple frente a herramientas como Decap/Netlify CMS y TinaCMS, aprecian el autoalojamiento sencillo en servicios como Cloudflare Pages y destacan funciones como soporte para múltiples repos, tipos de contenido configurables y edición de texto enriquecido. Los retos clave y elementos de la hoja de ruta incluyen una mejor incorporación mediante configuraciones generadas automáticamente, soporte mejorado para MDX y colecciones HTML, opciones de almacenamiento de medios (S3/R2) y una compatibilidad más amplia con proveedores Git más allá de GitHub.

Recepción general y casos de uso objetivo

  • Muchos comentaristas están entusiasmados, especialmente quienes echan de menos Forestry o están descontentos con Decap/Netlify CMS y Tina.
  • Casos de uso populares: blogs y sitios de documentación construidos con Hugo, Jekyll, Eleventy, Astro, Next.js y otros SSGs, facilitando que usuarios no técnicos editen contenido en repositorios Git.
  • Algunos lo ven exactamente como la «capa delgada de CMS sobre GitHub» que habían estado deseando.

Configuración, ajustes y UX

  • La gente elogia la UI/UX y cuenta que lo pusieron a funcionar en Cloudflare en minutos.
  • Otros señalan que la incorporación aún no es completamente de «hacer clic y listo»; averiguar la configuración de páginas y los esquemas de contenido todavía requiere esfuerzo.
  • Varios piden un asistente de configuración que infiera tipos de contenido y campos a partir de carpetas y front matter existentes; el autor indica que eso está previsto.

Formatos de contenido e integración con SSG

  • Funciona bien con front matter en Markdown para los SSGs comunes.
  • Limitaciones actuales: el soporte de MDX es parcial (los archivos sueltos mediante el modo «code» funcionan; las colecciones y el editor enriquecido aún no son sólidos).
  • Algunos usuarios de Jekyll no tienen claro cómo se asigna «body» cuando solo está implícito después del front matter.
  • Hay demanda de mejor soporte para HTML y colecciones MDX, date-from-filename para Jekyll, y colecciones YAML planas en lugar de un archivo por entrada.

Autenticación, alojamiento y proveedores Git

  • Por ahora solo se admite GitHub; el código puede alojarse en cualquier lugar (p. ej., Cloudflare Pages), el CMS es puramente frontend más pequeñas funciones de autenticación.
  • OAuth de GitHub requiere acceso amplio al repositorio; a los comentaristas les incomoda, pero los tokens de acceso personal con permisos granulares y el autoalojamiento lo mitigan.
  • Algunos quieren encarecidamente soporte para GitLab, Bitbucket, Gitea o una API Git genérica; Git genérico actualmente está fuera de alcance.

Gestión de medios y almacenamiento

  • El editor de texto enriquecido inicialmente fallaba cuando no se configuraba media; se publicaron hotfixes rápidamente.
  • Los usuarios piden servicios de carga S3/R2 y de terceros; el soporte para S3/R2 se está desarrollando activamente.
  • Los medios pueden colocarse junto a las entradas configurando filtros por extensiones de archivo.

Comparaciones, precios y filosofía

  • Se compara con frecuencia con Decap, Static CMS, Keystatic, Tina, Statamic, Lektor, Publii y CloudCannon.
  • Los principales diferenciadores que se discuten: UX más simple que Decap, funciona completamente en línea a diferencia del modo de escritorio de Keystatic, y no requiere alojarse con un proveedor específico.
  • El proyecto tiene licencia MIT y es autoalojable; se menciona una futura capa «Pro» para funciones avanzadas, lo que genera cierto escepticismo sobre el estado libre a largo plazo.