Migrando (varios sitios) a Pelican, parte 0
Como había mencionado en un post anterior, tener el blog en WordPress, aunque útil, iba a ser algo completamente temporal. Y es que, si bien es muy cómodo tener un sistema visual, que permita añadir funciones al sitio sin intervención (técnica) de mi parte, tiene varios inconvenientes que quiero evitar.
Uno de ellos, el que más me preocupa realmente, es depender de un sistema (por robusto y actualizado que sea) dinámico. Quiero decir: el 99% del tiempo este sitio no utiliza las funciones de WordPress que podrían valer la pena para mantenerlo; lo más dinámico que se llega a utilizar es la búsqueda del sitio, porque ya ni los comentarios son tan requeridos. Cosa de los nuevos tiempos, supongo, donde casi todo el contenido está en plataformas como YouTube. Como sea, es posible habilitar ambos contenidos dinámicos sin utilizar PHP, y también puedo mejorar mucho la experiencia del usuario en cuanto a velocidad de carga, mejor posicionamiento web, y así.
Problemas que vienen
Me planteo algunos inconvenientes, que comparto con ustedes para su entretenimiento:
- Ya no puedo usar plug-ins. Lo que en sí mismo es la mayor ventaja, lo convierte en un inconveniente. Por supuesto, Pelican tiene una buena colección de plugins que "hacen cosas", aunque todas procesan el resultado como HTML estático.
- Ya no puedo usar Temas. Es decir, el diseño web queda completamente en mi responsabilidad. Y, aunque existen buena cantidad de plantillas HTML de calidad (de pago, generalmente), ninguna de ellas está preparada específicamente para Pelican. Así que tendré que aprender Jinja2, que es lo suyo, sea ya que compre una plantilla, o directamente diseñe de cero una para cada sitio.
- Convencer a clientes. Esta parte no es tan difícil, aunque parezca lo opuesto. Casi todos mis clientes (que se reducen a unos 5) me delegan la actualización de su contenido. El último que no, realmente no va a requerir que convierta su sitio de un sistema a otro, aunque probablemente sea buena idea enseñarle MarkDown para el futuro.
Las ventajas que tiene
Como se sabe, las ventajas de tener un sitio estático, como cualquiera generado con Pelican, son muchas y variadas: - Libertad de elegir hosting. No estamos obligados a contratar un hosting compartido (aunque no hace daño), como podrían ser DreamHost o A2Hosting (links afiliados). Alojar un sitio estático, se puede alojar en un hosting gratuito (que nunca es buena idea, pero se puede), en un Slice de BuyVM, o en GitHub Pages. - No hay un "punto de quiebre" por causa del CMS. Al no utilizar un intérprete (ASP.net, PHP), se reduce el riesgo de ataques al sitio. Por supuesto, quedan otros accesos qué asegurar (por ejemplo, el acceso shell o FTP), pero esos ya son inherentes a Internet. - Comodidad para publicar. Aunque esto es debatible, ya que una de las razones por las que decidí usar WordPress fue justamente tener un escritorio visual para facilitar el trabajo, es cierto también que trabajar directamente con un programa de edición de MarkDown elimina en gran medida la necesidad del escritorio. Eso sí, no es tan visualmente agradable, pero sí es cómodo no tener que cargar el sitio completo para empezar a editar. - Facilidad para cambiar de hosting. Además del primer punto, es muy fácil comenzar nuevamente el sitio cuando no hace falta una base de datos. Es tan simple como cambiar las credenciales y host para copiar el sitio web y, listo, en cuestión de minutos el sitio estará nuevamente en línea en su nuevo hogar. - Es posible utilizar muy pocos recursos. Tanto a nivel servidor como en la propia ejecución del generador, es posible utilizar equipos relativamente viejos, ya que solo se generará el contenido una vez cada que actualicemos. - Mejor administración del ancho de banda y transferencia. Aunque las técnicas de caché han mejorado muchísimo para WordPress, es verdad que siguen siendo insuficientes en muchos casos. Además, algunos plugins están pensados para actualizar la caché una o dos veces al día. En sitios que se actualizan más bien poco, es innecesario, y cada vez que se actualiza, los visitantes volverán a recibir una página que ya han visitado. Por supuesto, la compresión gzip se puede activar del lado del servidor, para mandar aun más comprimidos los datos. - Menos impacto en CPU del servidor. Podríamos decir que el consumo del procesador del servidor tiende a cero, ya que no hay procesos continuamente trabajando para nuestro sitio. Si te corren del hosting, no es por el consumo de CPU.
Entre bastantes otros beneficios. Y, por supuesto, no son exclusivos de Pelican, sino son compartidos por todos los generadores de sitios estáticos.
¿Por qué Pelican?
Es simple: porque ya he trabajado antes con él. Es fácil editar (sólo hay que escribir ReStructuredText o MarkDown), la documentación de Jinja2 es extensa, es ligero (realmente, toma apenas segundos regenerar un sitio enorme, ya no digamos sitios pequeños), y su comunidad es cada día más grande.
Aunque intenté usar en algún momento Jekyll y Publii, realmente no terminé de adaptarme a ellos. Jekyll lo quise utilizar en HostGator (directamente, sin usar una máquina virtual en mi equipo para correr el generador), y simplemente me desesperé; supongo que podría haber funcionado, pero fue hace ¿diez? años y no he querido darle una nueva oportunidad, sé que es uno de los más queridos por la comunidad, e inclusive es recomendado por GitHub.
Publii de plano me decepcionó. Aunque es completamente visual y es fácil de mover entre computadoras, creo que su interfaz no me termina de agradar. Tal vez me estoy volviendo viejo, o solamente es que ya me adapté a otras herramientas.
¿Qué se necesita?
Bueno, cada proyecto es un mundo. Yo tengo varios proyectos, casi todos personales, así que esta es una aproximación de lo que viene en mi futuro cercano:
- Elegir los diseños, ya sean comprados, gratuitos o creados de cero (esto último lo descarto por tiempo). Probablemente sea lo más simple, porque ya tengo en mente las necesidades de cada sitio.
- En un sitio, específicamente, tengo que adaptar su tema a Jinja2, porque se tiene que respetar, sí o sí, la apariencia.
- Prefiero usar plantillas prediseñadas porque el tiempo es poco y necesito que los sitios estén terminados en algunas semanas, no en meses.
- Adaptar las plantillas a Jinja2 para Pelican. Creo, sin temor a equivocarme, que este será el proceso más largo y tardado de cada sitio. Aunque las plantillas para las que tengo licencia (Be, Canvas, Thimix) realmente están muy bien escritas, yo no estoy acostumbrado a trabajar con Jinja2. Aun así, por lo poco que edité temas de Pelican en el pasado, parece que es algo sencillo.
- Integrar el nuevo Pelican Search (antes se usaba Tipue Search, pero al usar jQuery se desaconseja su uso) y Staticman (que es nuevo para mí, pero aparentemente resuelve el tema de los comentarios). He visto pocas alternativas al segundo, y mi favorito, Disqus, siempre tendrá el inconveniente de estar fuera de mi control.
- Convertir el contenido. Una tarea sencilla, con algunos matices para el sitio que requiere ser adaptado desde WordPress. Por lo demás, las plantillas que tengo analizadas ya tienen todo lo necesario para presentar el contenido de manera elegante y simple.
Esa es, someramente, la hoja de ruta para mi proyecto. Por supuesto, multiplicado por varios sitios, y con las aristas que posiblemente surjan en el proceso.
Futuras actualizaciones
Como es un proyecto un poco largo, como puedo caer en diferentes situaciones que se vuelvan rutinarias, utilizaré el blog como lo que eran los blogs: un cuaderno de notas.
Voy a documentar mi experiencia, tratando de ser lo más detallado que pueda, según las situaciones que se presenten. Sin embargo, espero que entiendan que estos posts no estarán pensados necesariamente para que los entienda un novato con Python/Pelican/Linux, sino para que pueda resolver problemas específicos de mi proyecto y futuras conversiones de otros clientes. Aun así, espero que les sea útil.