Simply Staticで用いる追加設定
Simply StaticはWordPressで作成したウェブサイトを静的ウェブサイトに変換してくれます。詳細は以前の記事をご覧ください。しかし、以前の記事を書いた時点では見つからなかった問題などが発生しました。いくつか解決したのでそれをメモしておきます。
1. 404ページが更新されない
ぼくはフルスクラッチでブロックテーマを自作して使っています。404ページもブロックテーマのテンプレートに存在し、それはSimply Staticによって404.htmlというファイルに変換されます。しかし、その変換が一度しか行われず、404ページのテンプレートを修正しても更新されない問題が生じました。
これに関してぼくは完全にアドホックな解決策を利用しています。GitHubのデスクトップクライアントを使ってレポジトリを操作し、レポジトリ上の404.htmlを削除したのちにSimply StaticのExportを行うことで解決しました。GitHubのウェブ上で削除操作のちコミットしても同様のことができると思います。
ちなみに、私はパーマリンクの設定をカスタム構造の「https://hoge.hage.com/posts/%postname%.html」としているため、404.htmlというファイルができます。WordPressインストール直後のデフォルト設定では、基本の「https://hoge.hage.com/?p=123」のようなリンクになっています。このままだとSimply Staticを使う上で良くない的なことをどこかで見かけたので、このような設定にしています。基本のままでやるとどうなるかは未確認です。hoge.hage.comはLightsailでWordPressを動かしているホスト名です。自分のWordPressのホスト名に読み替えてください。
さらにちなみに、ぼくは%postname%（スラッグ）は毎回英語で設定しています。普通に記事を書いただけですと%postname%にはタイトル名が入ります。タイトル名は日本語であることがほとんどなので、URLの中に日本語がエンコードされて入り、URLが長く見にくくなってしまいます。それを避けるため、若干面倒でも毎回手入力で適当に英語タイトルを作成しスラッグとして設定しています。
2. 変換されないファイルが存在する
何故か変換やコピーされないファイルが二つありました。
https://hoge.hage.com/wp-includes/js/wp-emoji-release.min.jshttps://hoge.hage.com/wp-content/uploads/404.jpg
1)は、本当にたまたまChromeのデベロッパーツールを開いていたため、未コピーで404になっていたのを発見しました。何故コピーされないかは不明です。
2)は、404.htmlの中で参照している画像ファイルです。404ページが更新されないのと原因は似ているのかもしれません。
これらの問題を解決するために、Simply StaticのSettingsのGeneralにある、Additional URLsを設定しました。上記ふたつのURLを指定することでデプロイされるようになりました。公式のドキュメントにもこの手法について書かれている項目があります。
3. 意図しないリンクの置き換えが発生することがある
Simply StaticのSettingsのGeneralの中にReplacing URLsという項目があります。これは、WordPressが生成するページの中のURLをどう置き換えるか、という設定です。標準はRelative Pathになっています。この設定の場合、http://hoge.hage.com/fuga.htmlが/fuga.htmlに置き換えられます。ほとんどの場合、Relative Pathで問題ありません。
後で記事にしますが、ぼくがショートコードで雑に作ったXへのシェアボタンがあります。ボタンのリンクは「http://x.com/intent/tweet?url=https://hoge.hage.com/posts/…」みたいなURLになっており、このリンクをクリックすることでXに記事をシェアすることができます。Relative Pathの設定のままですと、このリンクの中のhttps://hoge.hage.com/の部分まで削除されRelative Pathになり、そのRelative PathがXのポストへリンクとして入ってしまいます。これは意図した動作ではなく、正しくシェアされません。
この問題を解決するために、Replacing URLsはAbsolute URLsにしてあります。schemeとhostをデプロイ先のhttps://hage.com/に設定し、すべてのURLを絶対URLに変換することで問題を解決できました。ちなみに、Force URL ReplacementはデフォルトのONのまま使っています。
4. 削除したはずのファイルが残り続ける
WordPress上でファイルを削除しても、GitHubのレポジトリ上のファイルは削除されることなくそのまま残り、毎回デプロイされます。削除したつもりでもCloudflare Pages上にファイルが残り、外部から見えてしまいます。良くない問題な気がします。
解決策はこれも無理やりで、たまにレポジトリの中身を全削除します。GitHub Desktopアプリでローカルにクローンしたファイル群をREADME.md以外は削除してコミット、プッシュすることで、レポジトリ上のファイルを削除しました。しかし、これやっても過去のmainトランクにはゴミが残り続けるんだよな…まぁいいか…
5. ExportしたZipファイルがWindows 11の標準機能では展開できない
これはAmazon LightsailでbitnamiのWordPressを使っているから生じる問題かもしれません。ZipでExportした場合、圧縮ファイルの中身がやたら深いディレクトリのZipアーカイブができます。それだけならばまだコピーして再圧縮すれば良いのですが、アーカイブ中にパスとして使えない文字が入っているらしく、Windows 11の標準展開機能では展開できませんでした。
7-Zipを使うと中身は見ることができたので、中身の深いフォルダをたどって展開しました。再圧縮してCloudflate Pagesにアップロードできるかは未確認です。
6. ExportではなくUpdateを実行すると更新部分だけコミットされる（ような気がする
これは問題点ではなく機能です。Generate Static Filesボタンの上にドロップダウンリストがあります。普段は「Export」になっていますが、これを使うとサイト全体をExportします。このドロップダウンリストを「Update」に変えてGenerate Static Filesすると、Incremental exportsになり、部分的に更新が走るように見えました。こちらの方が少し速いですね。最初はExportして、更新した時はUpdateで良いかもしれません。
7. ExportではなくSingle Exportを実行するとそのページに関する部分だけコミットされる
投稿やテンプレートを編集しているとき、右ペインの設定の中にSimply Staticの項目ができています。この中のExport static pageをクリックすると、そのページに関連するページを必要な分だけExportする、らしいです。この機能はSingle exportsと呼ばれています。記事書いて公開したのちにぽちっとクリックするだけで変更部分のみをデプロイできる、はずなのですが、うまく動きません。主に、「前の投稿」「後の投稿」のリンクが正しく更新されませんでした。本当にそのページだけを修正した時は走らせても大丈夫だと思います。
8. おわりに
たいして書くことないだろう、と思っていましたが、いざ並べてみると結構ありますね…コピーされないファイル問題は未だに気になっています。今回はたまたま見つけましたが、見つけられるのは稀かもしれません。どうしたものですかね。