El error consistía en que muchos enlaces les faltaba una “/” en el ”path” de la url. Ejemplo: https://tarkil.dev/authorstarkil, en vez de https://tarkil.dev/authors/tarkil. No solo afectaba a las direcciones de los artículos, sino también a la carga de imágenes, javascripts y hojas de estilos.
Investigando un poco descubrí que el problema estaba relacionado con la variable site.baseurl a la hora de concatenar las urls. La solución aunque trivial, era un poco tediosa: reemplazar ciertas ocurrencias de site.url con relative_url. Un commit de ejemplo:
<link rel="stylesheet" type="text/css" href="/assets/built/screen.css" />
<link rel="stylesheet" type="text/css" href="/assets/built/screen.edited.css" />
Que habría que reemplazarlo por
<link rel="stylesheet" type="text/css" href="/assets/built/screen.css" />
<link rel="stylesheet" type="text/css" href="/assets/built/screen.edited.css" />
Desafortunadamente los enlaces a autores y tags seguían rotos. Tocaba investigar, otra vez. Por fortuna, esta vez la razón aparecía en la propia documentación del tema de Jekyll, jasper2: GitHub no soporta el uso de plugins de terceros por motivos de seguridad. Como solución se proponen las siguientes:
- Compilarlo en local y subirlo a GitHub. Esta opción no me gustaba, pues mi objetivo era poder olvidarme de tenerlo que compilar cada vez que haga un cambio.
- Hacer uso de Travis CI. Me parecía una buena idea, hasta que leí el tema de tener que versionar el token de git. En principio está cifrado y no debería de tener mayor problema, pero soy muy paranoico y preferí descartarlo. Seguramente acabe cometiendo alguna burrada más grande.
- La última opción que ofrecían era el uso de Netlify. A diferencia de Travis CI, Netlify no necesita “pushear” el resultado de la compilación a GitHub, pues lo aloja ella misma.
Tras el cambio a Netlify, creo haber arreglado todos los enlaces, o eso espero. En el siguiente artículo contaré cómo configuré Netlify con Jekyll y GitHub. Ya adelanto que fue tan fácil como seguir la guía que ofrecen.
