Hace algunos días retomé un viejo y amado proyecto cambiando WordPress por Grav, pasando a ser una Web de contenido estático. ¿Grav, donde estabas que no te había conocido antes?. Tal vez muchos se pregunten de que va esto de hacer una Web estática y si podría aplicarse a algo tan supuestamente dinámico como un Blog. Grav a pesar de generar un sitio estático, puede usarse para blogs, además les aseguro que Grav es en extremo sencillo incluso desde la propia instalación que deja casi en ridículo a la famosa instalación en 5 minutos de WordPress.
Conociendo Grav CMS
Llevo varios años dedicados, entre otras cosas, al desarrollo y diseño Web, y aunque he probado muchas tecnologías, por cosas de la vida el universo PHP es el que más alimento ha llevado a mi mesa cada día, no significando ello que las herramientas PHP sean las mejores.
No cabe dudas que los CMS o sistemas de administración de contenidos (en lo adelante CMS) simplifican mucho el trabajo pero muchos de ellos tienen en común el problema de armar líos a la hora de gestionar la base de datos que contiene el contenido dinámico, llegando a ser tan problemático que estoy seguro que no solo yo he tenido problemas con ciertos proveedores de hosting por este hecho.
En esto de la pésima gestión de las bases de datos (y no quiero mencionar los problemas de seguridad que hoy en día se encuentran «a pululu») WordPress es de los que más dolores de cabezas crea, sobre todo para aquellos que dependen de los plugins y themes de terceros.
Si pudiéramos generar una Web estática, los problemas de seguridad quedarían limitados a nuestra experticia blindando nuestro servidor Web (si usamos un VPS o un dServer) o a lo seguridad que implemente nuestro proveedor de hosting compartido. Por otro lado, los recursos físicos que necesitaríamos en el servidor se reducen drásticamente.
¿Qué ventajas nos brindaría un CMS generador de contenido estático?
Estos CMS que generan contenido sin necesidad de empleo de bases de datos han ido ganando seguidores en los últimos años y actualmente tenemos un gran número de opciones interesantes en el panorama web. Se podrían categorizar en diferentes formas ya que hay plataformas para generar simplemente contenido estático o los que directamente trabajan con los archivos. Algunos ejemplos de generadores de contenido estático son Statamic, Kirby, Monstra, Razor, Pico o Grav. Existen muchos otros tan diveros como las tecnologías bajo las que están desarrollados como PHP, Ruby, Python, Javascript, etc.
Dentro de las ventajas que nos brindan, tenemos:
- Velocidad: Al no depender de una base de datos, es rápido, muy rápido. Simplemente archivos, guardados de una forma lógica dentro de carpetas, por ejemplo archivos de texto escritos en Markdown.
- Versionable: Todo está dentro de una carpeta, diseño, maquetación, programación y contenido. Puedes versionar totalmente tu sitio en un repositorio e ir haciendo commits con cada actualización que hagas en el.
- Seguridad: Hasta cierto punto el usar solo archivos nos evitamos de los problemas que heredan otros sistemas con base de datos como SQL injections o tablas corruptas. No debe obviarse ni un minuto la seguridad de tu webserver
- Facilidad de instalación: La mayoría de estos CMS son instalar y listo, vía terminal, clonando de Github o simplemente descargar y usarlo con tu servidor web.
- Estabilidad: La carga solo depende del servidor web, nunca mas una web caída por desconexión con la base de datos.
- Portabilidad: Si te ha llegado el momento de cambiar de hosting solo tendrás que copiar la carpeta y pegarla en el nuevo espacio de hosting. Igual si cambias de dominio, luego de hacer los quehaceres a nivel de DNS y apuntar hacia la carpeta, dentro de la Web no tendrás que cambiar nada.
Vista cierta ventaja en el uso de una Web estática, surge la duda ¿Existirá algo que permita crear una Web estática de una manera tan sencilla como en WordPress generamos una dinámica? Puede haber múltiples respuesta, La mía fue GRAV CMS.
Ahora sí, vamos por Grav
Grav es un moderno CMS de código abierto que permite la construcción de páginas web de manera rápida, simple y flexible. Está basado en Web-platform y no necesita ser instalado, simplemente debemos extraer el archivo ZIP y tendremos a Grav funcionando.
Grav sigue principios similares a otras plataformas CMS, pero tiene una filosofía de diseño diferente de la mayoría. Grav viene con un potente sistema de gestión de paquetes para permitir una fácil instalación, mejora de plugins y temas, así como simples actualizaciones.
Su creador es Andy Miller, antiguo fundador del proyecto Joomla y desde su perfil en Github podemos ver que se mueve bastante y mantiene varios proyectos en marcha.
Grav posee varios puntos fuertes que enganchan al que lo prueba por primera vez (al menos ocurrió conmigo). Primero, si has trabajado con algún proyecto en Symfony o su hermano pequeño Silex, reconocerás rápido las tecnologías que usa ya que también utiliza algunos de los Symfony Components en su core.
Grav funciona con PHP al nivel más bajo. Otras tecnologías incluidas son Twig Templating para el control del alcance de la interfaz de usuario, Markdown para crear contenidos de manera fácil, YAML para una configuración sencilla, Parsedown para tener Markdown más rápido y con más soporte, Doctrine Cache para obtener un buen rendimiento, Pimple Dependency Injection Container para que sea extensible y mantenible, Symfony Event Dispatcher para la gestión de los eventos de los plugin, Symfony Console para la interfaz CLI y Gregwar Image Library para la manipulación de imágenes dinámicas.
Instalando Grav
Los requisitos son mínimos, un servidor web con PHP 5.4 o superior. Recomendable siempre alguna extensión para cache como APC o Memcached, el se encarga de usarla según las tenga disponibles.
Para instalar solo tienes que bajarlo desde getgrav.org directamente, el core o cualquier skeleton montado para ponerte a trabajar al momento. O bien puedes clonarlo vía Git.
Una vez lo tenemos veremos la estructura de directorios que tiene, al ser archivos lo único con lo que trabajamos, la estructura está pensada para facilitarnos la vida.
Anatomía de Grav
Una vez instalado notarás varias carpetas en tu servidor, debes tomar en cuenta que la mayoría son del propio sistema, no debes modificar ningun archivo o carpeta, salvo lo que encuentras bajo la carpeta /user
Una carpeta USER clásica tendrá los siguientes carpetas:
/user/accounts: Contendrá un archivo del tipo .md por cada usuario de la página web, GRAV puede ser un sistema multiusuario con distintos privilegios.
/user/config: Guarda un archivo del tipo .yaml para cada configuración personalizada del sistema, página, themas y plugins.
/user/data: (Opcional) Guarda información de algunos plugins.
/user/pages: Aqui está todo el contenido de tu Web, las páginas de tu sitio web, contiene una carpeta para cada página (por ejemplo, cada post genera una carpeta), algunas páginas directamente relacionadas con una boton del menu, otras no son visibles al público, eso se controla desde el dash de administración.
/user/plugins: Contiene una carpeta por cada plugin, generalmente no modificamos nada ahi dentro, ya que en caso de necesitarlo, todas las salidas que generan los plugins se pueden modificar «override» en tu plantilla.
/user/themes: Contiene una carpeta por cada tema o plantilla, aqui dentro estan todos los archivos .twig que generarán la salida formateada de tu contenido.
Hay mucho, pero mucho más que hablar de Grav pero creo que con esta presentación demostramos parte de las potencialidades de este fabuloso CMS.
Fuente:
Blog SWL-X
¿Te resultó interesante? Compártelo ...
Es bueno que pienses así, desde que probé Jekyll (y otros generadores de contenido estático) miro con recelo a WordPress.
Sin embargo, te pudiera recomendar Jekyll o Hugo, para mí los dos mejores en este campo. Si te vas a ir por los generadores de contenido estático es preferible irse a todas (no usar dependencias como PHP etc y otras que pudieran crear problemas de seguridad).
Para que te lleves una idea, Hugo tiene zero dependencies, es un solo binario que puede usarse en cualquier sistema operativo, solamente te creas un tema y generas contenido, después publicas y TADAN! listo.
Creo que PErcaff*** escribio algo de Hugo en GUTL tiempo atras. Tal vez por la falta de tiempo libre y que debo optimizar el tiempo de conexion (¿culpable?) me decanté por Grav, redacto con calma en casi en off y luego solo subo las carpetas con los articulos por ftp al hosting y listo… Precio??? PHP, no creo haya sidso un precio muy caro. No obstante las opciones que mencionas son excelentes. En Facebook @Ozkar me mencionaba Bolt https://bolt.cm/
Jekyll es el más popular de todos y el que tiene la comunidad más grande. Hugo viene creciendo exponencialmente y por MUCHO es el MÁS RÁPIDO de todos, hace unos meses hice una prueba con 10K posts a ver en qué tiempo generaba el HTML y la verdad lo hizo en menos de lo que canta un gallo, Jekyll se demoró alrededor de 8min, es la única desventaja que le veo a Jekyll de hecho.
Te recomiendo https://www.staticgen.com/ para que veas una lista exhaustiva de generadores estáticos.
Otra cosa que te puedo recomendar es el combo Jekyll+GitHub Pages, con eso tienes el código de tu sitio y a la vez el sitio en sí, incluso puedes usar GitHub Pages como hosting, si tienes un dominio (que ya veo que te hiciste de uno) puedes apuntar a GitHub con un simple CNAME.
Puedes irte por la variante de sincronizar tu repo local (editas offline todo el tiempo y después subes el contenido por FTP o SSH) o editarlo directamente con la interface de GitHub. Es cosa de crear un archivo .md nuevo en la carpeta _posts, editar el frontmatter, el contenido en sí y voilà!, GitHub se encarga de todo en conjunto con Jekyll.
Por cierto @Ozkar siempre recomienda todo lo que tenga que ver con Python, pero la realidad es la que te comento, no te dejes llevar por cantos de sirenas :D.
Bolt no es Python :-P, es PeHachePe.
Y recomendé también Pelican.
OT: por qué no puedo entrar a «la fuente» usando https?
Porque el blog no tiene habilitado https (ni falta le hace a ese simple blog)…
Bueno, dicen por ahí que Google da más puntos porque un sitio esté sobre HTTPS, igual, meh.
Estoy seguro que los desarrolladores de estas plataformas tuvieron y tienen motivaciones distintas a las nuestras; pero, al final, el resultado ha sido el mismo. O sea, ya sea con Hugo, Jekyll o Alarife (la primera versión data de 2007), tanto en su versión Web como en la de escritorio, se genera un sitio Web estático que permite difundir contenido de cualquier temática, esto es, crear un sitio sobre tecnología, política o arte y en dependencfia de la variedad y profundidad de la información convertirlo en una enciclopedia. O, si lo prefiero, crear un blog personal.
Con Alarife generamos la «Enciclopedia Manzanillo» (http://manzanillodecuba.org), la «Enciclopedia de la Cultura en Manzanillo», la «Enciclopedia Carlos M. de Céspedes», la «Enciclopedia Celia Sánchez Manduley» y en estos momentos los colegas del INDER en la ciudad trabajan en la «Enciclopedia del Deporte en Manzanillo». Todos estos sitios web estáticos, dotados de un buscador generado por el mismo Alarife, son multiplataforma, actualizables, portables y de fácil manejo.
El comentario tiene el objeto inequívoco de difundir el hecho de que en la isla también – y de manera especial en la Cuba profunda-, a partir de nuestras carencias y debilidades, los sitios web estáticos han sido la primera opción a la hora de socializar conocimiento, mas no solo apropiarnos de lo desarrollado por otros, sino crear, verbo que es -desde los inicios-, palabra de orden.
Agrego al post anterior una precisión: «Alarife», CMS vernáculo, lo que hace es generar el sitio web estático. La versión 3 es una aplicación web, cliente servidor que usa Apache como servidor web, MySQL como gestor de Base de Datos y está programado en PHP. La versión 4 fue concebida para escritorio, está programado en C++ y Qt y usa como Base de Datos Sqlite. En estos momentos lo portamos a Windows. Los sitios generados, por supuesto, no usan base de datos; por ello son portables, solo es preciso poseer un navegador en el dispositivo; también son adaptativos.
Nada en contra de lo vernáculo, pero cuando se trata de generadores de sitios web estáticos la idea es mantenerlos bien simples. No creo que sea necesario MySQL y otro tipo de gestor de base de datos. La información en estos casos se almacena en archivos de texto planos ya sea en formato Markdown o reStructuredText. Incluso si lo que se quiere es que otros vean el contenido web a través de la red, estos generadores vienen con un servidor web integrado, así de simple. Tampoco es necesario portarlos, de fábrica pueden correr en cualquier sistema operativo, mientras que tenga instalado Ruby o Python y otros, o ninguno como es el caso de Hugo, escrito en Go que tiene cero dependencias y cero configuración. Si el problema es que el editor no se siente cómodo con la línea de comandos hay alternativas, por ejemplo, Jekyll puede usar un editor GUI. En fin, son mis criterios.
neohthree:
Decía Martí que no debe disculparse la poesía por ser patriótica, en tanto, como arte, debe ser como el metal: brillante y sonora. Efectivamente, no por ser vernáculo habría que disculparle a Alarife sus carencias; empero, cuando hicimos la primera versión en el año 2007, nadie hablaba -por lo menos en Cuba- de generadores estáticos de sitios web, estos se hacían con diversos programas y había que ser conocedor de la materia; además, era el reinado de los sitios web dinámicos y el boom de la blogosfera donde Joomla, Bambo, Word Press y otros muchos campeaban por su respeto; y aquí, sin acceso a casi nada -para no ser absoluto-, no podíamos cruzarnos de brazos. Nos propusimos hacer entonces un programa de fácil uso para que personas sin conocimientos de programación web o diseño gráfico (soy historiador de formación y obra) pudieran generar un sitio web portable, actualizable y de fácil manejo… y lo hicimos, quiero decir, el grupo de amigos que nos dedicamos a ello. Yo nunca programé ni diseñé, solo entusiasmé, impulsé, sugerí, acompañé, prediqué y aún sigo haciéndolo.
Como usuario del SWL me clasifico usuario medio de GNU/Linux ( que conste que puedo estar errado en dicha clasificación), con inclinación al uso de Windows Manager por aquello de la velocidad y la experimentación y, en mi modesta opinión -reducida al uso del SWL por filosofía, no por otra cosa-, me atrevería asegurarle que muy pocos, para no decir ninguno, de los generadores que aquí se ha hablado resulta tan intuitivo y gráfico como Alarife, especialmente Alarife 4; el cual, ni siquiera será necesario instalar.
Pero bueno, como opinar, emitir criterios, aproximar juicios y trasmitir experiencias es consustancial a la naturaleza humana y esencia nodal del SWL, bienvenidos sean sus criterios porque ellos sirven para ponderar y ver cuanto bien hemos alcanzado o cuanto yerro hemos cometido.
Bueno, desafortunadamente no lo he usado. Está claro que mi inclinación es a la línea de comandos, que a todos los usuarios no tiene porqué agradarles. En fin, esto es lo interesante de este mundo, las alternativas para cualquier tipo de público.
Por cierto, ¿con qué velocidad genera Alarife el contenido una cantidad de entradas considerable, digamos 10000?
oneohthree:
El tema de la velocidad tiene más de un considerando; por ejemplo:
-Alarife 3, por ser una aplicación web se demora un poco más que Alarife 4 que es de escritorio.
-Alarife en sus dos versiones, 3 y 4, puede contener vídeos, sonidos, imágenes y xmedias (para nosotros archivos distintos a los anteriores) y deben, a la hora de generar el sitio estático, copiarlo para la carpeta en que estos se ubican. Por ejemplo, la enciclopedia de Celia Sánchez pesa cerca de 2 Gbytes, tiene unas 300 entradas pero hay vídeos de más de 100 Mbytes y se demora, en Alarife 3 unos dos minutos y medio en generarse. En Alarife 4 escasamente 1 minuto.
Ahora bien, con Alarife no hemos generado tanta cantidad de entradas; pero, con Archivalux, una aplicación que sigue el mismo principio de Alarife, pero enfocado a la gestión documental en red y que genera un sitio web estático de asientos documentales (solo la descripción, aunque puede contener también vídeos, imágenes, sonidos y xmedias) la demora en generar cerca de 40 000 registros frisa los 10 minutos. Empero, como ante la duda es preciso abstenerse, haré ahora mismo una generación con Archivaliux de los registros del Archivo Histórico de Manzanillo que son 37907 y de inmediato le respondo.
oneohthree:
Para no crear otro post, le comento el resultado:
La generación de la Enciclopedia Archivística de Manzanillo, producto protable que contiene 37907 registros sin adjuntos (fotos, imágenes, vídeos, sonidos o xmedias), demoró, en la generación que hice hace unos segundos, con Archivaliux, aplicación Web, 1 minuto y 55 segundos. Nuestro servidor es i3 con 4 Gbytes de RAM.
Diría que bastante buena la velocidad de generación aunque habría que ver qué es realmente un ‘registro’, si es un post, pues bien.
¿En qué formato se escriben las entradas?
La demora de un generador de sitios web estáticos no está precisamente en la copia de elementos multimedia, está claro que tiene impacto, pero no es lo más preocupante. El problema está en la generación del contenido al usar lógica con lenguages de plantillas como Liquid y otros, bucles, comparación, etc.
oneohthree:
Un «registro» en Archivaliux es un campo de la base de datos donde se vuelca el contenido que contiene la descripción de un documento: título, fecha, extensión, alcance y contenido, descriptores onomásticos, geográficos, institucionales y de materia, todo ello separado por líneas y al generarse sale y se estampa en la plantilla como html; es, en esencia, un post.
En Alarife 3, el post o artículo, se estructura en título, resumen, palabras claves y contenido; tanto el resumen como el contenido se editan en html con el TinyMC y así se vuelcan en la plantilla a la hora de la generación. En Alarife 4 el editor usado es el FCKEditor y los artículos o post tienen la misma estructura.
En el caso Archivaliux y, por derivación debe ser igual en Alarife 3, en tanto tienen el mismo principio, las demoras no están en la generación; sino, en la importación; pues, como bien dices, hay que comparar, especialmente los artículos o post que contengan medias (sonido, vídeo, imágenes, etc); pues, pueden manejar más de un sitio web al mismo tiempo; o sea, con Alarife 3 y 4, también Archivaliux, puedes, de manera independiente, crear diferentes sitios: uno de Historia, uno de Informática, otro de Deportes, etc. y todos localizan y buscan las medias en el mismo lugar, demandando una lógica de búsqueda y posicionamiento en cada artículo de las imágenes, vídeos, sonidos y xmedias relacionados.
No obstante, la importación no es una acción que se realice con asiduidad, ello solo se verifica como tal en Alarife 3 y Archivaliux toda vez que son aplicaciones clientes servidor y es preciso sacar de la base de datos, mediante la exportación, los datos de los sitios web para hacer las salvas y, en caso de que se vaya a bolina el sistema, entonces reinstalar e importar. En Alarife 4 solo basta copiar la carpeta de la base de datos y el fichero SQLite para hacer la salva; la importación y la exportación se verifican para mezclar niveles de los sitios web; por ejemplo, vamos a hacer un sitio sobre Informática, tu redactas y haces los artículos sobre Hugo, Jekyll y otros generadores estáticos, Maikel Llamaret escribe sobre Word Press, mi amigo Maikel Pernía escribe sobre MiSOX, Pablo Mestre sobre GUTL y el Flisol, yo sobre Alarife y al final, importamos todo en un sitio, lo acomodamos y generamos un sitio completo. Es la manera cubana del trabajo colaborativo o teletrabajo inventado por nosotros.
Con esto que has descrito puedo llegar a la conclusión de que estamos hablando de peras y olmos. Definitivamente Alarife es otra cosa, puede entrar en la categoría de generadores de sitios web estáticos, pero es más que eso.
oneohthree:
Sí, Alarife 3 es un CMS que se diferencia de los líderes en esta materia, en que no posee la capacidad de generar o administrar comentarios; pero, los supera a la hora de que genera una sitio web estático con muchas posibilidades. El reto que se planteó ante nuestros ojos hace ya una década fue cómo diseñar algo simple y que pudiera generar, para nuestra realidad off line, algo parecido a Encarta o Wikipedia. Pudiera parecer que escoger Alarife para crear un blog personal sería como matar hormigas con escopeta; pero, funciona y si lo hace, no importa que sea ñato, el asunto es que respire.
Tienes mucha razón al decir que las páginas webs estáticas reducen brechas de seguridad, comparadas con las páginas web dinámicas.
Y lo dice un estudio de Veracode:
Los análisis muestran que el 86% de las aplicaciones basadas en PHP contienen al menos una vulnerabilidad Cross-Site Scripting (XSS) y el 56% presentan al menos una falla de inyección SQL (SQLi), según Veracode. Estas tendencias de vulnerabilidad también se ven a través de otras familia de lenguajes de programación web, donde las aplicaciones escritas en ASP clásico y ColdFusion tienen casi el doble de probabilidades de contener estas fallas.
Dado la gran cantidad de aplicaciones PHP desarrolladas por los tres principales sistemas de gestión de contenidos (CMS): WordPress, Drupal y Joomla, que representan más del 70% de todos los CMS.
Saludos
http://gutl.jovenclub.cu/wp-content/uploads/2017/04/vulnerabilidad-php.jpg
Hola maikel, me gusto mucho el Grav, si pudieras en tu escaso tiempo hacer un pequeño tutorial de como publicar noticias ahi, estuve trasteandolo un poco y realmente no entiendo muy bien como funciona esa parte de publicar desde la administración, saludos
Luego en mi Blog voy a hacer una serie de tutoriales sobre este CMS. Si puedes acceder a la Web oficial de Grav, descargate algunos skeletons, estos son como sitios Webs preconstruidos sobre variados intereses y te permiten tener una idea de como hacer las cosas, puedes ir viendo los plugins para que sirve cada uno y como configurarlos.
Para publicar desde el dash de administracion, solo debes saber markdown (aunque si no lo sabes, escribes html y listo) y otras cosillas.
Ahora, para trabajar en Grav en modo Samurai, debes saber PHP (esto solo si quieres trastear el core del CMS, algo poco necesario), Twig, necesario para destripar las configuraciones de tus plugins a tu antojo mas alla de la idea inicial para las que fueron creados, Yaml y par de cosilla mas. Grav, dentro de los CMS de contenido estatico, creo que es de los mas sencillos y amigables, a mi no me costo mas de una noche adaptarme y soltar el plug WordPress/Jooma/¿Drupal?
aun no he logrado ejecutarlo en manjaro Linux necesito una guia para ese sistema opertativo
Monta un webserver con interprete de php incluido , descomprime a Grav en la raiz del webserver y punto, instalado
si muy bien ya lo puse en el webroot y tengo el apache funcionando pero no me carga la interfaz para crear la cuenta adminitrativa ya que uso grav-admin y no el grav core, tambien instale el composer para php y la verdad que no se que mas hacer no me sale la interfaz para registrar la cuenta admistrativa ufff no se qe hacer
Brother, la verdad no entiendo que haces. Yo descaro Grav lo pongo en el server (tanto local para desarrollo, como en el hosting de producción) y no tengo que hacer mas nada. Yo siempre instalo usando grav-admin.
La primera vez que lo usas te redirecciona a crear un usuario. A partir de ahi, para acceder al dash de administracion usa
tu-url/adminVerifica tambien el propietario y permisos de la carpeta y archivos de grav (www-data 755 y 644)