原因

其实不管是使用 Hugo 还是 WordPress，对于我来说一个写博客的程序都是为了自己能多记录，勤记录。通过阅读以前的文章，我发现自己花了很多时间来折腾博客本身，通过这些折腾，有意无意地让我这个博客差不多也更新了近 10 年，这一次折腾当然也是为了鼓励自己能接着把博客写下去。

为什么是 WordPress，我知道很多人尤其是年轻人对于这个老古董的 PHP 程序可能嗤之以鼻，我曾经也一样，但这几年下来我渐渐感觉一件事情能坚持很多年本身就是值得尊重的，而在博客界占有压倒性地位的就是 WordPress，无数人为了让写博客这件事变得容易花费了很多精力。并不说 Hugo 不好，只是不得不说同样编辑、发表一篇文章而言，所见即所得以及图形化界面的 WordPress 要容易很多。或许单纯因为我变老了，时间变少了才做出这一决定也说不准，但要说 10 年之后依然存在的博客程序是什么，我想 WordPress 可能依然是不可取代的一部分。

虽然放弃 Hugo 有一种推翻过去 10 年自己做法的艰难感觉，但是为了能在接下来的 10 年继续更容易地更新博客，现在做出这个转变又何尝不是一个好的决定呢？

你好 WordPress

实际上在去年写介绍我最近做的新网站「日语迷.com」的时候我就已经在这个新的网站上使用上了 WordPress 也是因为这一年下来感觉 WordPress 其实让很多事情变得简单。比如说使用 WordPress 你可以不需要烦恼使用什么评论系统，可以接入邮箱与读者交流，可以很快速地修改文章内容。另外，不需要考虑怎么编译部署博客，一个 Web Server 加一个数据库就转起来的这种感觉是我最熟悉的。这些都是 WordPress 吸引我的原因，它丰富的主题和插件系统对于我来说其实并没有太大的吸引力。

谢谢 Hugo

过去这么多年由 Hugo 编译的我的博客从今天起就告一段落了，过去我也多次尝试自己写过 Hugo 主题，甚至给上游提交过 Bug 报告。这么多年基本一直使用着最新版的程序编译自己的博客，虽然时不时有一些小问题发生，但总体上都是非常稳定的。在这里对 Hugo 以及它背后的开发者说一声感谢。

最后，按照惯例在博客主题更新或者像是这次连背后的程序都改了的情况下贴上上一代博客的留念截图。

最后

如果有读者好奇我是怎么做的从 Hugo 到 WordPress 的迁移。虽然这听起来很蠢，但我就是从老博客一篇一篇复制 HTML 粘贴到 WordPress 的编辑器里然后替换掉媒体文件，手动把 110 篇文章给搬了过来，顺便借此机会读一读之前写的文章。接下来可能考虑把 Disqus 上的评论给想办法搬过来，就以后花点儿时间看看能不能写个脚本吧。当然啦，欢迎你来本文下方体验 WordPress 原生自带的评论功能。

这还不够，这周又花了点时间给博客的头部和分享图前也加上这个新头像。

在博客头部显示头像

新旧博客头部的对比如上，如果你也是 Google One 会员的话，你可能留意到我偷了下会员专享的那个彩色圈圈，套在了博客头部的头像上。

在博客分享图显示头像

分享图的话除了加上了头像，也趁机改了改之前旧的域名，也换上了一个较为圆润的字体叫做源泉圓體

检测 HTML 是否合理的动态徽章

因为期间修改了博客的一些 HTML 结构，一般新的改动上线后我会手动检测一下新的 HTML 是否合理，结果还真出了一些问题，现在已经修复。

之前在页面最下方有一个静态图标，点击这个图标就可以一键打开检测网站直接查看检测结果，这次更进一步通过利用 Shields.io 可以在图标上动态显示检验结果，像是这样：，如果 HTML 有问题这个图标会自动显示错误数量。

当然了，没有任何绘画天赋的我是不可能凭空画出什么来的，灵机一动想到了去日本这里的技能交易平台ココナラ找人画一张。因为要求简单，加上有新人优惠，一共花费 1283 日元就有了我现在新的头像。话不多说，下面就请欣赏我的新头像。

我的新头像

与画师的沟通

为了和画师沟通我要什么样的照片，我简单描述了下：

1. 图片为鸡的全身照
2. 样子比照星露谷物语里鸡的形象（附上截图一张）
3. 结构保持简单，最好在小尺寸屏幕上也容易分辨出是一只鸡

过了一会儿，画师收到消息表示感谢后马上回我：

1. 成果是 2000x2000px 的图片可以吗？还是特意需要分辨率小的
2. 以及鸡需要是正面照还是侧面照

我跟她说照最大分辨率出图就可以我可以自己调整，鸡要侧面照。然后很快就收到了草图，不过她跟我抱歉说没有画像素画的技术，给了一张她作品集里风格的草图，问我有没有问题，没有问题就可以接下来的涂色环节了。我看了下除了鸡脚有点粗之外没有太大问题，就让她修改了。之后双方确认后就上色了。

最后的成品是透明背景的 png 图，问我要不要加背景颜色，我说你看着自己的喜好加吧。其实主要是我也不知道加什么好，于是她给我绿色、蓝色、粉色和水蓝四种背景的图片。在我确认完后，双方互评结束了本次交易。以下是交易账单的详情。

自己的再创作

后来我想到其实背景可以用 ImageMagick 自己加，于是就去 Tailwind CSS 偷了它们的配色版，按照白、绿、蓝、紫、橙、金这样稀有度排序生成了下面这带不同背景的头像图片，虽然平时基本还是用白色背景居多。

最后

不知道各位对于我的新头像有什么看法。

如果你也想去那个网站平台找人画头像你甚至可以使用我的邀请链接 https://coconala.com/invite/KNHHG3 据说能得到 1000 日元的点券（不知道能不能直接用，未经证实）日本海外的用户似乎也可以用 PayPal 支付，只是交流上可能还是需要日语。

而在今天要使用的 Hugo 组件又把它叫作 Notice

hugo-notice 功能展示

总而言之，说了这么多其实这个功能非常常见，大概就是长下面这些样子：

突然感觉我这个朴素的博客文章样式一下子鲜艳起来了。而且，这个 hugo-notice 组件在日间模式和夜间模式下还使用了不同的配色，完成度很高，这也是我直接拿来主义懒得自己从头写的一个原因。

使用 hugo-notice

看文档有两种使用方法，一是用 Hugo module，另一种是当作 Hugo 的主题放到 themes 目录下。我个人没有用过 Hugo module，就用最简单直接的方法——当作主题导入使用它提供的 shortcode。

1. 把 hugo-notice 当作一个 git submodule 放到 themes 目录下

git submodule add https://github.com/martignoni/hugo-notice.git themes/hugo-notice

2. 把 hugo-notice 加到 Hugo 配置文件中 theme 选项的列表中的最左边。比如我的配置像是这样：

theme = ["hugo-notice", "futu"]

3. 完成了上面两步，基本上就可以使用 hugo-notice 提供的 shortcode 了，基本用法如下：

{{< notice info >}}
这是一条信息。
{{< /notice >}}

除了 info，还提供了 warning、note 以及 tip 这几种不同的样式可供使用。

微调 hugo-notice（可选）

完成上面的步骤如果你没遇到什么问题，基本上这里的微调并不需要。但如果你本身使用的主题使用的多语言功能不被 hugo-notice 支持，又或者你使用的主题支持的夜间模式不是在 body 标签的 class 属性里加入 dark，你可能需要稍微调整一下相关的代码。比如我这个博客的语言使用了 zh-Hans 以及夜间模式我是在 html 标签的 class 里加入 dark-mode。于是我就 fork 了原来的仓库，在此基础上做了些许修改使它可以与我的博客主题相兼容。感兴趣的话可以查看 yuanji-dev/hugo-notice@6ff5846 这个 commit。

快速输入 shortcode 的代码片段（可选）

为了让 Hugo 的 shortcode 在编辑器里用得更容易，我通常会制作一些代码片段（snippet）。虽然我使用 Neovim 的插件来输入这个代码片段，但理论上 VS Code 或者支持 VS Code 代码片段格式的编辑器应该也能用。这样在编辑器输入 h-notice 就可以快速输入这个 shortcode 了。

{
  "Hugo notice shortcode": {
    "prefix": "h-notice",
    "body": ["{{< notice ${1|warning,info,note,tip|} >}}", "${0}", "{{< /notice >}}"],
    "description": "Add notice box to document"
  }
}

最后

本来在写另一篇博客，当时想加入一些提示的话，才发现现在的主题还没有这个功能。结果就花时间找到了 hugo-notice 这个组件，以及又花了点时间写了这篇博客，导致原本在写的那篇博客却被耽搁了。感觉这样的事情经常出现，甚至已经渐渐习惯为了做某件事情，却被做那件事情的途中产生的支线剧情而支配做完了另一件看似毫不相关的事情。（这样的情况，想必读我博客的读者应该不难理解，对吗？）

被阅读最多的文章

按照惯例，我下载了 Umami 上统计的信息，使用去年写的 Hugo 的 shortcode 渲染出 2024 年博客文章访问前 10 名大概是这样：

今年给那个 shortcode 加了个新功能，可以显示文章的发布日期，可以看到 2024 年写的文章里共有 3 篇文章上榜。

回顾和展望

回顾去年一年写的博客，感觉最大的变化是换上了新的域名 blog.yuanji.dev，一个原因是为了和博客的标题保持统一，另外也是因为夏天的时候做了一个新的网站，想着在日本的生活渐渐稳定下来，准备在那个网站专门用来分享一些日语学习、日本生活的文章。（虽然目前也停更几个月了 😂）

至于 2025 年，这个博客就主要分享一些技术相关的记录和一些随笔吧！

分享到哪？

首先摆在面前的一个问题是，我希望把文章都分享到哪？稍微参考了一下一些平时浏览的网站，我大致列出了下面几个，简单附加了我个人对这些网站的看法：

• X（Twitter）：我目前（2024 年 1 月）浏览最多的社交网络
• Telegram：我目前（同上）使用最多的通讯软件
• 豆瓣：我之前最活跃使用的社交网络，目前半隐退中
• Reddit：打发时间的好帮手，潜水 10 年以上
• Facebook：虽然自己不用，但谈到社交网络就不得不说起的存在
• Pocket：似乎是稍后阅读类最知名软件
• 电子邮件：为了本格互联网使用者

分享按钮的实现方法

调查了一些现有网站上的实现方法，发现大体上有两大类：

1. 使用现成的服务，好处是非常方便，只需要引入一个 JavaScript 脚本，然后在需要的地方添加一个 div 元素即可。目前常见的还在提供服务的有：
   • ShareThis: Digital Behavioral Data Solutions | Global & Real-Time
   • AddToAny: Share Buttons by the Universal Sharing Platform
2. 完全不使用 JavaScript，每个分享按钮就是一个可点击的图标链接。虽然从使用者的角度不如上面简单，但是只要稍微有一些 Hugo 模板和 CSS 的知识，再加上下面这个脚手架网站，自己做一个也并非难事。
   • Social Media Sharing Buttons. No JavaScript. No tracking. Super fast and easy.

纯 HTML + CSS 实现分享按钮

本着让本博客最大限度不依赖于 JavaScript 就能使用大部分功能的宗旨，我当然选择了第二个方法。通过 https://sharingbuttons.io 生成了一个基本的 HTML 骨架和一个能用的 CSS 之后，魔改之路就开始了。

主要的更改大概是下面几个：

1. 替换最新的图标和配色，最显然的 Twiiter 已经改成 X，Facebook 和 Reddit 等也都有细微改动，通过 Simple Icons 可以获得各种品牌最新 Logo 的 SVG 和配色。
2. 添加缺失的服务，比如豆瓣和 Pocket，除了需要跟上面一样获得 Logo 和配色之外，还需要构造分享的 URL，比如豆瓣的像是这样：https://www.douban.com/share/service/?href={{ .Permalink }}&name={{ .Title }}，各家虽然名称不尽相同，但基本都是需要提供链接和一个可选的标题就行。
3. 最后可选的一步就是清理一下最初生成的 HTML 和 CSS，我甚至把 CSS 转写成了 SCSS 以保持本博客主题样式的一贯性。

代码虽然不复杂但是稍微有点冗长，感兴趣的朋友可以直接参考 feat: add share buttons for post · yuanji-dev/futu@1ce5993 主题仓库里这个 commit。其实也许可以做得更灵活一些，比如支持在 Hugo 可以按需配置生成分享按钮，不过目前的功能已经够我自已用了。

在 Hugo 中启用分享按钮

在 Hugo 主题里添加了这个分享按钮的功能后，使用起来就很简单了，就像博客的其他一些非主要的功能（比如显示目录、显示相关文章）一样，我提供了相同的启用逻辑：

1. 如果需要全局所有文章启用分享按钮，就在配置文件（比如 config.toml）里设置 enableShare 为 true 。
2. 如果只需要部分页面启用分享按钮，那就在那些文章的 front matter 里设置 enableShare 为 true。
3. 同样地，如果需要在特定页面禁用分享按钮，就在那些文章的 front matter 里设置 enableShare 为 false 。

最后

通过差不多一下午的努力，给自己的博客加上了社交属性。虽然不知道多少人会使用，但是不管怎么说从我的角度当然希望自己的文章能被更多的人读到，所以读者朋友们，请毫不犹豫地使用这些分享按钮，分享你觉得有意思的文章给亲朋好友吧！

对于那些不使用 Hugo 的朋友，如果也想给自己的网站加上类似的功能，我做了一个单 HTML 文件的 demo，也许你可以直接拿它改一改加到自己的网站。

被认证的博客

之前单纯觉得有趣，给自己的博客加上了类似 X（Twitter）上的认证标识，一转眼一年多过去了。前几天试着用 Google 搜索了一下自己的博客，没想到还在试运行的 Google 生成 AI（Bard）对我的博客似乎非常了解，在它看来我的博客是通过认证了😂。另外，看起来它已经收录了我最新的博客文章，还擅自（褒义）把一些文章的标题翻译成了日文，看起来似乎是个很勤快的 AI 呢。

被阅读最多的文章

另一个值得一提的是，2023 年年初给博客加了一个自建的统计功能以来，现在一年过去也积累了一些数据。其中最有价值的信息大概是哪些文章的访问量最大，我把前十名列在了下面：

另外一些有关访客来源、操作系统、地区分布等的信息我也放在这里，感兴趣的读者朋友可以自行阅读。

也许你会好奇上面表格里这么多数字我都是自己一个个打字上去的吗？当然不是，为此我专门做了一个叫做 json2table 的 Hugo Shortcodes，可以通过它直接把网站统计的 JSON 数据渲染成表格，之后可能会单独写一篇文章介绍一下。

回顾和展望

虽然断断续续，但我还是很庆幸 2023 年还在写博客，本文应该是第 90 篇。写着写着也算是写出了一些自己的风格，我自己总结如下：

• 博客从主题到写作环境基本稳定下来（基于自己写的 Hugo 主题，用 AstroNvim 书写 Markdown）
• 博客的内容之间不再那么孤立，文章之间开始出现联系（甚至可以开始写本文这样总结型的文章了）
• 博客有了一些固定的访问量（目前差不多日均 50 人，100 多浏览量，新文章发布日大概 2 倍）

通过上面这些观察，我估计在新的 2024 年会开始做一些小的改进，目前想到的有：

• 更新目前一些访问量大的文章或是出续集（上面访问量 Top 10 里的文章好几篇都是几年前写的了）
• 博客文章的主旨尽量明确，每一篇文章尽量只关注一个主题展开
• 给文章增加鼓励分享的按钮（方便自己以及读者可以分享到社交网络等）
• 尝试翻译一些文章到英文和日文（看到 Bard 已经主动用日文介绍我的博客而受到启发）

当然了，不管怎么说，最重要的还是再接再厉继续写下去。

这篇文章就作为上一篇的后续，介绍一下我观察到的日本的节日、日本月历有关的有意思的发现，然后顺便将这些观察反映到我博客的月历上。

👉 点击查看日历预览效果

红日子

作为一个来日本工作的社会人而言，不用说最先关心的几件事之一就是节假日。听职场上的中国人前辈们经常用「红日子」来指代周末和放假的节日。我在网上搜了下，确实也有日本人把这些节假日称为赤日(あかび)，但我在字典中并没有找到，字典里有的词叫「旗日(はたび)」，据说这些节日的时候会升旗庆祝。但不管怎么说把节假日称为红日子还是很形象的，因为在日本的月历确实节假日是印刷成红色的。据说这甚至影响了 iOS 系统的日历图标，将系统的区域设置成日本后，在非节假日的时候图标上的文字是普通的黑色，而只有节假日会变成红色。在日本亚马逊(amazon.co.jp)搜索カレンダー(Calendar)的结果也很清晰地反映出，日本月历配色的特点。（读者朋友要是愿意可以上美国亚马逊(amazon.com)搜索 Calendar 试试，这个区别还是一目了然的）

星期六是蓝色的

看了上面的截图，你可能也注意到，土曜日(星期六)的颜色区别于日曜日(星期日)的红色，竟然是蓝色的。通过一番调查，发现这篇こよみの学校 第115回『土日の色はいろいろ』｜暦生活文章解释地非常清楚。简单来说星期六使用不同的颜色和上世纪 70 年代日本开始推行周休两天制度有关系，但使用蓝色大概和印刷技术有关系，因为印刷原色黄、红、蓝、黑四种颜色，而红和黑已经被使用，剩下黄色和蓝色二选一的话，因为黄色不够醒目，自然就有蓝色来当此大任了。

顺便说一句，不知道是不是这个周休两天制度落实得不够彻底，直到今天，在日本如果某个节日和星期日重合的话，之后最近的一个非节日的日子（通常就是星期一啦）会补假。然而如果节日和星期六重合，法律并没有提到会补假。2023 年非常不幸，竟然有 3 个节日和星期六重合。

Hugo 处理数据

铺垫了这么多背景，终于到了改造我博客日历功能的时候了，简单总结一下我要做的：

• 按照传统，把日历里的星期六的颜色设置成蓝色
• 在日历中加入节日信息（因为 2019 年年底来的日本，我决定把 2020 年开始的日本节日放上去）

把星期六的颜色改成绿色，只需简单一句 CSS 即可，就不细说了。这里主要介绍一下如何在日历上放上节日信息。首先要做的就是去政府网站找到准确的节日信息，这个网页很清楚的列出了今明两年的节日信息，顺便附带了一个 CSV 文件，包含从 1955 年开始的所有节日。虽然 Hugo 也可以处理 CSV，但显然比起 JSON、YAML 或是 TOML 格式而言处理起来并没有那么友好。不过好在已经有其他人考虑到了这一点，国民の祝日API 这个网站直接提供了简单的 API 可以获取到 JSON 格式的节日信息。虽然我们可以直接使用 data.GetJSON 这个方法让 Hugo 编译博客的时候，从远端下载必要的 JSON 文件，不过考虑到我们只需要每年更新一次节日信息，我选择把从 2020 年开始的 JSON 文件放到了我的博客仓库，减少一个不必要的外部依赖。比如 https://api.national-holidays.jp/2024 通过访问这个地址就可以得到 2024 年的节日信息，将其保存为 2024.json 放到 data/calendar/holidays_jp 目录下，所有下载的文件像是这样：

❯ ls -alh data/calendar/holidays_jp
Permissions Size User   Date Modified Name
.rw-r--r--  1.4k yuanji 25 Dec 18:55  2020.json
.rw-r--r--  1.4k yuanji 25 Dec 18:56  2021.json
.rw-r--r--  1.3k yuanji 25 Dec 18:56  2022.json
.rw-r--r--  1.4k yuanji 25 Dec 18:56  2023.json
.rw-r--r--  1.7k yuanji 22 Dec 23:16  2024.json

根据 Data templates | Hugo 文档，只要把这些数据文件放到 data 目录下，就可以在模板中通过 $.Site.Data 访问，比如我在模板里使用了如下代码：

{{- range $.Site.Data.calendar.holidays_jp -}}
  {{ range . }}
    {{- $holidayEvents = $holidayEvents | append (dict "title" .name "start" (time.Format "2006-01-02" .date) "allDay" true "color" "red" "kind" "holidays_jp" ) }}
  {{ end }}
{{- end -}}

因为 holidays_jp 是一个目录，$.Site.Data.calendar.holidays_jp 就会得到以该目录下文件名为 Key，文件内容为 Value 的 map 了，虽然有点儿怪，但是直接 range 这个 $.Site.Data.calendar.holidays_jp map 会遍历所有 Value（某一年的节日内容）而不是 Key，再 range . 一下就得到每一条节日信息了。

FullCalendar 渲染数据

原理上和上一篇渲染博客文章信息到月历上并没有太大的不同，只是我做了一点小小的重构，比起把所有信息放到一个 $events 对象里，我试着做了下区分，分为了三个不同的对象，用来分别存储已发布文章、草稿，以及今天的主角——节日。

- events: {{ $events }},
+ eventSources: [{{ $postEvents }}, {{ $draftEvents }}, {{ $holidayEvents }}],

总结

本来上一篇文章就是今年最后一篇了，本文对于月历的更新部分在那篇文章里增补即可。但那样的话就失去了一个介绍日本节日、月历配色等有趣地方的机会了。

另外想到今年好几个之前的同事、同学来日本玩，网上也读到不少来日本游玩的游记，想必来年还会有更多的游客来日本旅游，或许有一篇有关日本节日的文章可以帮助想来日本旅游的朋友做计划也不一定。

最后，提前祝各位读者朋友新年快乐！

最早的契机来自身边的书店、超市等，推出了很多月历相关的商品。无意识地感觉到月历这个东西一下子存在感高了起来。另外，可能国内没有这样的习俗，似乎日本在进入 12 月之后，会有一个叫做 Advent Calendar 的企划活动，尤其在网络上的技术社区。大体上，这个活动从 12 月的第一天开始，直到圣诞节结束，参加活动的每个人分别负责其中一天，写一篇与某个特定主题相关的文章，比如下面这些：

• Obsidian Advent Calendar 2023 – Adventar
• 語学・言語学・言語創作 Advent Calendar 2023 – Adventar

于是我就想，何不给我自己的博客也加上个月历呢，一方面可以观察一下我过去都在什么时候写博客，另一方面也许有了这么个月历，可以更好地激励我写更多的博客文章呢？

使用 FullCalendar

就像去实体店里买月历一样，要给博客做一个月历功能，我首先想到的去挑选一个现成的。虽然似乎没有看到哪个 Hugo 主题标榜自己有这么个月历功能，不过果然我也不是第一个有这个想法的人，网上已经有一些类似功能的讨论，通过一番研究比较，我选择了一个基于 JavaScript 的日历库 FullCalendar。

虽然这个库提供各种各样丰富的功能，实际上我需要的仅仅是展示一个基本月历而已。所以使用起来并不是太复杂，基本上直接复制下方的官网示例代码，原型就差不多了。

<!doctype html>
<html lang="en">
  <head>
    <meta charset="utf-8" />
    <script src="https://cdn.jsdelivr.net/npm/fullcalendar@6.1.10/index.global.min.js"></script>
    <script>
      document.addEventListener("DOMContentLoaded", function () {
        var calendarEl = document.getElementById("calendar");
        var calendar = new FullCalendar.Calendar(calendarEl, {
          initialView: "dayGridMonth",
          events: [],
        });
        calendar.render();
      });
    </script>
  </head>
  <body>
    <div id="calendar"></div>
  </body>
</html>

然后只要想办法往上面示例代码中高亮的 events 里填入实际的数据即可，在我的博客里自然就是博客文章了。

Hugo 布局文件

有了上面使用 FullCalendar 的代码原型后，紧接着产生两个疑问：

1. 这个显示月历的代码应该放在哪？
2. 应该怎样使用（调用）这个月历？

因为我之前以前已经有较为丰富的 Hugo 主题开发经验，要回答这两个问题并非什么难事。

1. 在 Hugo 博客的目录下创建一个布局文件 layouts/_default/calendar.html
2. 在 Hugo 博客的内容目录下随便创建一个 .md 文件，只需要在 front matter 里加入 layout: calendar 即可。比如我想在 /calendar 访问月历，就创建一个 content/calendar/_index.md 这样的文件就可以了。

Hugo 提供 FullCalendar 可用的 events

通过上面两步的分析，大体上解决思路都已经确定，接下来就是按部就班让 Hugo 生成一个 JavaScript 对象 events 使得 FullCalendar 可以读取即可。整个 events 是一个数组，数组中的元素 Event Object 可以点击查看官网的文档。

虽然 event 支持很多很多属性可以定制，但对于我的博客来说很简单，我希望在月历上显示两种文章：

1. 已发布的文章
2. 未来将要发布，目前还是草稿的文章。（也就是我希望督促自己挖的坑啦）

它们俩在 FullCalendar 层面的区别，仅仅是颜色不一样，以及未发布的文章没有链接不能点击而已。在 Hugo 里虽然这个代码谈不上多好看，但是也够直白。下面这几行就得到了包含所有上面两类文章的 $events 了 ，之后把它们放到 JavaScript 代码里即可。

{{- $events := slice }}
{{- $posts := where .Site.RegularPages "Draft" "eq" false }}
{{- $drafts := where .Site.RegularPages "Draft" "eq" true }}
{{- range $posts }}
  {{- $events = $events | append (dict "title" .Title "start" (time.Format "2006-01-02" .Date) "url" .RelPermalink "allDay" true ) }}
{{- end -}}
{{- range $drafts }}
  {{- $events = $events | append (dict "title" .Title "start" (time.Format "2006-01-02" .Date) "allDay" true "color" "var(--text-muted)" ) }}
{{- end -}}

注意点

虽然整体上，这个功能并不复杂，但是一些小细节却占用了我不少时间，回想起来大概有下面这几点。

1. Hugo 默认会忽略任何草稿文件，所以不改一下默认设置的话，上面的 $drafts 将永远是空值。最简单的方法就是在配置文件里加上：buildDrafts = true 以及 buildFuture = true
2. 但是经过上面这么一设置，首页，归档页和 RSS 输出都自动出现了草稿，这是我不希望看到的结果，于是分别修改相应的模板文件。
3. 另外一个小问题是 FullCalendar 默认的点击行为是直接在当前页打开链接，我希望改成在新标签中打开。
4. 因为网络上删库跑路的事情太多了，虽然像这样知名的库不太至于，我还是保险起见将 FullCalendar 里需要的 JS 文件下载到了本博客自己的仓库里。
5. 此外就是一些关于月历显示大小，周末颜色区别，以及多语言之类的微调了。

代码在此就不一一解释了，总之整个月历功能的实现，我都包含在下面两个 commit 里了，有需要可以自行查看。

• feat(theme): add calendar page for posts · yuanji-dev/nikki@cc5f4cc
• feat: hide draft page in all list pages · yuanji-dev/futu@3499b50

总结

在做完这个小功能之后，我马上新建了包括本文在内的 4 篇草稿，使用自己做的功能的感觉很不错。希望我能让它们准时发布，我甚至开始乐观地估计，基于今年 15 篇博客的数量，明年倍增达到 30 篇也不是难事？

没错，自上次重写主题以来，我的博客差不多有一年半没有太大样式上的变化了。如果有读者有读过我上次那篇折腾博客主题的文章的话，应该知道我的主题主要基于一套 classless 的 CSS 样式，叫作 awsm.css。

然而最近当我想访问 awsm.css 的网站时，竟然发现原作者已经删库跑路了。虽然我有自己的 fork，但作为一个契机，差不多是时候再折腾一下主题了，毕竟也临近年末了。

从结论上而言，我从 awsm.css 转到了 water.css

经过

因为 water.css 也是一套 classless 主题，所以替换 awsm.css 并不是很费力，而且两套主题很相似，所以说实话如果没看出啥区别也不奇怪。不过就是一些小的细节花了几个晚上的业余时间微调了一下。简单列了一些问题点，大部分显著的毛病我已经修了，于是想着差不多可以释出第一版了。

其中一个值得注意的决定是，我尽量没有更改原主题的样式（除了少数 postcss 特有语法），额外的修改我都在主文件 main.scss 引入 water.css 的源文件之后加以覆盖，主要是为了以后如果上游有更新，可以比较容易地做相应更改。

改善点

我个人感觉用了 water.css 之后的一大改善点就是用上了 CSS 自定义属性。一个直接的好处就是让支持夜间模式变得简单，这也是这次折腾主题的一个比较大的动力。虽然我自己基本从来不用夜间模式，但也许有喜欢我博客的读者使用，这一次重点支持了一下，如果对我的这次新改动的主题感兴趣，欢迎使用和反馈。（可以点击导航栏右侧的🌙/☀图案切换）

关于标题

一方面是因为这次样式的改变主要是因为选择了 water.css，另一方面也让我想起了李小龙之前在采访中关于“水”的一段谈话（见下面视频），借此就用作了我这篇短文的标题。

以上就是这周有关修改博客样式的介绍了，希望各位读者喜欢。

Be formless, shapeless, like water.

Now you put water into a cup, it becomes the cup, you put water into a bottle, it becomes the bottle, you put it in a teapot, it becomes the teapot.

Now water can flow or it can crash.

Be water, my friend.