記事とショートの公開と未公開を、front matter（ファイルの冒頭に書く設定の並び）のフラグではなく、フォルダの場所で決めることにしました。

未公開のものは content/drafts/ に置き、公開するときは content/posts/<年>/ や content/shorts/<年>/ へフォルダごと移動します。ファイルの中身は編集しません。

これまではフラグを見るためにファイルを開く必要がありました。いまは公開の操作がフォルダの移動だけなので、開かなくても状態が分かります。

僕のブログでは、ショートを1件共有するときも、共有先は個別ページではなくショート一覧にしました。URLには一覧内の特定位置を指すアンカーが付き、該当するカードを示します。

ショート一覧でカードを選ぶと、別ページへは移らず、ブラウザのアドレスバーにあるURLだけが変わります。選んだカードは枠で強調され、URLをコピーするボタンも同じ一覧内アンカーを返します。

共有されたURLを開くと、一覧が該当カードの位置までスクロールします。その前後には、ほかのショートもそのまま並びます。

Hugoを選びましたが、将来も使い続けるとは決めていません。僕は別のツールへ移るとき、記事本文とデザインまで作り直すのは避けたいと考えました。

そこで、記事本文はHugo固有の記法を入れないMarkdownで書き、Hugoのショートコードは使わないことにしました。装飾はCSS、動きはJavaScriptに分け、Hugoだけで動く処理はテンプレートと設定にまとめています。新しくHugo固有の機能を使う場合は、専用の処理をまとめた一覧へ追記します。

haruki256.comの本番を、WordPressからHugoへ切り替えました。切り替え前にデータベースとファイル一式をバックアップし、Hugoの生成物は公開先とは別のフォルダへ展開しています。

WordPressは削除せず、public_html を別名に変えてからHugo側と入れ替えました。公開後は主要ページ、CSS、JavaScript、SVG、RSS、サイトマップ、404、HTTPSへの転送を確認しています。

問題があればHugoを別の場所へ動かし、WordPressのフォルダ名を public_html へ戻します。切り替える方法だけでなく、問題が起きた場合に戻す方法も先に用意しておきました。

WordPressから取り出した旧記事は、Hugoへ移したからといって、すべて公開し直す必要はありません。

このブログでは、公開されていた7本と旧下書き6本をMarkdownで手元に残し、13本すべてを非公開にしました。以前の公開URLは記録用の legacy_url に残しますが、Hugoの公開先には使いません。

新しい記事は /:year/:month/:day/:slug/ の形式で、slugを英小文字のkebab-caseに統一します。旧記事を将来書き直して公開する場合だけ、新URLと転送を設定します。

haruki256.comを、WordPressからHugoへ移す作業を始めました。

WordPressに大きな不具合が起きたわけではありません。記事をMarkdownで手元に置き、gitで変更を追い、公開環境では静的ファイルだけを配信する形が、これからの運用に合うと判断しました。

調査時点の投稿は7本で、承認済みコメントは0件でした。移行コストがまだ小さい今のうちに、既存URLを保ったまま切り替えられるか検証しています。