[🛠] Añadir calendario y estadísticas de actividad al sidebar del blog de GitHub Pages
✨ Resumen de GPT-5.5
Registro de cómo, justo después de reabrir el blog, añadí al sidebar un calendario de posts y estadísticas de actividad por categoría, incluyendo el mes del post actual y navegación por archivos mensuales.
Después de ordenar el post de reinicio del blog, el siguiente problema se vio de inmediato.
Había empezado a escribir posts otra vez. Pero todavía faltaba la sensación de que el blog hubiera vuelto a la vida. Con solo una lista de categorías, no se veía bien cuándo se movía el blog, qué días acumulaban registros o qué flujo reciente existía.
Para volver a escribir Daily Review, el sentido de las fechas importa.
Este blog, al final, se centra en “qué dejé en qué día”. Pero un blog de GitHub Pages no tiene una navegación por fechas que aparezca con naturalidad como en Naver Blog. Al ser un blog estático, tenía que construirla yo mismo.
Así que la función que añadí esta noche no era una simple decoración.
Era un trabajo para convertir el sidebar de un adorno auxiliar de la lista de posts en una herramienta de navegación que muestra fechas y flujo de actividad.
Lo primero que añadí fue un calendario pequeño y directo
El primer commit fue f6971fc.
f6971fc feat: add sidebar activity widgets
En ese momento creé dos archivos nuevos.
_includes/sidebar-calendar.html
_includes/sidebar-nav-stats.html
Añadí el include del calendario a sidebar.html.
{% include sidebar-calendar.html %}
El primer calendario se construyó solo con Liquid, sin JavaScript.
Desde site.posts excluí los posts ocultos y calculé el primer día de la semana y el último día del mes actual. Incluso el cálculo de febrero en años bisiestos se resolvió dentro de Liquid.
{% assign calendar_posts = site.posts | where_exp: "post", "post.hidden != true" %}
{% assign calendar_year = site.time | date: "%Y" %}
{% assign calendar_month = site.time | date: "%m" %}
Dentro del mes, las fechas con posts se convierten en enlaces, y las fechas sin posts quedan solo como números. La primera base era site.time. Es decir, en ese momento el calendario era un widget del sidebar que mostraba “el estado de posts del mes actual”.
Incluso con eso, el efecto apareció enseguida.
El blog empezó a sentirse vivo otra vez. A diferencia de una simple lista de títulos, un calendario muestra la densidad del registro. Se ve de un vistazo en qué días se concentraron posts, qué días quedaron vacíos y dónde está hoy.
También añadí información de actividad a las categorías
Si solo añadía el calendario, se veía el flujo por fechas, pero el flujo por categorías seguía apagado.
Así que también creé sidebar-nav-stats.html.
Este include interpreta la URL de cada elemento del sidebar como una ruta de categoría y vuelve a filtrar los posts que pertenecen a esa categoría.
{% assign stat_posts = site.posts | where_exp: "post", "post.hidden != true" %}
{% assign stat_categories = include.url | remove_first: "/" | split: "/" %}
Por ejemplo, si es /daily-review, muestra la cantidad de posts de la categoría daily-review; si es /diary/ai, deja solo los posts que incluyen tanto diary como ai.
La salida es simple.
Cantidad de posts · Fecha del post más reciente
Esto me gustó porque el sidebar dejó de ser una simple tabla de contenidos.
Se ve cuántos posts hay en Daily Review, cuándo se publicó el último post de IA y si GitHub Pages Blog está realmente en operación. Si un blog está muerto o vivo se nota mejor por la fecha más reciente que por la cantidad de posts.
Ajusté enseguida la densidad en móvil
En cuanto añadí el calendario, la densidad en móvil se volvió un problema.
El sidebar tiene espacio en escritorio, pero en móvil baja debajo del cuerpo o se mezcla con el menú. Si las celdas del calendario son grandes o las etiquetas de cantidad de posts son largas, un solo widget se come demasiada pantalla.
Por eso en 17d074d y b401d8b ajusté enseguida las etiquetas de actividad del sidebar y la densidad del calendario.
17d074d fix: tighten sidebar activity labels
b401d8b [Fix] | Sidebar calendar: Improve mobile density
En SCSS fijé las celdas de fecha con aspect-ratio: 1, usé fuentes más pequeñas y un radius de 4px. La información de actividad de categorías quedó pequeña para verse dentro de una línea.
Lo importante aquí era no convertir el calendario en protagonista.
El calendario es un dispositivo que ayuda a navegar el blog. No debe hacerse más grande que el cuerpo del texto. Sobre todo en un blog de registros, el sidebar debe dar información sin estorbar la lectura.
Lo cambié para usar el mes del post actual
Enseguida apareció un problema más importante.
Si el calendario se basa en site.time, entonces incluso al leer un post de 2025 aparece el calendario de mayo de 2026. Así el calendario no explica el contexto del post actual.
Por eso en ccb58d5 cambié la fecha base.
ccb58d5 [Fix] | Sidebar: Refine calendar behavior
La parte clave es esta.
{% assign calendar_source_date = site.time %}
{% if page.date %}
{% assign calendar_source_date = page.date %}
{% endif %}
Si la página tiene date, muestra el mes de esa fecha. En páginas sin fecha, sigue usando site.time.
Con esta modificación cambió el carácter del calendario.
El primer calendario era “el estado del blog este mes”. Ahora muestra “el tiempo en el que está ubicado el post que estoy leyendo”. Si leo una Daily Review antigua, puedo ver el flujo de registros de ese mes y encontrar también qué otros posts hubo en el mismo mes.
Eso encaja mucho mejor con un blog de registros centrado en fechas.
Los varios posts del mismo día se desplegaron como lista
En el mismo commit también añadí listas de posts por fecha.
Si en un día solo hay un post, está bien que el enlace de la fecha vaya directamente a ese post. Pero si hay varios posts en un día, aparece un problema. Solo en el primer día del reinicio ya había una Daily Review y un archivo de conversación con IA en la misma fecha.
Así que, cuando una fecha tiene varios posts, el enlace de la fecha no va directamente a un post. Se mueve a la lista de posts de ese día.
<section id="sidebar-calendar-2026-05-25-posts" class="sidebar-calendar__post-list">
<h4 class="sidebar-calendar__post-list-title">Posts del 25 de mayo</h4>
<ul>
...
</ul>
</section>
La regla en ese momento era simple.
1 post: ir a ese post
2 o más posts: ir a la lista de posts de esa fecha
No era una regla perfecta, sino una forma de resolver ahora mismo el problema de varios posts en la misma fecha. Aun así, lo importante es que el sistema no escondió el problema.
El sistema tiene que reconocer que en una sola fecha puede haber varios posts. Si en un blog pueden salir el mismo día Daily Review, conversaciones con IA y registros de desarrollo, este tratamiento hace falta.
También añadí una mejora con JavaScript
Solo con el calendario en Liquid se puede navegar alrededor del mes actual, pero moverse entre meses es incómodo.
Así que en b06b6d6 añadí JavaScript.
b06b6d6 [Feat] | Sidebar calendar: Add archive navigation
El archivo nuevo fue este.
assets/js/custom/sidebar-calendar.js
Y lo registré en after_footer_scripts de _config.yml.
after_footer_scripts:
- /assets/js/custom/dark-theme.js
- /assets/js/custom/sidebar-calendar.js
Desde Liquid bajé los datos de posts como JSON.
<script type="application/json" data-calendar-posts>
[
{
"title": "...",
"url": "...",
"date": "2026-05-25"
}
]
</script>
JavaScript lee esos datos y construye postsByDate, postCountByMonth, postCountByYear y latestPostMonthByYear. Después renderiza botones de mes anterior/siguiente, un input de mes, botones de cantidad de posts por año/mes y listas dinámicas de posts por fecha.
Esta estructura me pareció buena porque no abandonaba el fallback.
Si JavaScript está disponible, moverse por meses y navegar el archivo se vuelve cómodo. Aunque no haya JavaScript, Liquid ya renderiza el mes del post actual y la lista fallback para fechas con varios posts.
Ese equilibrio importa en un blog estático.
Qué cambió hoy
El flujo desde esta noche hasta la madrugada fue este.
f6971fc Añadí calendario al sidebar y estadísticas de actividad por categoría
17d074d Ajusté la densidad de las etiquetas de actividad del sidebar
b401d8b Ajusté la densidad del calendario en móvil
ccb58d5 Gestioné el mes del post actual y las fechas con varios posts
b06b6d6 Añadí una mejora JavaScript para navegación por archivos mensuales
Los archivos centrales son estos.
_includes/sidebar.html
_includes/sidebar-calendar.html
_includes/sidebar-nav-stats.html
assets/js/custom/sidebar-calendar.js
_sass/custom/customOverride.scss
_config.yml
En una frase:
Añadí al sidebar del blog una capa de navegación que muestra fechas y flujo de actividad por categoría.
Resultado
Ahora el sidebar del blog ya no es una simple lista de categorías.
Muestra el mes al que pertenece el post actual, marca las fechas con posts y despliega como lista las fechas que tienen varios posts. Los elementos de categoría muestran cantidad de posts y fecha del post más reciente. Si JavaScript está activado, se puede recorrer el archivo del blog moviéndose entre años y meses.
Desde la perspectiva de portafolio, el punto de este trabajo está en haber mejorado la navegabilidad sin servidor.
No hay DB aparte ni API. Con site.posts de Jekyll, Liquid, SCSS y un pequeño JavaScript, tapé un punto débil del blog estático. Los registros tienen fechas. Cuando esas fechas aparecen en la UI, el blog deja de verse como un montón de posts y empieza a parecer un sistema que se mueve en orden temporal.
El calendario que añadí hoy es el comienzo de eso.
Deja un comentario