HacheMuda

Blog personal de Guillermo Latorre

Resultados de la búsqueda de "":

Migrando Hachemuda de WP a Piecrust (II): migración de contenidos y flujo de publicación

Explicación de los pasos y recursos que he utilizado para exportar los contenidos de WordPress a Markdown para usarlos en PieCrust y del método que sigo para la publicación de nuevos contenidos en el blog.

Hace unos días publicaba la primerta parte de este artículo, explicando un poco qué es PieCrust y las razones por las que he escogido este framework para gestionar HacheMuda, convirtiendo todo el sitio basado en WordPress en una página puramente estática.

Llevaba bastante tiempo escribiendo los artículos de Hachemuda en Markdown, pero no de una forma muy “correcta”. Los escribía y después los copiaba en HTML en el editor de WordPress para publicarlos.

Pasando los contenidos de WordPress a ficheros en Markdown

Lo primero que quise hacer al plantear seriamente la migración de WordPress a un CMS estático fue comprobar que podía extraer bien todos los contenidos de Hachemuda y convertirlos a ficheros Markdown sintácticamente correctos. Si conseguía eso, ya podía usar cualquier CMS. Independientemente de que uses PieCrust, Jekyll, Statamic o el que sea, los contenidos siempre puedes tenerlos en Markdown y personalmente me parece una buena idea disponer de ellos en ficheros de texto para manejarlos más fácilmente y no depender de ningún software para poder consultarlos, copiarlos o lo que sea.

PieCrust tiene implementado un importador automático que se supone que hace precisamente eso, pero no he podido probarlo porque cuando empecé con el framework ya tenía todos los contenidos migrados.

Lo que yo usé fue el plugin WordPress to Jekyll Exporter, un plugin para WordPress que genera un directorio con todos los contenidos de la base de datos convertidos a ficheros de texto Markdown, incluyendo también los archivos adjuntos, ficheros de configuración, etc. Como te habrás percatado por el nombre, está pensado para usar finalmente Jekyll como CMS, pero en realidad te da igual el CMS que vayas a usar, lo que quieres es convertir los contenidos a Markdown.

Tuve que modificar el script para que no exportara las categorías (sólo quería mantener los tags) y después tuve que hacer algún search & replace de caracteres que no se exportaban bien y hacían que el Markdown fuera sintácticamente incorrecto para Piecrust, pero nada que no se pudiera solucionar fácilmente con las herramientas avanzadas de búsqueda y reemplazo de cualquier editor decente, como Coda o SublimeText. También tuve que reemplazar algunas cadenas de texto propias de WP que estaban incluídas en el contenido de los artículos, como por ejemplo shortcodes para algunos plugins.

Lo bueno de usar ese plugin es que te genera la cabecera del fichero Markdown no sólo con el título, categorías y etiquetas, sino también con todos los metadatos que tengas en tu base de datos. Por ejemplo: la URL de la imagen destacada, el estado y tipo de cada post, la descripción y el título SEO si usas WordPress SEO o cualquier otro campo personalizado.

Ejemplo de cabecera Markdown para los artículos de HacheMuda. Ejemplo de cabecera Markdown para los artículos de Hachemuda.

Otra herramienta muy recomendada es ExitWP, un script escrito en Python también para migrar un sitio web basado en WordPress a Jekyll, generando todos los ficheros Markdown. O también puedes revisar WordPress to Markdown Exporter, de nuevo un script Python con el mismo objetivo y que acabo de descubrir haciendo una búsqueda sobre este tema.

Flujo de publicación

Al tener el sitio web estático y no disponer de un panel de administración web para publicar nuevos contenidos, hay que pensar bien el método a seguir para actualizar la web. Cuando se publica un nuevo artículo, hay que tener en cuenta que no sólo hay que subir ese artículo, sino también una actualización de los directorios de etiquetas, categorías, la portada, la paginación, el archivo del blog, etc. Muchas cosas quedan modificadas al publicar un nuevo post.

Idea #1: hosting normal y FTP

La primera opción y la más sencilla es la más evidente: publicas el nuevo artículo en local, generas el sitio web estático con los nuevos cambios y lo subes todo manualmente al servidor mediante un cliente de FTP.

Muchos clientes FTP tienen funciones avanzadas que pueden ayudarte. Por ejemplo, yo uso Transmit, que tiene una función de sincronización de carpetas. De este modo, Transmit analiza los directorios y ficheros que han sido modificados y los actualiza en el servidor, dejando los demás intactos.

Pantalla de la función de sincronización por FTP de Transmit. Pantalla de la función de sincronización por FTP de Transmit.

Sin duda es lo más sencillo, pero también bastante engorroso el tener que estar subiendo/sincronizando manualmente los archivos cada vez.

Idea #2: hosting normal, GIT y FTP Deploy

Una segunda opción que me gusta mucho es usar un sistema de control de versiones, como GIT, mantener un repositorio con todas ellas y poder hacer deploy fácilmente de la última versión de los archivos. Así no sólo es más sencillo el deploy del sitio al hacer cambios, sino que guardas una copia de seguridad continua y con versiones de todas las actualizaciones y cambios que publicas.

Para el deploy automático de un repositorio de GIT a un servidor FTP existen varios servicios. Yo los que he probado son BeanstalkApp y DeployHQ. Ambos funcionan realmente bien, pero añaden un coste mensual que quería evitar si era posible.

El primero, BeanstalkApp, integra ya un repositorio cloud con GIT y permite hacer deploys automáticos a otros servidores FTP, SFTP, Amazon S3, etc. Es una pasada y la opción que más me gusta si no te importa pagar los 15$ mensuales que cuesta el plan básico. Es ideal si tienes más de un sitio, pero para sólo uno sale un poco caro.

El segundo, DeployHQ, no tiene un repositorio GIT sino que sólo realiza el propio deploy a otro servidor. Por tanto, necesitas contratar por otro lado un repo privado, por ejemplo en GitHub, para que DeployHQ lo “lea” y haga un deploy cuando se envíe un nuevo commit. Al final saldría por el mismo precio que BeanstalkApp, aproximadamente.

Idea #3: Dropbox y Site44

Otra opción es usar un sistema de sincronización más simple entre tu entorno local y el servidor público, como Dropbox. Yo uso Dropbox a diario en mi trabajo, de hecho tengo prácticamente todo mi ordenador constantemente sincronizado con este servicio en la nube. Pero para alojar páginas públicas tiene muchas limitaciones y no es muy recomendable si es un proyecto medio serio. No es el objetivo de Dropbox.

Existen algunos servicios, como Site44 o Kissr, que ofrecen un plan de hosting básico en el que todos los archivos están permanentemente sincronizados con directorios de tu cuenta de Dropbox.

Esta es la idea con la que me he quedado de momento, y con la que estoy realmente contento hasta ahora. Con Dropbox como eje central de la sincronización y Site44 como hosting, que utiliza Amazon S3 internamente como servidor.

Este es el proceso que sigo para publicar un nuevo artículo:

  1. Edito el fichero del post y las imágenes a las carpetas correspondientes de mi instalación local de PieCrust. Compruebo que todo está bien desde el navegador mediante la función servidor de PieCrust.
  2. Una vez confirmado que todo está como yo quiero, llega el momento de la publicación online. Genero el sitio web estático con PieCrust, especificando que el directorio donde debe poner los ficheros es mi carpeta de Dropbox sincronizada con mi hosting en Site44. El comando tiene esta pinta:
chef bake -o /Users/guillermo/Dropbox/Aplicaciones/site44/www.hachemuda.com/

En cuestión de unos segundos o minutos (lo que tarde la sincronización de Dropbox con tu ancho de banda), ya está el nuevo post y el nuevo sitio online.

Puesta a punto y configuración de Site44

Site44 es súper sencillo: haces login con tu cuenta de Dropbox y creas tu primer sitio web especificando si quieres que sea tu propio dominio o un subdominio de site44.com.

Para usar tu propio dominio, tienes que modificar la configuración de los DNS. Lo malo es que Site44 no permite apuntar directamente el dominio raíz, solamente subdominios (www es un subdominio), de modo que tuve que redireccionar el raíz a www. El dominio y la tabla de registros DNS los gestiono directamente con CloudFlare y actualmente tengo esta configuración:

  • Un registro CNAME apuntando de www a domains.site44.com.
  • Un registro CNAME apuntando de @ a www.hachemuda.com.
  • Un PageRule de tipo redirección: de hachemuda.com a http://www.hachemuda.com
  • Otro PageRule de tipo redirección: de hachemuda.com/* a http://www.hachemuda.com/$1
Ejemplo de configuración de PageRules en Cloudflare. Ejemplo de configuración de PageRules en Cloudflare.

Una vez creas tu cuenta en Site44, cambias los DNS y añades tu dominio, automáticamente se te crea un directorio en tu carpeta de Dropbox llamado Aplicaciones/site44/www.midominio.com. Ese es el directorio sincronizado por el hosting y el único al que Site44 tiene acceso. Por defecto pone un fichero HTML básico que puedes probar a modificar y sincronizar para comprobar el buen funcionamiento, :)

Plantilla personalizada para errores 404

Una opción avanzada que permite Site44 y que no he conseguido saber si la permiten otros servicios de este tipo es la personalización de una página de error 404. Para publicarla, simplemente tienes que colocar un fichero 404.html en el directorio raíz de tu web. Ese fichero HTML será el que se muestre cuando haya un error.

Precios

Los precios de Site44 puedes consultarlos en la web:

  • Plan Gratuíto: límite de 5 sitios web y 100MB de transferencia al mes.
  • Plan Personal: 4.95$ mensuales por 10 sitios web y 10GB de transferencia.
  • Plan Profesional: 9.95$ mensuales por 50 sitios web y 50GB de transferencia.

Así que ya sabes, puedes darte de alta en el plan gratuíto para probar el sistema y después pasarte a uno superior.

Conclusión

Me encanta cómo tengo configurado ahora mismo el entorno de trabajo en Hachemuda. Puedo escribir artículos con cualquier editor Markdown, sin depender de nada más. PieCrust me permite previsualizar mi web en local cuando quiero hacer cualquier cambio. Para publicar simplemente tengo que generar el sitio con un comando y Dropbox se encarga de la sincronización entre mi entorno local y el entorno de producción, poniendo automáticamente online la última versión de la web.

¡Genial! ¿No crees? :)