[🛠] Adding a Calendar and Activity Stats to the GitHub Pages Blog Sidebar

✨ GPT-5.5 Summary 　

A record of adding a post calendar and category activity stats to the sidebar right after reopening the blog, including current-post month behavior and monthly archive navigation.

After organizing the blog restart post, the next problem became visible immediately.

I had started writing posts again. But the blog still did not quite feel alive again. A category list alone did not clearly show when the blog moved, which days had records, or what recent flow existed.

To write Daily Review again, a sense of dates matters.

This blog is ultimately centered on “what I left behind on which day.” But a GitHub Pages blog does not naturally have date navigation like Naver Blog. Since it is a static blog, I had to build it myself.

So the feature I added tonight was not just decoration.

It was a task to turn the sidebar from a supporting decoration for post lists into a navigation tool that shows dates and activity flow.

The First Thing I Added Was a Small, Direct Calendar

The first commit was f6971fc.

f6971fc  feat: add sidebar activity widgets

At that point, I created two new files.

_includes/sidebar-calendar.html
_includes/sidebar-nav-stats.html

I added the calendar include to sidebar.html.

{% include sidebar-calendar.html %}

The first calendar was built only with Liquid, without JavaScript.

It filtered hidden posts out of site.posts, then calculated the first weekday and last day of the current month. Even leap-year handling for February was processed inside 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" %}

Within the month, dates with posts become links, and dates without posts remain numbers. The initial base was site.time. In other words, at this stage the calendar was a sidebar widget showing “the current month’s post status.”

Even this much had an immediate effect.

The blog started to feel alive again. Unlike a plain title list, a calendar shows the density of records. You can see at a glance which days were crowded with posts, which days were empty, and where today is.

I Added Activity Information to Categories Too

If I added only the calendar, date flow became visible, but category flow still felt dull.

So I created sidebar-nav-stats.html as well.

This include treats each sidebar item’s URL as a category path and filters posts belonging to that category.

{% assign stat_posts = site.posts | where_exp: "post", "post.hidden != true" %}
{% assign stat_categories = include.url | remove_first: "/" | split: "/" %}

For example, /daily-review shows the count of posts in the daily-review category, and /diary/ai leaves only posts that contain both diary and ai.

The output is simple.

Post count · Latest post date

I liked this because the sidebar became more than a simple table of contents.

It shows how many Daily Review posts there are, when the latest AI post went up, and whether GitHub Pages Blog is actually active. Whether a blog is alive or dead is often clearer from the latest date than from the post count.

I Immediately Adjusted Mobile Density

As soon as I added the calendar, mobile density became a problem.

The sidebar has space on desktop, but on mobile it moves below the body or mixes with the menu. If calendar cells are large or post-count labels are long, one widget takes up too much screen space.

So in 17d074d and b401d8b, I immediately tightened the sidebar activity labels and calendar density.

17d074d  fix: tighten sidebar activity labels
b401d8b  [Fix] | Sidebar calendar: Improve mobile density

In SCSS, I fixed date cells with aspect-ratio: 1, used smaller font sizes, and used a 4px radius. Category activity information was made small enough to fit on one line.

The important thing here was not to make the calendar the main character.

The calendar is a device that helps blog navigation. It should not become larger than the body content. Especially in a record blog, the sidebar should provide information without interfering with reading.

I Changed It to Use the Current Post’s Month

A more important problem appeared right away.

If the calendar is based on site.time, then even while reading a 2025 post, the calendar shows May 2026. In that case, the calendar cannot explain the context of the current post.

So in ccb58d5, I changed the base date.

ccb58d5  [Fix] | Sidebar: Refine calendar behavior

The key part is this:

{% assign calendar_source_date = site.time %}
{% if page.date %}
  {% assign calendar_source_date = page.date %}
{% endif %}

If the page has a date, it shows the month of that date. On pages without a date, it still uses site.time.

This changed the character of the calendar.

The first calendar showed “this month’s blog status.” Now it shows “the time where the current post is located.” If I read an old Daily Review, I can see the record flow for that month and find what else existed in the same month.

That fits a date-centered record blog much better.

Multiple Posts on the Same Day Became a List

In the same commit, I also added per-date post lists.

If there is only one post in a day, sending the date link directly to that post is fine. But if there are multiple posts in a day, a problem appears. Even on the first restart day, Daily Review and the AI conversation archive existed on the same date.

So when a date has multiple posts, the date link does not go directly to a post. It moves to that date’s post list.

<section id="sidebar-calendar-2026-05-25-posts" class="sidebar-calendar__post-list">
  <h4 class="sidebar-calendar__post-list-title">May 25 posts</h4>
  <ul>
    ...
  </ul>
</section>

The rule at this stage was simple.

1 post: go to that post
2 or more posts: go to the list of posts for that date

It is less a perfect rule than a way to solve the immediate same-date multiple-post problem. Still, the important thing is that the system does not hide the problem.

The system has to acknowledge that a single date can have multiple posts. If a blog can publish Daily Review, AI conversations, and development records on the same day, this handling is needed.

I Added JavaScript Enhancement Too

With only the Liquid calendar, current-month navigation is possible, but moving across months is inconvenient.

So in b06b6d6, I added JavaScript.

b06b6d6  [Feat] | Sidebar calendar: Add archive navigation

The new file is this:

assets/js/custom/sidebar-calendar.js

And I registered it in _config.yml under after_footer_scripts.

after_footer_scripts:
  - /assets/js/custom/dark-theme.js
  - /assets/js/custom/sidebar-calendar.js

The Liquid side sends post data down as JSON.

<script type="application/json" data-calendar-posts>
[
  {
    "title": "...",
    "url": "...",
    "date": "2026-05-25"
  }
]
</script>

JavaScript reads this data and builds postsByDate, postCountByMonth, postCountByYear, and latestPostMonthByYear. Then it renders previous/next month buttons, a month input, year/month post-count buttons, and dynamic post lists by date.

I liked this structure because it did not abandon the fallback.

If JavaScript is available, month movement and archive navigation become convenient. Even without JavaScript, Liquid already renders the current-post month and the fallback list for dates with multiple posts.

This balance matters in a static blog.

What Changed Today

The flow from tonight into dawn looked like this.

f6971fc  Added sidebar calendar and category activity stats
17d074d  Tightened sidebar activity label density
b401d8b  Adjusted mobile calendar density
ccb58d5  Handled current-post month and multi-post dates
b06b6d6  Added JavaScript enhancement for monthly archive navigation

The core files are these:

_includes/sidebar.html
_includes/sidebar-calendar.html
_includes/sidebar-nav-stats.html
assets/js/custom/sidebar-calendar.js
_sass/custom/customOverride.scss
_config.yml

In one sentence:

I added a navigation layer to the blog sidebar that shows date and category activity flow.

Result

The blog sidebar is no longer just a category list.

It shows the month the current post belongs to, marks dates with posts, and expands multiple posts on the same date into a list. Category entries show post counts and latest post dates. If JavaScript is enabled, I can move across years and months to browse the blog archive.

From a portfolio perspective, the point of this work is that I improved navigation without a server.

There is no separate DB and no API. With Jekyll’s site.posts, Liquid, SCSS, and a small piece of JavaScript, I filled a weak point in the static blog. Records have dates. When those dates appear in the UI, the blog looks less like a pile of posts and more like a system moving through time.

The calendar I added today is the start of that.