推奨は、純度100%のオリジナルテーマ

長谷川 雄治
135回表示・読了見込 12

最近のWordPress界隈のゴタゴタから、今からどうすべきか、どう向き合うかについて筆者なりにざっくりと解説してみました。
なぜオリジナルテーマが推奨なのかも、長々と語っています。少しでもご参考になれば幸いです。

先月末、WordPressの開発に14年以上貢献してきたエンジニアが、離脱を表明するニュースが出たり(https://gigazine.net/news/20241029-chris-wiegman-so-long-wordpress/)、カスタムフィールド向けのプラグインである「Advanced Custom Field(通称ACF)」が突如「Secure Custom Field(略称SCF)」へ変更になる(https://addapter.co.jp/blog/acf-to-scf#-)など、なんとなく慌ただしい印象のWordPress(というよりは、WordPress.orgの所有者であるAutomatticと、WP Engine社)界隈。

我々、BLUE B NOSE(以下BBN)もWordPressの上に成り立っており、とあるサイトでカスタムフィールド向けのプラグイン「Custom Field Suite(以下CFS)」を使用していましたが、今年6月中旬頃に脆弱性が報告されていた(https://wpsecurity.jp/10140/)ことに気がつき、別のプラグイン「Smart Custom Fields(略称はこちらもSCF)」への切り替えが発生するなど、少々バタついておりました。

有料機能もあるACFをまつわる騒動について「それって、どうなの?」と思いましたが、CFSはCFSでどうやら開発終了となったようで、脆弱性への対応はない模様。開発終了と言えば、少し前になりますが、WordPress上で使うメールフォームプラグインとして「Contact Form 7」と二大巨頭の一角を占めていた「MW WP Form」が開発終了してから約一年が経過しています。(https://blog.taga-tame.com/introducing-alternative-plugins-and-form-creation-tools-for-mw-wp-form/)

Jamstackや各種SSGも興盛で、着実に開発に携わる人材やリソースが減りつつあるWordPressについて、今後どのように向き合うべきなのか。筆者なりの考えをお伝えします。

目次

コアの部分も関係各位も、余裕がなさそう

WordPressのコアの開発には微塵も触れず、コントリビュータもやっていない外野の立場からでは、コミュニティの現状等まで詳しく把握できるはずもありませんが、現在着実に言えることとしては上記の見出しぐらいでしょうか。

最近のWordPressは、本体であるコアやプラグイン、テーマが更新された場合、即座にアップデートをかけて追従しないと、管理画面で編集画面が崩れてしまう現象が発生するようです。

筆者が実際に遭遇した事象としては、カスタム投稿やプラグインの設定画面で用いられる旧タイプの編集画面、Classic Editorで「2列表示」に設定していると、右端のサイドバーが重なり合うようになってしまったり、メイン部分へ挿入するように設定しておいたはずのmeta boxが、サイドバーへ移動したり、予期せぬ場所へ移動してしまい、そのままでは編集したい部分が全然見えなかったり、「更新」ボタンが押せなかったり、そこそこ大きな不具合がありました。

管理画面内で使うCSSや、HTMLの組み合わせがおかしくなっているのだろうと思われますが、コアとプラグインを更新したり、編集画面を「2列表示」から「1列表示」に切り替えたり、カスタム投稿の編集画面もGutenbergへ切り替えるように一手間加えるなどして、一時的な措置をとっています。

今まではあまり見られなかった類の不具合であり、また少しくらい更新を先延ばしにしていても目にみえる問題は少なかった印象でしたが、コアもプラグインも配布テーマも、ちょっとでも更新がかかったら即座に追従しないと不具合が生じてしまうような状況では、今後も安心して使い続けられるのか、不信感が芽生えてしまいます。

ちなみに、WordPress 5.5から5.6へのコアアップデートの際、内包されているjQueryを1.x系から3系にバージョンアップが加わったことにより、特定のテーマやプラグインが上手く使えなくなる事象も過去に起きています。

日本国内の不動産物件を取り扱いやすくする某有料プラグインで不具合が起きたり、通販機能を追加するプラグイン「Welcart」はバージョン1系を使えというアナウンスを出していたり(https://www.welcart.com/documents/archives/5636)、そのサイトの根幹を担いそうなプラグインで、「それってどうなの?」と思う事例が発生しています。

対策としては、新たに「Enable jQuery Migrate Helper」プラグインを追加してバージョンを管理しろというもの(参考:https://mypacecreator.net/blog/archives/66305)。コアアップデートの齟齬を解消するために新たにプラグインを追加して対応するのは、あまり気持ちのいいやり方では無いように思います。主に管理画面向けとはいえ、パフォーマンスを落とす要因になったり、余計な脆弱性を増やす可能性もあるので、プラグインは最小限に留めたいというのが、開発者としての正直な意見ではないでしょうか。

Gutenbergが導入されると、今度は「AddQuickTag」が「Classic Editor」で使いにくくなり、Reactで実装される編集機能、ブロックを有効にするためなのか、コアアップデートをかける度に余計なコードが出力されたり、それを抑制するためのコードを探して対処するといったイタチごっこも発生しています。

カスタムプロパティを追加するCSSも取り扱いに気をつけないと、テキストリンクの色や下線を上書きされてしまい、意図しない表示になっているサイトやページも割と見かけます。デフォルトでサイトマップを生成するようになってしまったのも、プラグインとの兼ね合いでは抑制をかける必要がありますが、開発者以外で気づいていらっしゃる方はどれだけいるのだろうか、と他人事ながら心配になってしまいます。

コアの開発者やプラグイン、テーマに関わる方々が生み出したものを更に加工する程度の関わり方しかしていない立場ですが、どこも新しい機能の開発や変更に追従するのが精一杯で、細かいところまで気が回っていないというか、後方互換やら古くからの開発者のことを気にかける余裕はなくなりつつあるといった印象を受けてしまいます。

WordCampなどの活動も各地で継続中のようですが、以前ほどは日本語での情報発信は盛んではなく、携わっていた人たちはWordPressではない領域へ移動したり、REST APIだけ使う形に切り替えるなどして、そこまで熱を入れて関わっている人口はかつてほどではなくなっているのかもしれないなぁ、という肌感覚でもあります。

ただ、どれだけ目に見える人の動きが少なくなったところで、コアの開発やコミュニティは活発ですし、数あるオープンソースCMSの中ではシェアや規模が大きなエコシステムでもあるので、急に潰れてしまったり、使えなくなるといった可能性は低いでしょう。

代替を模索する必要はありますが、慌てて移行する必要もないだろうというのが、現段階の見立てです。

特定のテーマやプラグイン依存は避けたい

密かに激動の時代を迎えているWordPressなので、今の段階で何らかのテーマやプラグインに依存したサイト運営やカスタマイズというのは、できるだけ避けた方が良いと思います。特に、有料テーマの購入や、便利な拡張機能があるからといってプラグインに課金するのも、慎重になった方が良いでしょう。

今までも、有料テーマやプラグインにも関わらず、「急に使えなくなる」事例がチラホラ発生しています。買い切りだろうと継続課金だろうと、恐らく返金には応じてくれないと思いますし、クレジットカードでの決済の場合は、処理が煩雑になりそうな気もします。

テーマやプラグインの開発者として携わっていれば、WordPressの先行きが不透明なことは自明だと思われるので、今のタイミングで「テーマを買いませんか」や「限定機能を解除しませんか?」というオファーをかけるのは、正直どうなんだろうと思ってしまいます。

たかだか数千円、数万円で質の良いデザイン、コードを変えるならそれで良いというなら、それもまた合理的な判断だと思いますし、「長年使ってきたテーマだから」と著名な配布テーマを使って、その上では有効なカスタマイズを磨き込むのも良いでしょう。万が一が起きた場合、必死に取り組んできた時間や積み上げてきたものが無駄になったとしても、それも含めて自己責任ですから。

WordPressを取り入れたサービスを提供している立場から何か言えるとしたら、「純度100%のオリジナルテーマ」は推奨度合いが比較的高いといったところでしょうか。今なら、Gutenberg向けのブロック開発も有力な選択肢かもしれません。

何らかのテーマやプラグインが突然使えなくなっても問題ない環境を用意したり、技術の習得に励んだり。極端なことを言えば、いつかWordPressが使えなくなっても流用可能な技術、考え方を養っておくと、万が一が起きた場合でもレジリエンスを発揮しやすいはず。

幸い、WordPressやPHPは程よく枯れた技術であり、最先端のものではないので、JamstackやイマドキのSSG等の代替技術よりは調べやすいですし、不具合やコードについてChatGPT等の生成AIへ質問してみても、「使える答え」が返って来やすいでしょう。機械翻訳の精度も上がっているので、英語の質疑やコメントの応酬しか残っていない場合であっても、コピペで解読したり、必要な部分を掻い摘むことも簡単です。

筆者も先日、プラグインを使わずにメディアライブラリを呼び出して画像を選択するカスタムフィールド、独自のmetaboxの実装でChatGPTを頼り、無事に実装する段階まで辿り着けています。BBNではCF7を利用していますが、別件でAstro.js + PHPメールフォームを実装しているので、こちらの技術も流用すれば、CF7っぽいJavascript + Google Recaptha V3なメール送信も問題なく導入できるかと思います。

「WordPressじゃなくても良いじゃん」と言えそうなレベルまで、自分の手で作れる時代。配布がいつ終わるかもしれないテーマや、どこに脆弱性が発見されるかも分からないプラグインに頼るよりは、どこで何が起きているかが把握しやすい独自テーマ、オリジナルテーマの方が良いのではないかというのが、私の考えです。

HTMLやCSSを書き起こせるなら、テーマも作れる

何らかのデザインカンプや、Adobe XDやFigmaなどのデザインデータを元に、静的なHTMLやCSS、その上で用いるJavascriptを書けるなら、後はWordPress向けの機能やお約束に則りさえすれば、独自テーマは簡単に作れます。

どんな機能が作りたいか、どういうアプローチで作れば良いかが明確でないと難しかったり、参考にする情報が古かったり間違っていたりして、現在のバージョンでは非推奨とされるやり方を選んでしまう可能性はありますが、深い部分を全く見ずに既存テーマを弄るよりは、遥かに有用な取り組みです。

画像の呼び出し方が特殊だったり、テーマフォルダまでのパスを取得する方法が独特だったり、PHPの書き方、echoが必要な書き方とそうでない書き方が分かりにくかったり、返り値の違いで処理を変えるところが難しかったり、ifやループの閉じ方がややこしかったりはしますが、適切なエディタを選び、作り慣れていけば、だんだん分かって来ます。

まずは独自テーマで使うためのHTMLを固め、SassやES6を使ってCSSやJavascriptを書きたい場合は、Node.jsやタスクランナー等を使う環境を別途用意して出力させたりすれば、後はテーマフォルダ直下のstyle.css内のコメントを記述したり、functions.phpを用意したり、index.phpさえ準備してしまえば、事前に組み上げたHTMLをコピペしたり、CSSをコピペしたり別ファイルとして読み込んだり、Javascriptをwp_footer等で読み込むようにすれば、簡単に作れるでしょう。

開発しやすくするための方法や、パフォーマンスを向上させやすい書き方、開発しやすい方法といった応用技術もありますが、それらは基礎ができるようになってから徐々に枝葉を広げていけば良い話。自分の手でHTMLやCSS、Javascriptを書けるようなら、テーマをゼロから作ることに挑戦したって問題ないでしょう。

BBNは全てオリジナルテーマ

デモサイトもこのサイトも、制作事例として掲載しているどのサイトも。全て独自開発のオリジナルテーマを使用しています。最低限のプラグインとして、CF7やサイトマップ生成のプラグインを活用し、それ以外は管理画面向けのプラグインが中心です。キーワードやdescriptionの追加であれば、テキストベースのメタボックスを実装する形で対応しています。

特定の固定ページであれば、page-slug.phpを用意してslugを合わせてしまえば、管理画面で入力する手間を省けますし、CF7上で使う「zipaddr-jp」を動作させるために、do_shortcodeによる挿入ではなく、管理画面からショートコードとして埋め込む形も採用しています。

カスタムフィールドの「繰り返し」や、特定の投稿やカスタム投稿を選択する機能はプラグインを使った方がユーザー向けとしても便利だなと頼ることもありますが、ケースバイケースで独自実装に切り替えることもあります。

また、シングルページを使わないカスタム投稿を使ったり、一覧ページのURLに一手間加えるなど、通常のアプローチでは難しそうな実装も、数々クリアして来ました。

表示速度向上のために不要なコードの出力を抑え、CSSの読み込みでレンダリングブロックが起こらないように工夫したり、Javascriptは”type=module”を指定したり、pre_get_postsでは不要なページ送りを防ぐ”no_found_rows”をfalseに設定したり、見えにくいところで十重二十重に工夫を施しています。

デモサイトで使用しているテーマについては、元となるHTMLやCSSを開発するリポジトリや、WordPressテーマ自体のリポジトリを公開しているので、興味がある方は遠慮なくご利用いただいて、「ここがおかしいじゃないか」と批判していただいたり、プルリクエストやフォークなどもいただけると、全体として有益かと思うので、お力添えいただけますと幸いです。

使い勝手と安定運用の両立を目指して

BBNでは、長期的な安定運用を重視し、責任の範囲を明確にしたオリジナルテーマによるWebサイト制作と運用支援をご提供しています。表示速度と使いやすさを大切にし、プラグインの利用は最小限に抑えつつ、デフォルトで読み込まれるコードであっても、不要と判断したものは取り除く方針です。

特定のプラグインを入れた方が便利だとか、標準機能を抑制するのは不便だというご意見もよく分かりますが、様々な要因を加味した上でその都度取捨選択し、どうしても必要と判断した場合だけ部分的に解禁する運用体制を整えています。

Webサイトの目的や役割は、煌びやかに飾り立てて自己顕示欲や承認欲求を満たすことではなく、必要とする相手に情報をスムーズかつスピーディに届けることだと考えています。そのため、それを妨げるものは必要ないという判断し、必要な機能に絞ったサイト作り、テーマ作りを心掛けています。

今の時代に合わせた、本当に必要なWebサイトを構築したい方、安定したWordPressサイトを運用したい方は、是非BLUE B NOSEまでご相談ください。既存のWordPressテーマやサイトのパフォーマンス改善、自分たちでは解決しにくい問題へのご相談などもお待ちしております。

テーマ解説はこちらでも

BBNで使用しているテーマの仕様はこちらでも解説しています。導入しているTipsを解説した記事もありますので、そちらも合わせてご覧ください。

サンプル事例のテーマ、仕様概説

サンプル事例からリンクさせている独自テーマのリポジトリ。どんなコンセプトで、どんなフローを想定して構築し、どんな相手へ向けて公開しているのか、どんな機能を有しているのか。Github上のコードを見ればある程度分かるという方向けに、どんな構成でどんなことをしているのか、非常にざっくりとご紹介します。
長谷川 雄治
技術について

シェア・共有

長谷川 雄治
昭和63年生まれ。大阪電気通信大学 総合情報学部 デジタルゲーム学科卒。
2011年からWeb制作に従事。コーディングやWordPressのカスタマイズ等を主に経験を積む。2013年、仮面ライターとして独立開業。マーケティングや企画、上流も下流も幅広く対応。
コーディングとコンテンツ制作の同時提供を考えるヘンな人。
BLUE B NOSEでは開発等を担当。

関連記事

最新記事

人気記事

コストを抑えたWebサイト制作に最適 速くてリッチなWebサイトが、月額10,000円〜

メールでお問い合わせ ご利用の流れを確認する