Aki Hamano

WordPressの小ネタ集

この記事は、WordPress に関してもしかするとあまり知られていないかもしれない事を、とりとめもなく独断でまとめたものです。

特に、ここ数年 WordPress に触れておらず、今の WordPress はどうなっているのか? という事を知りたい方向けの情報も少し盛り込んでいます。

クラシックエディターはいつまで使えますか ?

Classic Editor プラグインの説明には、この記事を書いている時点で「Classic Editor は公式な WordPress プラグインであり、少なくとも2024年まで、または必要なくなるまでの間、完全にサポート・保守されます。」と記載されています。

それでは2025年以降、クラシックエディターが使えなくなる可能性があるのでしょうか ? 自分は、クラシックエディターは残り続けると思います。

ポイントは、「クラシックエディターが使えなくなる」という言葉には二つのニュアンスが含まれているという点です。

  • クラシックエディター「プラグイン」がサポート・アップデートされなくなる
  • WordPress コアから、クラシックエディターの機能が「廃止」される

確かに前者のプラグインについては、将来的にサポートされなくなるかもしれません。しかし、WordPress コアにクラシックエディターの機能が残っていれば、「クラシックエディターが使えなくなる」わけではありません。

クラシックエディタープラグインが行っている事を、自前で実装すればよいだけです。つまり、use_block_editor_for_post フックを使うという事です。

Classic Editor プラグインは継続的にダウンロードされています。また、WordPress は後方互換性を大事にしていますし、むしろクラシックエディターの機能を廃止する方が大変だと思うので、個人的にはクラシックエディターの機能は今後も残り続けると思います。

WordPress はいつアップデートされますか ?

約4か月ごと、多くの場合は4月・8月・12月にメジャーアップデートされます。

他の一般的なプロダクトの場合、次のメジャーアップデートで盛り込みたい機能、リリース元の方針、市場の動向等によりリリース・アップデートの時期が左右される場合があると思います。

しかし WordPress の場合は、そういった要因でリリース時期が左右されるわけではなく、期限ありきで開発が進められます。次のメジャーアップデートで達成したい事はあらかじめロードマップで宣言されはしますが、これら全てが次のメジャーアップデートでリリースされるとは限りません。不十分である、または期限に間に合いそうにない場合は、期限を延ばすのではなく、次のメジャーアップデート以降に持ち越されます。

そのため、WordPress で開発しているサイト等の公開時期が決まっていれば、「公開するときの最新 WordPress バージョンは X.X だろうな」と予測を立て、そのメジャーアップデートでリリースされる可能性のある機能に合わせて開発する事もできます。

WordPress のバージョン番号ってどうやってつけられていますか ?

ソフトウェアのバージョニングの方法の一つとして、「セマンティックバージョニング」というものがあります。これは、バージョン番号を X.Y.Z の三つの数字であらわし、X がメジャーバージョン、Y がマイナーバージョン、Z がパッチバージョンを表します。

一方 WordPress の場合は、「X.X.Z」形式でバージョンが表されます。つまり、1番目と2番目の番号がセットでメジャーバージョンを表し、3つ目の数字がマイナーバージョンを表します。2番目の番号が二桁になる事はなく、9の次は0となり、1番目の数字がインクリメントされます。これは、Gutenberg プロジェクト (Gutenberg プラグイン)でも同様です。

つまり、WordPress 5.9が6.0にアップデートされることも、6.0が6.1にアップデートされることも、どちらもメジャーアップデートで変わりはありません。

注意点としては、このバージョニングはあくまでも WordPress 本体に関してのことであり、テーマ・プラグインがこのバージョニングにのっとっておらず、セマンティックバージョニングを採用している場合もあるという事です。

また WordPress 関連の書籍で「WordPress 6.X対応版」といった表記が見られる場合があります。おそらくセマンティックバージョンの意味合いで「メジャーバージョンの6には対応しているよ」という事を伝えたいのかもしれませんが、WordPress のバージョニングと照らし合わせた場合に矛盾が生じます。例えば、書籍の執筆・校正時点での最新の WordPress バージョンが6.4だとして、「WordPress 6.X対応版」と記載されていた場合、まだリリースされていない6.5～6.9までも対応しているという事を意味してしまいますので、「この本は最新メジャーバージョンのWordPress6.4で確認したよ」というくらいの意味合いでとらえた方がよいかもしれません。

Gutenberg ＝ ブロックエディターですよね ?

厳密には異なり、定義としては「4つのフェーズを持ったプロジェクト名」です。

4つのフェーズは以下の通りです。

  1. より簡単な編集: WordPress ですでに利用可能で、継続的に改善されています
  2. カスタマイズ: 完全なサイト編集機能、ブロックパターン、ブロックディレクトリ、ブロックベースのテーマ
  3. コラボレーション: コンテンツを共同執筆するためのより直感的な方法
  4. 多言語対応: 多言語サイトのコア実装

フェーズ1はもちろんブロックエディターをあらわしますが、WordPress5.0がリリースされた当時はもちろんこのフェーズ1しかまだ実装されていなかったはずなので、その名残で「Gutenberg = ブロックエディター」というニュアンスで話される場合があるのではないかと思います。

ロードマップによると、フェーズ2 (カスタマイズ) は WordPress 6.3 で正式に終了し、フェーズ3 (コラボレーション) の検討が進行中とあります。この記事執筆時点では、最新の WordPress メジャーバージョンは6.4であり、Gutenberg プロジェクトでも既にフェーズ3に関する開発も始まっていますので、「Gutenberg プロジェクトは現在フェーズ3にいる」と言ってよいと思います。

WordPress サイトを制作したい時には、HTML / CSS / PHP が分かっていればいいんですよね ?

要件ややること/やりたいことによっては、それ以上の技術が必要となる場合があります。

例えば、ブロックエディターは React アプリです。そのため、独自のブロック (カスタムブロック) をフルスクラッチで開発しようと思った場合、もちろん React / JavaScript の知識が必要となります。また、ブロックエディターやコアブロックを「フック」してカスタマイズしたい場合は、add_filter や add_action など PHP のフックは使えませんので、addFilter や addAction などの JavaScript のフックを使用する必要があります。これらのフックの仕様と、React / JavaScript を理解している必要があります。

また、前述の Gutenberg プロジェクトのフェーズ3 (コラボレーション) の一環として、管理画面 (ダッシュボード) の刷新が予定されています。これはつまり、サイトエディターが React ベースであるように、ダッシュボードも React ベースになる可能性が高い事を意味しています。

自分の予想では、今後は WordPress テーマ・プラグイン開発においてますます JavaScript 力が必要になってくると思います。ダッシュボードが React 化されないようにする「Classic Dashboard」のようなプラグインももしかしたら登場するのかもしれません。

また自分はあまり詳しくありませんが、WordPress をヘッドレス CMS として扱いたい時は、フロントエンドに関わるより広範囲な技術が必要になる場合もあると思います。

不具合を見つけたのですが、どこに報告したら良いですか ?

不具合の報告先として、大きく以下の三つがあり、報告したい内容によって報告先が変わってきます。これらのルールに当てはまらない場合ももちろん多くありますが、大事な事は「重要だと感じた課題・問題をオープンな場に持っていく」ことだと思います。もし過去に同様の問題が報告されていたり、報告先が適切でなかったとしても、その報告を目にした経験のあるコントリビューターが、適切な報告先を案内してくれるはずです。

Core

WordPress Trac

WordPress コアは、「Trac」というプロジェクト管理ツールで課題が管理されています。ここに報告すべき問題は、例えば以下のようなものです。多くの場合、PHP に関する問題が多いと思います。

  • 特定のデフォルトテーマでエラーが出る、表示がおかしい
  • PHP のエラーメッセージが表示される
  • PHP の関数、フックに関わる問題
  • ダッシュボードに関わる不具合

Gutenberg

WordPress/gutenberg: The Block Editor project for WordPress and beyond. Plugin is available from the official repository.

Gutenberg プロジェクトは GitHubで管理されています。Core (Trac) では PHP に関する問題が多いと書きましたが、ここでは JavaScript に関連する問題が主に報告されます。

  • ブロックエディターの問題
  • サイトエディターの問題

Slack

Slack への参加方法 – サポートフォーラム – WordPress.org 日本語

WordPress では、コミュニケ―ションツールの一つとして Slack が使われています。日本 のコミュニティ用の Slack も存在し「WordSlack」と呼ばれています。例えば、WordPress のサイト言語を日本語にした場合の誤訳、不自然な翻訳文を見つけた場合は、この WordSlack に参加し、いずれかのチャンネルで報告すると良いと思います。

アップデートすれば直ると思っていた不具合が直っていない !

その不具合は適切な方法で報告しましたか ?

もちろん開発は人の手で行われますので、その不具合がオープンな場で報告され、検証され、それを修正するコードを誰かが書かない限り、不具合は修正されません。

前述の「不具合を見つけたのですが、どこに報告したら良いですか?」を参考に、「もしかしたら不具合かも ?」と思った事は遠慮せずに報告していただくとよいかと思います。

リリースパーティってどこで開催されるのですか ?

パーティとは呼ばれますが、リリースされる事を祝ってオフラインで開催されるパーティという事ではありません (地域のコミュニティで、そういうイベントは別で開催される事もあるかもしれませんが)。Slack でテキストベースで行われる、リリースタスクを進める事自体がリリースパーティと呼ばれます。

WordPress のメジャーアップデート正式版がリリースされる時、Beta / RC 版がリリースされる時に開催されます。ホスト、そのメジャーリリースのリリースリード、コントリビューター等が決められた時間に Slack の #core チャンネルに集まり、ブロッカーや不具合がない事をテストしながらリリース作業が進められます。

日本時間だと大体深夜2～3時から始まる事が多いので大変ですが、興味がある方はぜひ一度参加してみて、さらにテストにも協力してみて下さい。

なぜ WordPress では今も Subversion (SVN) が使われているのですか ?

WordPress がリリースされてから20年が経ちましたが、当初から SVN を使用していたという歴史的経緯があるのだと思います。

ただし、WordPress リポジトリの Git ミラーが GitHub 上に存在し、GitHub 上でプルリクエストを提出できます。このプルリクエストはあくまでもコードレビューのためであり、マージはされずクローズされます。最終的には、WordPress の SVN リポジトリへのコミット権限を持ったコアの「コミッター」の方が、そのパッチをコミットします。

なお Gutenberg プロジェクトは GitHub 上で開発されており、承認されたプルリクエストはメインブランチにマージされ、次の WordPress メジャーリリースの ベータ1フェーズの前に、WordPress コアにバンドルされるという仕組みになっています。

テーマを作る時は index.php とかを作るんですよね ?

テーマの種類によっては、必ずしもそうではありません。

index.php が必須であり、さらに各ページテンプレート PHP ファイルをテーマファイル内で定義していくのは、「クラシックテーマ」の場合です。

「ブロックテーマ」の場合は、テーマディレクトリに templates/index.html (と style.css) さえあればテーマとして認識されます。index.html の内容はサイトエディター内で更新出来るので、テンプレートとして空であっても問題ありません。また、各ページテンプレート自体もサイトエディター内で作成できます。

大きく分けると、現在のテーマの種類としては「ブロックテーマ」「クラシックテーマ」「ハイブリッドテーマ」の三種類があります。それぞれのテーマによって、テーマ自体の作り方も大きく変わってきますので、Web サイト・書籍でテーマ開発を学習される場合は、「どのテーマの種類の事を言っているのか」を理解しておくことが重要だと思います。

なお WordPress コアでは、デフォルトテーマは既にブロックテーマとなっています。直近でリリースされた WordPress6.4には、ブロックテーマとしては三つ目のデフォルトテーマとなる「Twenty Twenty-Four」がバンドルされています。

theme.json って何ですか ?

テーマのグローバルな設定、スタイルなどを定義できる構成ファイルです。 このファイルは、ブロックテーマとクラシックテーマの両方で利用出来ます。

例えば、テーマに何らかの機能をオプトインしたい場合に add_theme_support() を使うと思いますが、多くの同様の機能を theme.json でもオプトイン出来ます。さらにグローバルな設定だけでなく、ブロック単位での機能 (ブロックサポート) のオプトイン/アウト、ブロック・要素単位でのスタイル定義など、出来る事はメジャーアップデートを重ねるにつれ広がっています。

ただし、既存のテーマに theme.json を追加する場合は注意が必要です。theme.json の有無によって、特にエディター側でのレイアウト関連のスタイルが大きく変わるため、既存テーマの CSS の調整が必要になる場合があります。

Global Settings & Styles (theme.json) – Block Editor Handbook | Developer.WordPress.org

Dev note とは何ですか ?

次のメジャーリリースにおいて、主に開発者向けの技術的な変更を記した記事のことです。Dev note は複数投稿され、それらをまとめたものが「フィールドガイド」として、正式版リリース前のベータフェーズの頃に Make WordPress Core ブログに投稿されます。

非常にボリュームがあり、もちろん英語の記事となりますが、WordPress 開発に関わっている場合はメジャーリリース前に必ず一読し、必要に応じて対処しておくことをおすすめします。

ローカル環境を構築するのが大変なのですが…

以前と比べてローカル環境を構築する事がずっと便利になっており、いくつかのツールを紹介します。

wp-env

@wordpress/env | Block Editor Handbook | WordPress Developer Resources

Docker ベースのツールで、npm パッケージとして公開されています (@wordpress/env)。パッケージのインストール後に、開発するテーマ・プラグインディレクトリで wp-env start コマンドを実行すると、現在のそのテーマやプラグインがインストール・有効化された状態で WordPress 環境が起動し、http://localhost:8888 でアクセス出来ます。

環境の停止・削除・再起動などもこの wp-env コマンドで実行できます。また、.wp-env.json、またはそのファイルを上書きする .wp-env.override.json ファイルで、環境をカスタマイズする事もできます。

Playground

WordPress Playground (playground.wordpress.net/

いわゆる「Web ブラウザ上で WordPress を動かせる」ツールで、WebAssembly がベースとなっているツールです。WordPress 環境を構築する場合、基本的に OS、Web サーバー、データベース、PHP 実行環境が必要になりますが、ブラウザ内で WordPress 環境が完結しており、それらを構築・準備する必要がありません。

注: 「Web ブラウザ上で WordPress を動かせる」とありますが、もちろん Playground 自体をホストする必要があります。playground.wordpress.net がその一つですが、独自に Payground をホストする事もできます。

wp-now

playground-tools/packages/wp-now at trunk · WordPress/playground-tools

wp-env 同様、ローカル環境を起動するための CLI ツールですが、こちらは前述の Playground がベースとなっています。

Categories

Events