Programar posts con Jekyll en GitHub Pages: el proceso completo
El primer problema “serio”, que me he encontrado con Jekyll, es que no podía programar los posts, crear un post con la fecha en futuro, no es suficiente para que se publique, también hay que hacer que se ejecute el build, ¿como?, simplemente modificando el archivo: | .github/workflows/pages-deploy.yml Y añadiendo esto:
on:
schedule:
- cron: '*/30 * * * *' # Runs every 30 minsCon esto, forzaremos un build cada media hora, que hará que ahora ya sí se publiquen los posts programados.
Configuración de _config.yml
En el archivo _config.yml existe una opción llamada future que controla si Jekyll debe publicar posts con fecha en el futuro:
future: false # ublicar posts con fecha futuraEl naming, es un poco … de aquella manera
Por defecto está en false, lo que significa que Jekyll ignorará los posts con fecha futura. Si lo cambias a true, Jekyll publicará esos posts automáticamente, pero ten en cuenta que esto puede causar problemas si tienes el workflow configurado para ejecutarse automáticamente.
Osea, si está en true, publicará todo, al momento, independientemente de la fecha que tenga el post.
Si lo pones en false, solo publicará los posts que tengan fecha en el pasado. Por tanto, podrás programar posts.
La configuración recomendada es mantener future: false y usar el workflow con schedule para publicar los posts automáticamente cuando llegue su fecha.
Otra opción (menos elegante), es forzar el rebuild, ejecutando un push vacío desde nuestro local, o donde sea:
git commit -m 'Force Rebuild' --allow-empty
git push origin <branch-name>Y ahora ya solo tendrás que escribir y hacer push de tus posts con fecha futura, y se publicarán automáticamente. Compártelo si te ha gustado. ¿Tienes dudas con la configuración? Escríbeme. Y… hasta aquí por hoy!
Artículos relacionados
Qué son los WebSockets y por qué no son HTTP más rápido
Casi todos los desarrolladores tratan los WebSockets como una versión un poco más rápida de HTTP. No lo son. Representan un cambio de fondo en la forma en que se comunican el navegador y el servidor. Imagina que estás escribiendo a un amigo, pero en vez de recibir su respuesta directamente, tienes que coger el móvil cada segundo y gritarle '¿ya has contestado? ¿ya has contestado?'. Suena de locos, ¿verdad? Pues así funciona la web tradicional: el cliente pregunta, el servidor responde y cuelgan. Para datos en vivo (un chat, una cotización, una notificación) eso es un desastre. Aquí te explico, sin tecnicismos, qué son los WebSockets, en qué se diferencian de verdad de HTTP y cuándo te interesa usarlos.
FutureLink: enlazar en Astro posts que aún no has publicado
Tengo el blog lleno de posts programados que se enlazan entre sí. Y eso, con un calendario editorial de por medio, tiene una trampa: cuando un post sale el martes y enlaza a otro que sale el jueves, durante dos días ese enlace apunta al vacío. Un 404 interno, justo lo que no quieres para SEO ni para el lector. Así que me hice un componente de Astro pequeñito, FutureLink, que comprueba en tiempo de build si el post destino ya está vivo: si lo está, pinta un enlace normal; si todavía no, pinta solo el texto, sin enlace y sin romper nada. Y como el sitio se reconstruye por cron cada pocos minutos, el enlace se activa solo en cuanto el destino se publica. Te cuento el problema, el código entero y por qué lo monté así.
⚡ Por qué deberías usar pnpm en vez de npm y migrar hoy mismo
Llevo años viendo discos llenos de carpetas node_modules clonadas mil veces y esperas eternas en cada npm install. pnpm resuelve las dos cosas: guarda cada dependencia una sola vez en disco y enlaza por hard links, instala en una fracción del tiempo y te protege de las phantom dependencies. Te cuento por qué deberías cambiarte, qué tiene de truco y cómo dejar que tu memoria muscular siga escribiendo npm con un alias que funciona en todos los sistemas operativos.