WordPress 5.8の新機能（フルサイト編集、WebP画像、グローバルスタイル、グローバル設定など）

WordPress 5.8 は記念すべきリリースとなるでしょう。信じられないほどの数の機能、改善、バグ修正に加えて、WP 5.8 は、「フルサイト編集」という広範なプロジェクトの最初の機能も提供することで、ウェブサイトを構築する新しい方法を導入します。

フルサイト編集以外にも、WordPress 5.8 は本CMSのいくつかの画面での数多くの変更と機能強化をもたらします。

Gutenbergプラグインを今まで使用しなかったWordPressユーザーは、Gutenbergの9つのリリースのすべての機能や改善点を一気に勉強することになります（各リリースの詳細については、Gutenberg 9.9、10.0、10.1、10.2、10.3、10.4、10.5、10.6、10.7を参照してください）。

サイトのパフォーマンスを重視するユーザーにとってのもう一つの重要な新機能は、WebPフォーマットのサポートです。

そして、IE11がサポートされなくなること、theme.jsonをベースにした新しいブロック構成とスタイリングのメカニズム、block.jsonをベースにした改良されたブロック登録システム、2021年のWordPressのフェーズ2のAPI関連の多くの改良などが、開発者のユーザーはきっと気に入るでしょう。

ここでは、今後数ヶ月の間にリリースされる予定の新しい強力なサイト構築ツールへの道を開く、機能や強化点を長々と紹介していきますので、是非とご覧ください。

WordPress 5.8 のフルサイト編集機能

フルサイト編集のビジョンは、WordPressユーザーがブロックを使ってウェブサイト全体を構築できるツールや機能の組み合わせを提供することです。フルサイト編集では、ナビゲーションメニュー、サイトブランディング、サイドバーのウィジェット、テンプレートなど、ページ上のあらゆる要素を作成できる多くのブロックが用意されています。

WordPress 5.8 にフルサイト編集（FSE）の機能の一部が導入されたとしても、完全な機能を備えたビジュアルサイト構築環境がまだ提供されないでしょう。FSE はまだ完成しておらず、WordPress 5.8 のリリースは「パブリックベータ段階」にあたります。Josepha Haden Chomphosyはこう述べています。

「フルサイト編集」は複数のプロジェクトで構成されており、1回のリリースでは実現できないほどの大きな変化をもたらします。最も重要なことは、完全なユーザーエクスペリエンスとしてリリースされるわけではないということです。フェーズ1のマージプロセスの際に出た最も明確なフィードバックの1つは、エクステンダー（エージェンシー、テーマ作者、プラグイン開発者、サイト構築者など）が今後の変更に備えるための十分な時間がなかったというフィードバックでした。

この点を考慮し、今回のマージプロセスはオン・オフの切り替えではありません。WordPress 5.8の時点での焦点は、完全なユーザーエクスペリエンスではなく、オープンパブリックベータ版なのです。

したがって、すぐに完璧なFSEエクスペリエンスを期待してはいけません。バージョン 5.8 から時間をかけて新機能が徐々に追加・改善されていきます。同じ理由で、WordPress 5.8は、私たちが慣れ親しんだウェブサイトの構築プロセスに劇的な影響を与えることはないと推測されます。

執筆時点では、サイトオーナーや管理者は、Twenty-Twenty One Blocks（Twenty-Twenty Oneのブロック版）などのブロックテーマをインストールし、Gutenbergプラグインを有効にすることで、意識的にFSEを選択する必要があります。

フルサイト編集には、サイトエディタ、グローバルスタイル、クエリブロック、ナビゲーションブロック、テンプレート、ブロックテーマなど、さまざまなサブプロジェクトが含まれています。後述するように、WordPress 5.8 のフルサイト編集に最も近い機能は、テンプレート編集モードと、そのモードで使用できるテーマブロック機能です。

次に、WordPress 5.8でコアに統合されたFSEの機能をご紹介します。

テンプレート編集モード

テンプレート編集モードでは、ブロックを使って記事やページのテンプレートを作成することができます。これは、サイト構築の複雑さを軽減するための素晴らしい方法で、ユーザーはブロックの操作に慣れながら、サイトエディタのインターフェースに入らずにいくつかのサイト編集機能を利用することができます。また、ブロックベースのテーマを使用していなくても、ブロックエディタのUIから簡単にテンプレートを作成して編集したいユーザーにも最適な機能です。

WordPressのテーマのカスタマイズはこれまで異常に簡単になりました。もう、カスタムテンプレートを作るために子テーマを作る必要はありません。WordPress 5.8 では、テンプレート編集はブロックテーマに限らず旧テーマでも利用できますが、旧テーマで有効にするにはオプトインが必要です。

新しいテンプレートを作成するには、「設定」サイドバーの「テンプレート編集モード」を有効にするだけでOKです。ユーザーが編集モードを切り替えられるように、新しい「テンプレート」パネルが用意されています（Gutenberg 10.5のリリースノートを参照）。

「テンプレート」パネルでは、新しいテンプレートを作成したり、既存のテンプレートを編集することができます。

新しいテンプレートを作成するには、「新規」をクリックします。次に、モーダルにテンプレート名を入力し、「作成」をクリックすれば完了です。

テンプレート編集モードでは、サイトタイトル、サイトタグライン、ログイン・ログアウトなどのFSEブロックを含む、すべてのブロックを使ってテンプレートを構築することができます。

編集内容に満足したら、下の画像のように、投稿編集モードに切り替えて、テンプレートを記事やページのコンテンツとは別に保存することができます。

テンプレートは、「wp_template」というカスタム投稿タイプとして、WordPressのデータベースに保存されます。これにより、エディタインターフェイスからテンプレートを編集できるだけでなく、インポートやエクスポートも自由にできます。また、1つのテンプレートを複数のウェブサイト間で使用することもできます（執筆時点では、この機能はGutenbergプラグインを有効にした場合にのみ利用できます）。

Exporting Templates and テンプレートやテンプレートパーツのエクスポートTemplate Parts. — テンプレートやテンプレートパーツのエクスポート

こちらのテスト依頼やJustin Tadlockによるこの実験で報告されているように、執筆時点ではテンプレート編集モードにはまだバグがあるようです。

しかし、テンプレート編集モードがウェブサイトの外観をカスタマイズする仕事をどのように変えるかを完全に理解するために必要なのは、主要な問題が修正されるまでの少しの忍耐だけです。

開発者のスキルがなくても、レイアウトやウェブサイトの全体的な外観を完全にコントロールできるようになります。

テンプレート編集モードは当初、ブロックテーマと旧テーマの両方で利用可能でした。5.8のリードチャンネルでの思慮に満ちた議論の結果、テンプレート編集モードを旧テーマではオプトイン、ブロックテーマではオプトアウトにすることが決まりました（pull #32858も参照）。

Carolina Nymarkはこう述べました。

当初、テンプレート編集機能はすべてのテーマで有効でした。しかし、テーマ開発者からは、この新機能に対応するために、既存の旧テーマをすべて更新することができないという懸念が寄せられました。そこで、リリースチームとエディターチームは、テ旧テーマではンプレート編集機能をオプトインにすることを決定しました。

旧テーマでオプトインするには、開発者はテーマサポートを追加する必要があります。

add_theme_support( 'block-templates' );

theme.jsonを使っている旧なテーマでは、テーマサポートを削除することでオプトアウトできます。

remove_theme_support(  'block-templates' );

WordPress 5.8 でのテンプレート編集モードの仕組みや便利な使用例については、Anne McCartyのビデオをご覧ください。

テーマブロック

前述のように、FSEは単一の機能ではなく、サイトエディター以外のサイト構築機能も含めた機能のセットです。テンプレート編集モードは、まさにその一例と言えるでしょう。WordPress 5.8 では、テンプレート編集モードに加えて、データベースから動的に取得した情報を表示できる多くのテーマブロックも導入されてます。これらのブロックの中には、FSE以外のコンテキストでも使用できるものもあります（issue#28744参照）。

WordPress 5.8以降で、FSE以外のコンテクストでも利用可能なフルサイトエディタブロック

テーマブロックは、旧テーマにテンプレートタグ機能を導入したもので、通常のブロックと同じように使うことができます。例えば、投稿タグや投稿のアイキャッチ画像を、投稿コンテンツやテンプレートの任意の場所に追加することができます。WordPress 5.8 でコアに追加されたテーマブロックの数を知るには、ブロックプレースホルダーに「/post」と入力してください。

WordPress 5.8 で利用できる便利なテーマブロックの一つはログインとログアウトのリンクを提供するログイン・アウトブロックです。オプションで、リンクの代わりにログインフォームを表示することもできます。サイト管理者は、リダイレクト先をカスタマイズすることもできます（PR #29766を参照）。

FSEブロックの詳細については、Githubの「旧テーマでのフルサイトエディタブロックの有効化」を参照してください。

クエリーループブロック

ブログ投稿やカスタム投稿タイプのカ専用リストを表示する必要があるという状況に何度遭遇したことがあるのでしょうか？商品、イベント、不動産などを考えてみてください。もちろん、そのためのプラグインはたくさんありますが、高度にカスタマイズされたクエリを作成するためには、WordPressのループの知識が必要になることもよくあります。

WordPressのコアにクエリーループブロックが導入されることで、サイトオーナーや管理者は、複雑なコードを書いたり、開発者を雇ったりすることなく、少なくとも一般的なユースケースでは、投稿やCPTのリストを作成できるようになります。

では、クエリーループブロックの機能は何でしょうか？

簡単に言えば、WordPressのループと同じ機能ですが、その機能をブロックエディタの視覚的なコンテキストの中で果たします。

クエリーループブロックは、ユーザーの設定に基づいて WordPress データベースにクエリを実行し、取得した各投稿をループして、ページにデータを表示します。

集中的な開発の結果、このブロックは現在の構造になり、「クエリー」ブロックと「投稿テンプレート」ブロックの2つのサブブロックで構成されています。

高度な機能であるクエリループブロックには、構成が必要です。

まず、カルーセルまたはグリッドで表示するブロックのパターンを選択できます。パターンを選んだら、「選択」をクリックするだけで、クエリーループブロックがカスタムの投稿リストを生成します。

「白紙から始める」をクリックすると、「タイトルと日付」、「タイトルと抜粋」、「タイトル、日付、抜粋」、「画像、日付、タイトル」というコアブロックの4つのバリエーションのリストが表示されます。（「ブロック設定でパターンを提供する」を参照）。

クエリーループブロックを選択すると、ブロック設定のサイドバーが表示され、そこでクエリーを作成することができます。クエリーのパラメータをURLから取得することもできますし、リストに表示投稿タイプ、表示順、スティッキーポストの有無など、クエリの引数をカスタマイズすることもできます。

また、カテゴリー、作成者、キーワードなどのフィルターを設定することもできます。

さらに、ブロックツールバーの「表示設定」ボタンでは、1ページあたりの項目数、オフセット、表示する最大ページ数などの設定ができます。

クエリーループブロックは確かに、強力なツールで、サイトオーナーは高度にカスタマイズされた投稿リストやカスタム投稿タイプを作成することができます。

しかし、WP_Queryクラスのパラメータを見てみると、コードを使用したカスタマイズのレベルは、クエリーループブロックを使用したカスタマイズよりもはるかに細かいことがわかります。

とはいえ、多くのユースケースに対応できる貴重で柔軟なツールであることは間違いありません。今後もさらなる機能強化が期待されます。

投稿エディタで永続的なリストビュー

投稿エディタに拡張されたもうひとつのFSE機能は、永続的なリストビューです。WordPress 5.8（およびGutenberg 10.7）以前は、リストビューはポップオーバーで表示されていました。フォーカスをポップオーバーの外から離すと、リストが消えてしまいました。

逆に、サイトエディタでは、ブロックツリー全体を含むサイドバーにリストビューが表示されていました。

WordPress 5.8 では、リストビューは投稿エディタのサイドバーに表示されるようになり、ユーザーはブロックツリーをより素早く正確にナビゲートできるようになりました。

リストビューのアイテムをクリックすると、リストの項目がハイライトされ、フォーカスが投稿エディターの該当するブロックに移動します。さらに、リストビューの項目にカーソルを合わせると、その項目と投稿エディタの該当するブロックの両方がハイライトされます。

最後になりますが、ブロックにアンカーを追加すると、リストビューの該当する項目の横にもアンカーが表示されます。

このようにリストビューが強化されたことで、複雑なドキュメントの操作がより簡単になります。

ブロックをベースにしたウィジェットエディタ、カスタマイザーのブロックウィジェット

「ブロックをベースにしたウィジェットエディタ」は、ブロックエディタのインターフェイスを旧テーマのウィジェットに導入することを目的とした幅広いプロジェクトです。

新しいウィジェットエディタは、いまだに旧テーマを使用している大多数のユーザーに多くのメリットをもたらします。同時に、ブロックインターフェースがすべてのWordPressユーザーにとって標準となる前に、そのブロックインターフェースに慣れることができます。

Anne McCartyが指摘したように、ブロックをベースにしたウィジェットには以下のような利点があります。

サイドバー、ヘッダー、フッターに、カラム、セパレーター、スペーサーなどのデザインブロックを使ってレイアウトを作成できるようになりました。
カスタムコードを追加したり、サードパーティ製のHTMLエディタをプラグインで埋め込んだりしなくても、ウィジェットがデフォルトでリッチテキスト編集に対応するようになりました。
ショートコードをベースにしたウィジェットの多くがブロックとして利用できるようになり、編集作業が効率化されました。

Andrei Draganescu は、ブロックをベースにしたインターフェースからウィジェットを編集できることのメリットも強調しています。

ウィジェット機能をブロックにアップグレードする主な利点は、サイトの固定ページや投稿を編集するときに使用する使い慣れたブロック操作を使って、ウィジェットを直接編集できるようになることです。ブロックを使えるようになると、コードのないミニレイアウト、コアブロックやサードパーティ製のブロックの膨大なライブラリを活用したコンテンツ作成など、新しいクリエイティブな可能性が広がります。

WordPress 5.8 でウィジェットが使えなくなるのではないかと心配する必要はありません。コミュニティは、「既存のウィジェットやサードパーティ製のウィジェットは引き続き動作し、ブロックと一緒に使用することができるように」その後方互換性を確保するために努力してきました。（「WordPress 5.8 のブロックをベースにしたウィジェットエディタ」を参照）。

ただし、既存のWordPressインストールで換性の問題が発生しないように、本番のサイトを更新する前にステージング環境で新バージョンをテストすることをお忘れなく。

今すぐブロックをベースにしたウィジェットエディタを使わないという方のために、従来のウィジェット画面を復元するための方法は3つあります。

公式のClassic Widgetsプラグインをインストールすると、ウィジェット画面の以前のインターフェースを復元することができます。このプラグインは「早くとも2022年まで、または必要な限りサポートされ、維持されます」。
テーマ開発者は、通常通りテーマサポートを削除することで、ブロックをベースにしたウィジェットエディタを無効にすることができます。
remove_theme_support( 'widgets-block-editor' );
新しいuse_widgets_block_editorフィルタも利用可能です。
```
add_filter( 'use_widgets_block_editor', '__return_false' );
```

「ウィジェットブロックエディタの概要」の「旧ウィジェットエディタの復元」もご参照ください。

カスタマイザーにブロックウィジェットが登場

同じプロジェクトの一環として、WordPress 5.8ではカスタマイザーにブロックウィジェットが追加されました。

カスタマイザーにブロックをベースにしたウィジェットを追加するのは、とても簡単です。ウィジェットパネルの右上にあるプラスのアイコンをクリックすると、「カスタマイズウィジェットインサーター」が起動します。

次の画像のように、ウィジェットパネルの下部から「クイックインサータ」ーを起動することもできます

執筆時点では、新しいウィジェット編集インターフェースにはまだ改善やバグ修正が必要ですが、カスタマイズの可能性はほぼ無限大です。

WordPress 5.8 がリリースされると、カスタマイザーにブロックエディタの力が加わり、高度にカスタマイズされたサイドバーを手間なく構築することができるようになります。

「ブロックをベースにしたウィジェットエディタの開発メモ」では、ブロックベースのウィジェットエディタのより詳細な概要と、開発者向けの例やリソースを紹介しています

ブロックエディタの機能と改善点

WordPress 5.8 では、FSE の一部の導入に加えて、ブロックエディタのいくつかの要素に新機能と改良が加えられるため、全体的なユーザーエクスペリエンスが大幅に向上します。

これらの変更点は以下の通りです。

メディア＆テキストブロックの機能強化

ブロックをカラムブロックに変換することは、これまでも可能でした。しかし、カラムブロックに変換されたブロックはすべて1列で表示されます。このため、通常は1列での表示が適さない「メディア＆テキストブロック」では、最適でない結果になる可能性があります。

WordPress 5.8（およびGutenberg 10.2）以降は、メディア＆テキストブロックをカラムブロックに変換すると、画像用とテキスト用の2つの列が自動的に追加されます。

再利用可能なブロックの改善

再利用可能なブロックでは、ブロックやブロックグループを保存して、後でウェブサイトの任意の投稿や固定ページで再利用することができます。これは、同じブロックやブロックグループを複数の投稿や固定ページで繰り返し使用する場合に便利です。

WordPress 5.8では、再利用可能なブロックが視覚的に明確になた為、管理しやすくなりました。

WordPress 5.8 にアップデートしてから利用可能になる再利用可能なブロックの新機能は次の通りです。

再利用可能なブロックを作成する際、モーダル画面でブロックの名前を指定できるようになりました。
再利用可能なブロック名は、ブロックツールバー、ナビゲーションリスト、パンくずリストに表示されるようになりました。
子ブロックを選択すると、再利用可能なブロックがアウトライン化されるようになりました。これにより、親ブロックとそのコンテンツを簡単に識別できるようになり、操作性が大幅に向上しました。
サイドバーのインスペクタでブロック名を変更できるようになりました。

ロックツールバー構成の標準化

ブロック間での一貫したUIを提供し、ユーザーエクスペリエンスを向上させるために、いくつかのロックツールバーの構成が標準化されました。ツールバーは、「メタ、ブロックレベル、インライン」の順で表示されるようになりました。

Gutenberg 10.1および Gutenberg 10.3がリリースされてから、多くのブロックツールバーが標準化されました。例えば、画像、ボタン、リスト、見出し、段落、引用、オーディオ、ファイル、メディア＆テキスト、ビデオなどです。

Matias Venturaがこう述べています。

メタ、ブロックレベル、インラインというツールバーにあるセマンティックなグループ化は、ボーダーでも表現するべきです。現在、ブロックレベルの各コントロールは異なる表現になっています。例えば、ナビゲーションのようにすべてのコントロールにボーダーがある場合もあります。

そのため、WordPress 5.8以降のブロックツールバーでは、コントロールをボーダーで囲まれたセグメントにまとめています。さらに、

メタセグメントには、ブロックスイッチャー、ドラッグハンドル、ムーバーコントロールなどのブロックタイプのコントロールが含まれています。
ブロックレベルセグメントには、段落ブロックの配置や画像ブロックのリンクなど、コンテンツ全体に影響を与える特定のブロックツールが含まれています。
インラインレベル／その他のセグメントには、テキストブロックでのインラインフォーマットなど、インライン変換ツールが含まれます。
その他メニューには、追加のツールがあります。

下の画像は、WordPress 5.7 と 5.8 の画像ブロックツールバーを比較したものです。

WordPress 5.7 と WordPress 5.8 の画像ブロックツールバー

トップツールバーの改善

以前のWordPressでは、トップツールバーモードを有効にすると、以下の画像のようにトップツールバーとブロックツールバーが並んで表示されていました。

WordPress 5.8 では、トップツールバー表示を有効にすると、ブロックツールバーがエディタの最上部、トップツールバーの直下に固定されます。これはブラウザの幅とは無関係に行われるため、ユーザーエクスペリエンスが大幅に向上するはずです。

今回の機能強化では、ツールバーの API が<BlockTools />コンポーネントに統一され、開発者にとっても大きな変化をもたらします（PR #31134参照）。

埋め込みPDF

ファイルブロックを使ってPDFファイルがドキュメントに追加された場合、新しいサイドバーのトグルで、#30857埋め込みPDFバージョンの有効化/無効化ができるようになりました（PR #30857参照）。

ファイルをエディタのキャンバスに直接ドラッグアンドドロップするか、ライブラリから選択するだけでOKです。また、PDFビューアの高さを手動で調整したり、サイドバーコントロールを使って調整することも可能です。

PDFビューアは、モバイルブラウザを除き、すべての主要ウェブブラウザでサポートされています。

デュオトーンブロックのサポート

WordPress 5.8でコアに追加された最も興味深い機能のひとつが、Gutenberg 10.6で導入されたデュオトーンフィルターです。

「ブロックサポート」機能として利用できるデュオトーンフィルターは、コアの画像ブロックとカバーブロックではデフォルトで有効になっています。ただし、カバーブロックでは、固定背景では機能しません。

画像とカバーブロックのツールバーに、「デュオトーンフィルターの適用」というコントロールが表示され、多くのプリセットを選択できるデュオトーンピッカーが表示されるようになりました。

2つのサブコントロールにより、シャドウとハイライトを別々にカスタマイズできます。効果は、インラインスタイルで隠されたSVGフィルタとして、特定のクラス名を使用して適用されます。

この新しいツールに加えて、新しいcolor.__experimentalDuotoneプロパティも導入されます。これで、開発者はblock.jsonファイル内のブロックまたはブロックの一部にデュオトーンフィルタを追加することができます（詳細はカラーオブジェクトのリファレンスを参照）。

supports: {
	color: {
		__experimentalDuotone: '> .duotone-img, > .duotone-video',
		background: false,
		text: false
	}
}

あるブロックがcolor.__experimentalDuotone対応である場合、style属性を使ってカスタムのデフォルトカラーを設定することができます。

attributes: {
	style: {
		type: 'object',
		default: {
			color: {
				duotone: [
					'#FFF',
					'#000
				]
			}
		}
	}
}

下の画像は、同じ画像に2種類のデュオトーン効果を適用したものです。

開発者は、theme.jsonファイル（次のセクションを参照）で、以下のようにデュオトーンのプリセットも定義できます。

{
"version": 1,
"settings": {
	"color": {
		"duotone": [
			{
				"colors": [ "#000", "#7f7f7f" ],
				"slug": "black-and-white",
				"name": "dark-grayscale"
			}
		],
	...

デュオトーンフィルターの詳細については、「デュオトーンフィルターで画像に色付け」をご覧ください。

テーブルブロックの色とボーダーの設定

WordPress 5.8 では、テーブルの背景色と前景色をより細かく管理できるようになることなど、テーブルブロックも大幅に改善されます。

それに、テーブルブロックには、「ボーダーブロックのサポート」も追加され、ボーダーの色、スタイル、幅をコントロールできるようになりました。

ご利用中のテーマがこの新機能をサポートしている場合、新しい「ボーダー設定」パネルには、ユーザーがカスタマイズできる3つの新しいコントロールが表示されます。

開発者の方は、以下のコードをtheme.jsonファイルに追加することで、テーマにボーダーブロックへの対応を追加することができます。

"border": {
	"customColor": true,
	"customStyle": true,
	"customWidth": true
}

ブロックインサータの改良点

WordPress 5.8 では、ブロックインサータが複数の機能が追加され、強化されました（PR #26938および#21080）。

1.ブロックインサータでの2次元キーボードナビゲーション。より正確に、より直感的にブロック間を移動できるようになりました。

上矢印（↑）と下矢印（↓）を押すと、上下の行にフォーカスが移動します。
また、TabキーまたはShift+Tabキーを押すと、検索ボックス、タブリスト、各カテゴリーの最初の項目の間でフォーカスを移動できます。

2.フルサイト編集のインサーターに、テンプレートのパーツやバリエーションのための新しい「テーマ」カテゴリーが表示されるようになりました（PR #30020参照）。

3.オートコンプリートのマッチング機能で複数の単語にマッチングするようになりました（PR#29939を参照）。

ブロックエディタのその他の改善

WordPress 5.8 では、短くても述べる価値のある小・中規模の変更が数多く追加されています。その中でも、以下のような機能強化が挙げられます。

カバーブロックでのドラッグ＆ドロップ対応

デスクトップから画像をドラッグ＆ドロップして、カバーブロックの背景を置き換えることができるようになりました（Gutenberg 10.3およびPR #29813を参照）。

公開UIの強化

WordPress 5.8以降、公開UIにサイトのアイコンとタイトルが表示されるようになり、投稿や固定ページの公開先が明確になりました（Gutenberg 10.4）。

この改善は、フルスクリーンモードで作業している場合や、モバイルデバイスで作業している場合に有益です。

theme.jsonでのブロック設定とスタイル

WordPress 5.8 では、the theme.jsonファイルが「設定の中心点」となり、テーマ開発者に、エディタの設定やスタイルをカスタマイズするための新しい方法を提供します。

theme.json ファイルを使って、テーマにカスタムプリセットを設定したり、デュオトーンやテーブルボーダーなどの新機能のサポートを追加することができます（「グローバル設定とスタイル」を参照）。

André Maneiroがこう述べています。

この新しいメカニズムは、これまでエディタの制御に必要だったさまざまなadd_theme_support呼び出しを統合することを目的としています。

例えば、以下のコードでカスタムデュオトーンのプリセットをグローバルに設定することができます。

{
	"version": 1,
	"settings": {
		"color": {
			"duotone": [
				{
					"colors": [ "#000", "#0FF" ],
					"slug": "black-cyan",
					"name": "Black Cyan"
				}
			],

これにより、デフォルトのプリセットが上書きされ、デュオトーンのオプションが1つだけ表示されます。

新しいメカニズムでは、グローバルまたはブロック単位で設定を制御することができます。例えば、次のようなプリセットを theme.json ファイルに追加することで、12px のカスタムフォントサイズをグローバルに追加することができます。

{
	"version": 1,
	"settings": {
		"typography": {
			"customLineHeight": true,
			"fontSizes": [
				{
					"slug": "extra-extra-small",
					"size": "12px",
					"name": "Extra extra small"
				},
				{...}

この結果、ユーザーはコンテンツ内の任意のテキストにこの新しいフォントサイズを利用できるようになります。

段落ブロックだけをカスタマイズしたい場合は、コードが若干異なります。

{
	"version": 1,
	"settings": {
		"blocks": {
			"core/paragraph": {
				"typography": {
					"fontSizes": [
						{
							"slug": "extra-extra-small",
							"size": "12px",
							"name": "Extra extra small"
						},
						{
							"slug": "extra-small",
							"size": "16px",
							"name": "Extra small"
						},
						{
							"slug": "small",
							"size": "18px",
							"name": "Small"
						},
						{
							"slug": "normal",
							"size": "20px",
							"name": "Normal"
						},
						{
							"slug": "large",
							"size": "24px",
							"name": "Large"
						}
					]
				}
			}
		}
	}
}

以上です！これで、カスタムフォントサイズのプリセットの段落ブロックへの設定は完了しました。

コアブロックは新しいメカニズムに従うように更新されていますが、サードパーティ製のブロックはReactのuseSettingフックを使って新しいメカニズムに対応することができます（この関数についての詳細は開発メモおよびAPIドキュメントをご覧ください）。

const isEnabled = useSetting( 'spacing.margin' );

theme.jsonファイルをベースにした新しいメカニズムは、ブロック設定だけに適用されるわけではありません。WordPress 5.8 以降、エディタのスタイルを作成してエンキューする必要はなくなります。theme.jsonファイルを使ってプリセットを宣言するだけで、エンジンがクラスを生成し、エディタとフロントエンドの両方で自動的にエンキューします。

対応するCSSカスタムプロパティもエンジンがによって生成されます。

上記の例では、段落ブロックに5つのfontSizesプリセットを設定しました。そのプリセットに対して、以下のCSSカスタムプロパティが生成されます。

p {
	--wp--preset--font-size--extra-extra-small: 12px;
	--wp--preset--font-size--extra-small: 16px;
	--wp--preset--font-size--small: 18px;
	--wp--preset--font-size--normal: 20px;
	--wp--preset--font-size--large: 24px;
}

theme.jsonファイルで段落のフォントサイズを設定すると、対応するp 要素は has-{preset-slug}-{preset-category}クラスになります。

つまり、extra-extra-smallフォントサイズの段落は、has-extra-extra-small-font-sizeクラスになります。

<p class="has-extra-extra-small-font-size">Lorem ipsum dolor...</p>

CSS宣言ブロックは次のとおりです。

p.has-extra-extra-small-font-size {
	font-size: var(--wp--preset--font-size--extra-extra-small) !important;
}

theme.jsonでの設定やスタイルの詳細については、開発メモやAPIドキュメントをご参照ください。

また、 theme.json features.の新機能を試してみたい開発者にとって便利な記事で刺激的なチャレンジであるAnne McCartyのFSEテスト依頼も是非ご参照ください。

ブロック API の強化

WordPress 5.8 で強化されたブロック API は、プラグイン開発者が特に注目すべきものです。

ブロックタイプを登録する際にblock.jsonファイルを使用することは標準的な方法として推奨されているようになりました。

パフォーマンスに関しては、テーマがアセットの遅延読み込みをサポートしている場合、block.jsonファイルでブロックタイプを登録すると、リソースのエンキューが自動的に最適化されます。これは、style と scriptプロパティで指定されたリソースが、ブロックが検出されたときにのみフロントエンドにエンキューされるためです。これにより、プラグインの開発がより効率的になり、ページサイズが縮小し、こちらの記事で取り上げた問題の防止が可能になります。
block.jsonファイルでは、ブロックがBlock Types REST API Endpointによりリストに載せられるようになることにより、サーバーサイドのブロック登録は簡素化されます。
block.jsonファイルは、ブロックプラグインをWordPressのプラグインディレクトリに登録する場合にも必要となります。

Register_block_type 関数の変更点

WordPress 5.8 以降、register_block_type関数は、block.jsonファイルからメタデータを読み取るようになりました。最初のパラメータでは、block.json ファイルが置かれているフォルダへのパスを指定できるようになりました。

この関数は、以下の例のように使用できます。

function create_custom_block_init() {
	register_block_type( __DIR__ );
}
add_action( 'init', 'create_custom_block_init' );

登録されているブロックタイプや、失敗した場合にfalseが返されます。

お気づきのように、register_block_type関数は、以前はblock.jsonファイルからメタデータを読み込んでブロックタイプを登録する唯一の関数であったregister_block_type_from_metadata 関数と同じように使用されるようになりました。Greg Ziółkowskiはこう述べています。

既存の関数であるregister_block_type_from_metadataメソッドをregister_block_type に統合し、混乱を避けることにしました。両方の関数を使用することは可能ですが、今後、公式ドキュメントやツールでは短い方の関数を使用する予定です。

サーバー側でブロックを登録されたら、クライアント側ではindex.jsファイルで同じブロック名を使って設定を登録するだけでOKです。

WordPress 5.8で強化されたブロックAPIの詳細については、Greg Ziółkowskiの開発メモをご覧ください。

WordPress 5.8のWebPサポート

ここKinstaでは、サイトのスピードとWordPressのパフォーマンスにこだわっております。そのため、WordPress 5.8で導入されるWebPフォーマットのサポートは、私たちにとっては、とても嬉しいニュースです。

次世代フォーマットのWebPは、Googleが開発した画像フォーマットで、「PNGやJPEGよりも圧縮率が高いため、ダウンロードが速く、データ消費量が少ない」という特徴があります。

Google Lighthouseは、次世代の画像フォーマットの使用を勧めている

Googleはこう述べています。

WebPは、Web上の画像に優れた可逆および非可逆圧縮を提供する最新の画像形式です。WebPを使用すると、WebマスターとWeb開発者は、Webを高速化する、より小さく、よりリッチな画像を作成できます。

WebPロスレス画像は、PNGと比較してサイズが26％小さくなっています。WebPの不可逆画像は、同等のSSIM品質インデックスで同等のJPEG画像よりも25〜34％小さくなります

WordPress 5.8 以降、JPEG、PNG、GIF 形式と同じように WebP 画像形式を使用できるようになります。画像をメディアライブラリにアップロードして、コンテンツに組み込むだけです。

以前の記事では、WebPフォーマットと、そのフォーマットをWordPressで使用するためのツールについて詳しくご紹介しました。今回、WordPress 5.8でWebP画像がサポートされるようになったことでにより、状況が少し変わるかもしれません。WebP フォーマットがサポートされるようになった為、WordPress で WebP 画像をアップロードするためにサードパーティ製のプラグインをインストールする必要がなくなりました（少なくとも一般的なユースケースでは）。

メディアライブラリを使ってWebP画像をWordPressにアップロードできるようになったとはいえ、WordPressは画像のWebP形式への自動変換をサポートしていないことにご注意ください。この機能をウェブサイトで有効にするには、サードパーティ製のWebP WordPressプラグインが必要です。

WordPressでWebP画像を使用するには

画像をWebPに変換するには、さまざまな方法があります。

Google が提供する Linux、Windows、Mac OS X 用にコンパイル済みの WebP ユーティリティとライブラリを使用することができます。
Macでは、Homebrew WebPパッケージやMacports WebPパッケージなどのパッケージマネージャーをインストールしてください。
Google Chrome LabsのSquoosh、バッチ式画像変換ソフトのXnConvert、GIMPなどの一般的な画像編集ソフトなど、WebPに対応した画像編集ツールを使うこともできます。
WebP用のWordPressプラグインをインストールすると、WordPressでWebP画像をより細かく管理することができます。

コマンドラインツールをご利用の場合は、cwebpおよびdwebpユーティリティを使用して画像をエンコードしたりデコードすることができます。たとえば、次のコマンドでは、基本的なJPEGからWebPへの変換を実行できます。

cwebp [options] original_image.jpg -o compressed_image.webp

また、Bashとcwebpを使って、画像の一括変換を行うこともできます（Jeremy Wagnerの例）。

find ./ -type f -name '*.png' -exec sh -c 'cwebp -q 75 $1 -o "${1%.png}.webp"' _ {} \;

上記のコマンドは、すべての.png画像を圧縮率75の.webpフォーマットに変換します。

WebP形式の画像ができたら、WordPressのメディアライブラリを使ってアップロードすることができます。下の画像は、メディアライブラリでの変換前の127KBのJPEG画像です。

圧縮後のWebP画像のサイズは、元のJPEG画像よりも42%小さいです!

最後になりますが、WebP画像には、JPEG、PNG、GIF画像と同様の編集機能があります。切り取り、回転、反転、拡大縮小などができ、変更を任意の画像サイズに加えることができます。

WordPress 5.8でのWebPに関する注意点

Adam Silversteinはこう述べています。

WebP 画像は非可逆圧縮や可逆圧縮に加えて、アニメーション形式や透過画像もサポートしています。WordPress では、可逆圧縮の WebP 形式は LibGD がサポートを提供するようになるまで、ホスティングサーバが Imagick (PHP ライブラリ) を使用している場合にのみサポートされます。また、アニメーション形式やアルファ形式は、サイズ変更された画像にはまだ対応していません（これらの形式で画像をアップロードすると、非可逆画像が作成されます）。

ホスティングサーバーがWebP画像をサポートしていない場合は、画像をアップロードしようとするとエラーメッセージが表示されます。ご利用のサーバーが Imagick ライブラリをサポートしているかどうかがわからない場合は、「サイトヘルス」ツールの「情報」タブに Imagick ライブラリの項目があり、そこから情報を得ることができます。

WebP のサポートにともない、WordPress 5.8 では「サイトヘルス」の「メディア処理」画面に、「ImageMagickバージョン番号」と「ImageMagickがサポートするファイル形」の2つの項目が追加されました。

サポートされているファイルタイプのリストに WebP が含まれていない場合は、ご利用のホスティング会社まで問い合わせください。

WordPress 5.8 での WebP サポートに関する追加情報、よくある質問などのリソースについては、こちらの開発メモをご覧ください。

画像の最適化に興味がある方は、以下のチュートリアルも是非ご覧ください。

開発者向けの追加機能

WordPress 5.8 には、開発者にとって便利な機能が何十もあります。本記事では、皆さんの開発作業に最も大きな影響を与えるはずのものに注目しましたが、以下のような興味深い新機能はまだまだたくさんあります。

ブロックサポートAPI

WordPress 5.8 では、ブロックサポートフラグが新たに追加され、開発者は登録済みのブロックをカスタマイズできるようになりました。

前述の実験的なデュオトーンブロックのサポート（color._experimentalDuotone）に加えて、WordPress 5.8ではリンクカラーのサポートも追加されました。この機能を利用するには、ブロックのメタデータに以下のフラグを追加するだけです。

supports: {
	color: {
		link: true;
	}
}

次の例のように、属性を使ってデフォルト値を設定したり、theme.jsonでプリセットを設定することができます。

attributes: {
	style: {
		type: 'object',
		default: {
			color: {
				link: '#FF0000',
			}
		}

その他のブロックAPIの変更点は以下の通りです。

fontSizeとlineHeightのサポートが安定しました。
spacingのサポートが拡張され、marginとpaddingを制御できるようになったほか、top、right、bottom、leftのサイズを個別に制御できるようになりました。

WordPress 5.8のブロックサポートAPIの詳細については、ブロックサポートAPIの更新に関する開発メモをご覧ください。

ブロックサポートAPIの使用方法については、ブロックサポートAPIの公式ドキュメントを参照してください。

サイトヘルスのカスタムタブ

開発者は、2つの新しいフックを使って、サイトヘルスインターフェースにカスタムタブを追加し、画面をカスタマイズできるようになりました。

site_health_navigation_tabsフィルターは、サイトヘルス画面に新しいタブを登録できるタブIDとラベルの連想配列です。以下のサンプルコードをテーマの関数ファイルやカスタムプラグインに追加することで、このフィルターを使用することができます。

function kinsta_site_health_navigation_tabs( $tabs ) {
	$tabs['kinsta-site-health-tab'] = esc_html_x( 'Kinsta', 'Site Health', 'text-domain' );

	return $tabs;
}
add_filter( 'site_health_navigation_tabs', 'kinsta_site_health_navigation_tabs' );

下の画像は、新しい「サイトヘルス」タブです。

site_health_navigation_tabsフィルターのおかげで、タブの順番を変えたり、1つ以上のア項目を削除することも可能です。

site_health_tab_contentアクションは、ユーザーがサイトヘルス画面のデフォルトの「ステータス」画面以外の部分にアクセスしたときにトリガーされます。フックは、次のスニペット（開発メモからの例）に従って使用できます。

function kinsta_site_health_tab_content( $tab ) {
	// Return if this is not your tab.
	if ( 'kinsta-site-health-tab' !== $tab ) {
		return;
	}

	// Include the interface, kept in a separate file just to differentiate code from views.
	include trailingslashit( plugin_dir_path( __FILE__ ) ) . 'views/kinsta-site-health-tab.php';
}
add_action( 'site_health_tab_content', 'kinsta_site_health_tab_content' );

まず、現在のタブがカスタムタブであるかどうかが検出され、サイトヘルス画面のコンテンツが.phpファイルから読み込まれます。site_health_tab_contentアクションでは、開発者がデフォルトの「情報」タブを拡張して、プラグインやテーマに固有の情報を追加することもできます。

ブロックエディタAPIの変更（複数の管理画面がサポートされるように）

WordPress 5.8 では、ブロックエディタを使用する管理画面は投稿エディタだけではなくなりました。（例えばウィジェット画面もブロックエディタを使用します。）

コア貢献者は、$postオブジェクトに依存してサーバー上に定義されたいくつかのフックを見つけました。このオブジェクトは、サイト編集、ウィジェット、およびナビゲーション画面には存在しません。したがって、フィルターの一部が推奨されなくなり、コンテキストを考慮した代替品に置き換えられました。

また、現在のブロックエディタのコンテキストとさまざまなメソッドを表す新しい WP_Block_Editor_Contextクラスも導入されました。

今回の変更により、これらの画面の機能が改善され、開発者がカスタマイズしたものを追加できるようになります。

管理画面に関連するブロックエディタAPIの変更点の一覧については、Greg Ziółkowskiの開発メモをご覧ください。

その他の新機能と強化点

WordPress 5.8 がもたらす新機能や開発者向けの変更点は非常に多く、本記事ですべてを紹介することはできません。一方、ここで紹介しきれなかった開発メモを集めましたので、ぜひご覧ください。

まとめ

WordPress 5.8 は、フルサイト編集への初歩です。しかし、今回の（今年2回目の） WordPress のリリースは、FSE だけではありません。ユーザーも開発者も、ブロックエディタ、新しい theme.jsonメカニズム、より強力なブロックAPI、WebP 画像フォーマットのサポートなど、数多くの改良点を見つけることができます。

私たちが特に感銘を受けたのは、ロックエディタとそのUIの様々な改良です。ブロック間のナビゲーションの向上、ブロックツールバーの刷新、インターフェイスの強化したわかりやすさなどの改善が気に入っています。

今回のような小さな変化が少しずつ編集作業を改善し、気づかないうちに、より良く、より堅牢なソフトウェアを使っていることに気づくのでしょう。それは、WordPressの誠の心です！

あなたは、フルサイト編集についてどう思われますか？WordPress 5.8でのお気に入りの変更点は何ですか？ご意見をお寄せください。

Carlo Daniele Kinsta

Carlo is a passionate lover of webdesign and front-end development. He has been playing with WordPress for more than 20 years, also in collaboration with Italian and European universities and educational institutions. He has written hundreds of articles and guides about WordPress, published both on Italian and international websites, as well as on printed magazines. You can find him on LinkedIn.