先日、page-*.php を使うことの是非みたいな話が話題になりました。
基本的には、「page-*.php にコンテンツベタ書きするのはアンチパターン」ということだと僕自身は考えてます。そういう作り方するなら Astro とか採用したほうがベターなのでは？とは考えいて、過去にそういう話をさせてもらいました。
WordPress のメリットを生かせないやり方をしても WordPress を運用する上での手間やリスクなどはついて回るわけで、それはコスパが悪いやり方だよなと。ユーザー自身に編集をさせないやり方をするならそういうシステムを採用した方が開発も楽だと思ってます。
そもそも僕が怒る筋合いもないとは無いですし、別に page-*.php とかを見ても怒りが沸いてくるとかは別に無いんですが、ただまぁ、それによって発生するデメリットは押さえておきましょうねという話だと思います。グローバル変数使うなみたいな話とかみたいなそういうことと近しい話かなと。
プラグイン作者として思うこと
僕自身いくつかプラグインを公開していたり、Gutenberg にコントリビューションをやっていたこともありますが、基本的にはデフォルトテーマでの動作確認を行うことがほとんどです。特に公式のプラグインディレクトリに公開されているものはそうですが、まずはデフォルトテーマや公式のテーマディレクトリでインストールできるテーマで正しく動作するように作ります。
サイト制作に関わる中でプラグインを作成することも多いですが、その際もその業務とは切り離された最低限の WordPress 環境を用意して開発をすることがほとんどです。開発時のエラーや不具合がそのプラグイン由来なのか別の要因なのかがわかりにくいですし、プロジェクトにすでにあるコードへの依存などが発生したりで後々予期せぬ問題を発生させる恐れがあるからです。なので最初に初期状態の WordPress での動作を確認し、それを実際に開発中のサイトに導入してみて動作検証するような順序で開発します。
特定のテーマ専用のプラグインを公式レポジトリに載せるメリットも無いですし、それに依存せず使えるものが汎用性があって広く使ってもらえるプラグインだと思います。Contact Form 7 を使うために専用のテーマを導入にして下さいと言われても困りますよね。
プラグイン作者として色んなフィードバックを貰いましたが、「デフォルトテーマでは正しく動作するのに、知らないテーマやプラグインと一緒に使った結果上手く動かない」、と言われたこともたびたびありました。作者側としては「そんなこと言われても本当にわからんですよ…」というのが率直な感想です。サポートフォーラムの問題解決のためのチェックリスト等でも言及されますが、トラブルシューティングの基本として、「すべてのプラグインを無効化し、同時にテーマをデフォルトのテーマに戻して再度試してみましょう。それで正常に動くなら一つずつ元に戻してみて、どれが問題を引き起こしているか絞り込むことができるはずです。」と書かれています。
作者側としては、「デフォルトテーマ等で不具合が再現できる場合は対処のしようがあるけれど、そうでは無い場合はそもそもわからないしどうしようもない」、という感じです。こっちが想定してない使い方をして上手く動作しなくても、そりゃ想定してないし…
WordPress の魅力としてプラグインの豊富さ等はよく語られますが、そのメリットを享受するためには結局デフォルトテーマのようにテーマを作ることが一番良いわけです。WordPress はもともとブログシステムとして開発され、基本的な設計や思想は現在でも大きく変わっていないです。管理画面からテキストやら画像やらを入力して記事を作成することを主眼に置いているわけで、テンプレートにコンテンツをベタ書きすることはそもそも想定されてないわけです。
結局、WordPress が想定外使われ方をしている状態をサポートするってのはそもそも無限のケースを考えるって話なので原理的に不可能ですし、特定のテーマのためだけの機能を足すのもそれはそれでキリが無いので現実的では無いです。
サイト制作を生業とする人として考えること
そんなブログシステムとして出発した WordPress ですが、CMS として扱われることが増え、そのニーズに応えられる機能がはじめは少なくテーマにハードコードすることも少なくなかったですが、2010年代後半にはかなりの改善がなされて「ホームページを作る」くらいのニーズであればテーマにハードコードせずに作成できるのが現在地です。
WEBに求められる技術の複雑化、デザインやフロントエンド技術の進化、WordPress 側の進化、それらと現場のニーズの折り合いをつけるのが難しくなってきたとは思います。
登壇などでたびたび言及していますが、WordPress は HTML/CSS を細かく制御しようと思うと壁は多いです。ある意味、ノーコードツールとして進化しようとしているのでこの傾向は今後も続き、どんどん壁が増えていくと思って良いかと思います。
WordPress は強力なツールではあるが万能ではない
近年の WordPress は Wix や Squarespace などのサイトビルダーと比較される機会が増えましたしその方向性を指向しているように思います。これらは HTML / CSS 等を記述せずにWEBサイトを作るツールです。
WordPress 側の表現力もかなり強化され、クラシックエディター時代とは比較するまでも無く、ブロックエディタでできる表現もかなり増えました。
10年以上前は「お問い合わせフォームがほしい」という理由のみで WordPress + Contact Form 7 を静的サイトに追加するみたいな話もありましたが、最近はメールフォームを提供するサービスも、Google Forms / form.run / Formspree / SSGform 等多数ありますし、HubSpot 等の CRM が提供するフォームを利用することも増えました。
Next.js / Astro も広く普及しましたしコマンド一発でひな形と開発環境を簡単に立ち上げてくれます。実際に僕が page-*.php を書いて開発していたことも大昔にありましたがその頃に Astro があったらたぶん WordPress やってないだろうなーとは思ったりもします。また、それらを運用するためのホスティングサービスも Vercel / Cloudflare Pages / Cloudflare Workers / AWS Amplify 等の信頼性の高いサービスが存在しています。
page-*.php にコンテンツをベタ書きしたいシチュエーションに遭遇したとき、「自分たちが作ろうとしてるサイトに本当に WordPress がマッチしているのか？ 」、「WordPress 本体やプラグインのアップデートと付き合うだけのメリットがあるのか？」ということを問い直すのは重要なのではないかなと思う今日この頃です。