ブログの構造を整理した

Hugoでの警告

しばらく忙しくしていたこともあり、Hugoのバージョンを上げていなかったなと最新版にしてみました。
更新後に Hugo Serverを立ち上げると警告が出まして、今使っているコードの中に近い将来使えなくなるものがありますよという案内です。

今すぐ対応する必要はありませんが、PaperMod（テーマ）側で修正入っているかなと公式サイトを覗いてみることに。

PaperMod

あれこれ見ている間にふと気付いたのです。
私のブログの作り方というか、PaperModの構成はよろしくないということに。

従来のやり方

Hugoではthemesというフォルダーの中に好きなテーマを展開します。
その中にはページレイアウトを構成するパーツ（html）や、スタイル（css）等がすべて収まっており、あとは記事を用意するだけでホームページが完成するというお手軽さです。他にも設定するところはあるけど、ざっくり言うとそんな感じ

記事を表示するパーツがsingle.htmlというものでして、私はそれを複製して自分好みの改造をしていたんですね。

元ファイル
- /themes/PaperMod/layouts/single.html
複製先
- /layouts/single.html

/layouts/のほうが、themesよりも優先される仕様です。

これは一例ですが、そんな感じでhtmlやらcssやらをどんどん複製していき、サイトが完成しました。

デメリット

ただ、これって問題があったんですよね。
PaperMod側で修正の入ったファイルをthemesに入れても、優先される場所に同じファイル名が存在すると新機能やら不具合対応やらが反映されないわけですよ。

気付いちゃった

あらためてPaperModの中身を見ていましたら、上書き用にファイルが用意されておりましたわ。

single.htmlの抜粋ですが、9行目にextend_post_content.htmlってあります。
このextend_hoge.htmlっていう空ファイルがsingleやfooter等々で複数用意されていまして、そこにカスタマイズしたい内容を書いてあげれば良いのです。

呼び出される場所（実際に画面に表示される場所）は限定されるものの、ある程度それで我慢できれば、公式が手を加えるsingle.htmlは常に最新のものが使い続けられるという話です。

single.html
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
  {{- if .Content }}
  <div class="post-content md-content">
    {{- if not (.Param "disableAnchoredHeadings") }}
    {{- partial "anchored_headings.html" .Content -}}
    {{- else }}{{ .Content }}{{ end }}
  </div>
  {{- end }}

  {{- partial "extend_post_content.html" . }}

  <footer class="post-footer">
    {{- $tags := .Language.Params.Taxonomies.tag | default "tags" }}
    <ul class="post-tags">
      {{- range ($.GetTerms $tags) }}
      <li><a href="{{ .Permalink }}">{{ .LinkTitle }}</a></li>
      {{- end }}
    </ul>

大規模修正

いままでちまちま作っていた複製ファイルといったんオサラバして、extend系ファイルに手を加える作業を行いました。
昔は自力でネットを駆け巡って調べ、トライ・アンド・エラーで時間をかけて行いましたが、今はのっちー（Notion AI）のおかげで大幅に時間短縮ができました。

ついでに以前から気になっていた部分の調整（主にスタイルシート）なんかも加えて、ようやく公開に至りました。
のっちーありがとう。

🔗 あなたをサポートするAIチームのご紹介 | Notion

ブランチ

GitHubで管理していますが、今回、大規模修正をかけるということでブランチなるものを用意して作業し、完了後にマージしました。
知識としてはありますが、やったことはなかったのでのっちーに教えてもらいながら進めました。

以下はのっちーに書いてもらいました。（絵も）

なぜブランチを切るの？何をするの？

大きな修正をするときほど、いきなり main を直接直すのではなく、作業用ブランチを切ってから main に取り込むのが安心です。理由は「安全に進められて、途中経過を分離できて、確認もしやすい」から。

branch — 「大きく変えるほど、まず分ける」
これがブランチ運用のいちばん大事な考え方です。

なぜやるのか（目的）

main を安定させるため：作業中のバグや未完成の変更が混ざりにくい
変更を見える化するため：差分がまとまり、レビューや説明がしやすい
失敗しても戻れるため：方針変更や撤回が簡単で、試行錯誤しやすい
並行作業を安全にするため：複数人・複数タスクがぶつかりにくい

どんなことをするのか（やること）

main から作業用ブランチを作って変更をまとめる
変更が揃ったら Pull Request（PR） を作り、差分と意図を共有する
必要なら指摘を直し、OK になったら main にマージする

ということで

hugoの警告から大規模修正をかけたお話でした。
これでメンテがしやすくなったはずだし、気になっていたいくつかの調整もできてスッキリ。（実はもう少し手を入れたい）

尚、最初の警告は消えていませんので、PaperMod側ではまだ対応していない様子。
自力でやってもいいけど、やるとまた整合性とるのが面倒になる部分なので、しばらく放置しときます。

「ここおかしくなっているよ！」とかお気付きの点があればお知らせくださいませ。

Hugoでの警告#

PaperMod#

従来のやり方#

デメリット#

気付いちゃった#

大規模修正#

ブランチ#

なぜブランチを切るの？何をするの？#

ということで#

関連記事