Estoy buscando un Ruby CMS (o complemento) que pueda servir y editar contenido ubicado en un repositorio de Git. Estoy harto de tener mi contenido en un db. Usuarios, configuraciones, comentarios, bien. Pero no más contenido.¿Gestión de contenido basada en Git?
Cada edición en vivo de una página tendrá que ser comprometida de forma automática e inmediata para evitar la necesidad de una fusión en el servidor. Además, cada vez que se presionen nuevos cambios, deberán actualizarse inmediatamente en el sistema de archivos.
Refinería La documentación de CMS parece hacer algo similar, aunque quizás con un repositorio remoto.
He leído sobre GitModel y git-blog, pero todavía estoy buscando algo que coincida con mis necesidades un poco más cerca. [EDITAR: GitModel es demasiado difícil de editar manualmente cuando se usa con la mayoría de los CMS, y git-blog usa generación de archivos estáticos.]
EDITAR: Mi sesgo contra las bases de datos solo se aplica a los sitios que necesitan un alto grado de personalización, y no puede usar ningún CMS tal como está. Sitios cuyo código evoluciona tanto como su contenido. Esto es cuando tener contenido en un DB es una pesadilla total. Cuando tenga que bifurcar el contenido y el código al mismo tiempo, los combinará en la producción más adelante. Los DB no se ramifican ni se fusionan.
Tengo un sitio.
El argumento de rendimiento a favor del contenido solo de base de datos es nulo e inválido. Escribí un CMS hace 5 años que sincroniza la base de datos del sistema de archivos, donde el sistema de archivos es siempre la copia maestra. Escalaba fácilmente a 100.000 páginas, manteniendo tiempos de respuesta de 10 ms y tiempos de reindexación de 2 segundos. Índices totalmente buscables de todo el contenido, metadatos, etiquetas, fechas, etc. Y diablos, lo escribí en el marco más lento y doloroso del planeta, ASP.NET. Realmente casi hizo soportable a ASP.NET, y ha servido a varias compañías extremadamente bien, ya que tenían el mismo tipo de sitio que el mencionado anteriormente.
sitios pequeños pueden simplemente utilizar una caché en la memoria, pasando el contenido completo db
Un argumento válido para el contenido db sólo es la escalabilidad de la edición. Los editores deben usar el mismo servidor, aunque los cambios se pueden replicar hacia afuera. Pero en el caso de sitios muy personalizados y que cambian rápidamente, que cambian el código tan a menudo como el contenido, la edición distribuida/comunitaria de dicho código y contenido es poco probable. La edición comunitaria/distribuida puede usar un sistema diferente.
Hasta ahora, lo más cercano que he venido es usar Cloud9 para editar un repositorio de contenido de git (Nesta CMS), luego presiono los cambios a través de la línea de comando. Es lento, pero al menos está basado en la web en caso de que mi máquina de desarrollo no sea útil, y descubro que escribí mal mi nombre en un artículo. Todavía estamos buscando mejores opciones.
¿Te gustaría hablar un poco acerca de por qué no quieres contenido en la base de datos? –
"He leído sobre GitModel y git-blog, pero todavía estoy buscando algo que coincida con mis necesidades un poco más cerca". ¿Qué pasa con esas cosas que encuentras insatisfactorias? – MatrixFrog
GitModel no ofrece mucha flexibilidad sobre cómo se escriben los archivos, y hace que editarlos directamente sea un poco difícil. git-blog usa generación estática, mientras que la mayoría de mi sitio contendrá una funcionalidad dinámica avanzada. –