目次
Odamaki再開発計画
はじめに
Odamakiは2021年1月24日からデザイン、開発しているWordPressの自作クラシックテーマです。テーマ名はオダマキソウから取っています。このテーマをyokkin.comに適用して3年間になりますが、このテーマファイルは機能を拡張しづらかったり、コードが見づらかったりするという問題がありました。
この理由で、2月24日から、Odamakiを作り直してきました（現在完了形）。今回の改修は、いわゆる開発手順やテンプレートファイルのメンテナンスを楽にしたうえで、部分的にブロックテーマの要素を取り入れるハイブリッドテーマ化を主軸に置いています。今回の改修にあたっていろいろなモダンな試みを行ったので総じて記事にできたらいいなと思っています。
なぜWordPressにこだわるのか？
今回の更新にあたって、SSG（Static Site Generator）を使ってサイトを生成し、それらをGitなどで運用し、サイトのビルド、デプロイをGitHub CIなどで行うことも検討しましたが、やはりWordPressに踏みとどまることにしました。その理由はいくつかあります。それはいろいろな面倒にまさるエディタの書きやすさと、単純な技術の習熟度の問題です。
エディタの書きやすさ
WordPressのエディタ、Gutenbergは操作が直感的で、全部ブラウザで完結しているところが良いです。思いついたアイデアがあったらすぐにブラウザを開いてブログを書くこともできるし、出先で誤謬を発見したときにも、ブラウザでサクッと更新することができます。記事を書く際の執筆体験は大変良いと思います。
この方法の対抗馬としては、記事を外部のテキストエディタを使い、Markdownなどのプレーンテキスト形式で執筆する方法があります。しかし、我々が普段読み書きする自然言語をテキストエディタを使って書くのは正直辛いです。
ではワープロで下書きをすればじゃないかと思う人もいるかもしれません。しかしそういうわけでもなく、結局記述した文章をテキストエディタに移すという二度手間が生じるし、何より文章以外の要素、たとえばコードや画像などが入ると途端にワープロでは扱いづらくなります。
ここで、Markdownをディスっているわけではありません。Markdownは文章を書くためのよいフォーマットであり、全部テキストファイルだからバージョン管理や取り回しが楽です。しかし、基本的にMarkdownを記述するものはテキストエディタで、テキストエディタでの執筆体験は、WordPressのエディタで記事を書く際の執筆体験より劣っていると思います。
技術の習熟度の問題
筆者は、WordPressにはかなり慣れています。また、このサイトについていえば、大規模な変更には保守的であり、それなりに自分自身が手慣れているものを、このサイトで使う技術として利用したいと思っています。
書き慣れていないコードを書いて、バグらせたり、設計の手慣れがなく、不安定なサイトを運用することになるのは予想がつきます。安定は第一だと思い、WordPressを選ぶことには意義があると思いました。ただし、今後新しいウェブサイトを作ることになった際は、別の手段を検討しないことはないと思います。
ネガティブキャンペーンは結構！
そうはいっても、読者の中には、WordPressは設計がレガシーで、セキュリティの担保が大変で、メンテナンスが煩雑で云々と思っている方もいるかもしれません。実際、WordPressのサイトを維持するためには、本体やプラグインの定期的なアップデートや、セキュリティ、幅広い技術スタックの知識、微妙なレスポンス速度と向き合わなければなりません。
しかし、プラグインや本体のアップデートのような些細な作業は内部で定期的に動くWP-Cronという仕組みでいい感じにやってくれるし、後述するWP-CLIのようなツールを併用すると、管理画面での作業をシェルから実行できるし、シェルスクリプティングを頑張れば面倒な作業を自動化することもできます。WordPressのコミュニティは本当に大きく、本質的な厳しさに打ち勝つための打開策が用意されているので、そこにしっかりと目を向ければ、決してすべてが苦痛だというわけではないと思います。
どの技術にも問題はあります。まだまだWordPressのいいところは素直に捉えられるし、せっかく作ったOdamakiのデザインを無下にもしたくないので、私はこのテーマファイルを強化・延命する形で存続させることにしました。
なぜハイブリッドテーマにしたのか？
さて、今回はWordPressに親しい人であれば、なぜ今更クラシックテーマを？と思う人もいるかもしれませんが、理由はあります。最近のテーマ形式の流行はブロックという再利用可能なコンポーネントと、テーマファイルに付属するテンプレートファイルを組み合わせてウェブサイトを作成することができる、フルサイト編集対応のブロックテーマです。それに対して、PHPのテンプレート関数を使ってテーマファイルを作成していく従来型のテーマをクラシックテーマといいます。この２種類のテーマファイルの形式があるため、現在WordPressでウェブサイトをデザインしたいと思い立った時、人々がとれる選択肢は以下の通りです。
- 自分がブロックテーマ開発者となって、ノーコードで自力でカスタマイズできるような設計を持ったテーマを作成する。
- そもそもコードを書くのをあきらめて、既存のブロックテーマのフルサイト編集機能を使ってカスタマイズする。
- 従来型のクラシックテーマを作成する。
クラシックテーマとGutenbergを融合したハイブリッドテーマ
最初は、1のように、今回作成するテーマファイルの形式もそれに迎合する形でブロックテーマに完全移行させても良いと思いました。しかし、既存のブロックのデザインに絞られるということと、自分しか使わないテーマなのにも関わらず、わざわざカスタマイズ性を高める理由がないという理由で断念しました。2も、別段気に入った既存のテーマがないので断念しました。ということで3を選択することになりました。
ただし、フルサイト編集対応のテーマファイルを使用しようがしまいが、現在のWordPressを運用する上で、記事執筆時にはGutenbergというエディタの使用を推奨されます。そのため、ブロックテーマの基礎技術からは逃れられません。そのため、本テーマファイルは、クラシックテーマでありながら、theme.jsonを利用してデザインを定義するような、ハイブリッドテーマという構成になっています。
開発環境の調達にwp-envを利用する
今回、開発環境の調達にはwp-envを利用しました。
このテーマを開発し始めたのは2021年です。当時はテクいものにあまり手も出せていなかったし、それにまつわる技術的理解も浅かったです。実際、本当にWordPress環境を構築するために、ウェブサーバーのnginxや、データベースサーバーを自分でインストールする必要があると思っていました。しかし、便利ツールが生まれてきた中で、自分自身もこの3年間色々な知識を手に入れることができたと思っています。そこで、wp-envというツールが手ごろに感じて、採用することにしました。
wp-envは、WordPress公式が開発簡易化のために用意しているCLIツールです。このツールはDockerさえインストールした状態で、.wp-env.jsonという設定ファイルさえ用意すれば、開発に必要な環境を簡単に作成したり削除したりすることを可能にするてんこ盛りセットです。
WP-CLIも便利
また、wp-envは、wp-cliというツールも同梱しています。wp-cliは、WordPressの各機能をコマンドラインから利用することを可能にするツールで、これを使うと、本番環境からダンプしたデータをインポートしたり、レコードの置換も簡単にシェルから行ったりと、WP-CLIで作ったまっさらな環境を簡単に開発レディな環境に仕立て上げることができます。
このようにして開発に必要な環境自体はすべてwp-envで完結させることができました。
ぜひ今後も利用したいと思います。
Timberを使う
WordPressでテーマを作成するためには、まず基本となる書き方や、必須となるテンプレート関数があり、それに則ってテーマファイルを記述する必要があります。ただし、基礎となるクラシックテーマの構文は非常に古めかしいものです。これはWordPress自体が2003年からの遺産を引きずっているソフトウェアである以上、仕方のないものではあります。しかし、それからの20年間で、PHP、WordPressを囲む技術、そしてWebサービスを構築するうえで大切とされる考え方は大きく変化しました。そして、クラシックテーマを書く環境も変化しました。
でもちょっと待って！PHPは「テンプレート」言語じゃないの？
もっとも、PHPはテンプレート言語としての起源がありますが、EJS, Jinjaのような現代的なテンプレート言語が持つ機能や構文と比べるとずっと原始的です。この問題はTwigの「What makes Twig better than PHP as a template engine?」でも言及されています。
テンプレートのMVC化
今回、テンプレートのMVC（モデル・ビューコントローラ）化を促進するために、Timberというフレームワークを利用しました。特に、従来のWordPressのクラシックテーマでは、HTMLのセマンティックな要素に介入してPHPの構文や、WordPressのテンプレート関数の呼び出しを書く必要があり、ビューとコントローラの部分が切り離せない関係にありました。そのため、いったん書いたコードはなかなか後で触りづらいという問題があります。
Timberの機能
Timberは、データモデル、ビュー、コントローラを以下のような要素に対応付けています。このフレームワークの功は、記事やコメントのデータをうまくオブジェクトとして収めつつ、ビューとコントローラの間でコンテキストという共有データを保持し、そこにTwigというテンプレートエンジンが介入することで、ビューとコントローラを分離しているところです。
また、もちろんTwigテンプレート自体の機能を利用することもできます。たとえばTwigは、テンプレートの「継承」をサポートしていて、テンプレート自体の再利用性を高められます。また、map、reduce、filterなどの関数もサポートしていて、宣言型プログラミングを支援しています。このため、上手くテンプレートファイルをかけば、何をやっているかが一目でわかるような仕上がりにすることもできます。採用して大正解でした！
| データモデル | WordPressが保有する記事データ。 |
| ビュー | HTMLなどの見栄え、後はデータを埋め込むだけのテンプレートファイル。 |
| コントローラ | 内部の記事を取得する仕組みを使ってデータを取得し、このページで何を何回表示させるなどのロジック部分を担当。 |
Webpackを使ったモジュールのバンドリング
HTTPリクエストの数が減ると、サーバー側の負担も読み込み速度も向上します。今回はウェブサイトの読み込み時のパフォーマンスを上げたくて、モジュールのバンドリングにも挑戦してみました。たとえば、PostCSSのモジュールの一つである、PostCSS Preset Envを使って、自動でCSSのプロパティにベンダープレフィックスを付けたり、cssnanoを用いてminifyを行いました。また、ES2020で記述しているJavaScriptについても、後方互換性を維持するために、JavaScriptのトランスパイルをBabelを用いて行いました。これらの成果物を一つのJavaScriptにバンドルするために、Webpackを利用しました。使ったモジュールは以下の通りで、構成は以下のような感じになっています。
これにより、ページロード時に読みこむリソースの多くを削減することができました。また、最終的にはCSSをいくら分割しようが、最終的にはモノリシックなJavaScriptに収められる点もよいと思います。
ホームページのデータモデルを構築した
Advanced Custom Fieldsを活用してフロントページにあった多くのコンテンツ、例えば作品や自己紹介などのページをWordPressの管理画面から編集できるようにしました。これまでは、技術力がなくテーマファイルに直書きしていましたが、データも一か所にまとめられることができるし、楽に編集できるという点でも便利になったと思います。
おわりに
このように、ひとまずOdamakiを人に見られてもよい形にできてよかったです。また、MVCの概念を理解するだけでなく、テーマの開発を通して実践できたり、フロントの知見を得たりや、意思決定の能力も向上させたりすることもできたと考えています。OdamakiのGitHubのリポジトリは以下にあるので、良ければご覧ください。
コメント
コメントはありません。