WordPress Theme Emulsion

block editor ( gutenberg ) 対応した新しいコンセプトのテーマ

gutenberg 9.3 WordPressの未来を見せ始める

gutenberg 9.3 WordPressの未来を見せ始める

FSEをサポートしたテーマでは、カスタマイザー、ウィジェットが消えた

観測気球ですか?

FSEをサポートする新しいタイプのテーマを使った場合には、ダッシュボードのメニューから、カスタマイザーやウィジェットが消えてしまいました。(現在の、ブロックエディタ対応テーマ等は、カスタマイザーやウィジェットは従来通り使えます。)

Gutenberg9.3を有効にしたFSEテーマ

FSEテーマとは何ぞや、という話は、追々説明するとして、WordPressの新しいタイプのテーマを使用した場合上記のようなメニューが表示されます。

サイトエディタが追加され、外観メニューには、カスタマイズ、ウィジェットがなくなり、代わりにテンプレートや、テンプレートパーツといったメニューが表示されるようになりました。

まぁ、全部消えたわけではなくて、アドミンバーなどのメニューは、そのままなので、アクセスできないというわけではないですが、WordPress5.6以降の変化の兆しは十分みることができ、また、私には結構ショッキングな話題です。

サイトエディター

サイトエディタは、以下のような画面で構成されていて、下の画像はindexページの内容を編集しようとしているところです。

従来ブロックエディタは、投稿タイトルと投稿本文を編集していたわけですが、サイトエディターになると、ページ全体を編集するといった事ができるようになります。

最初のメニューのところに、templateとか、template partsといったメニューが並んでいましたが、従来テンプレートのカスタマイズは、archives.php category.phpといったファイルをFTPでアップロードしていましたが、FSEテーマの場合は、編集作業でそれらのファイルを作成したり、編集できるようになります。

Site Editor

FSEテーマとは

以下は、自分のテストを通した理解なので、間違いがあるかもしれませんが、、、

FSEテーマは、テーマに、block-templates、block-template-part ホルダーを持っていて、その中にcategory.htmlといったテンプレートファイルやテンプレートパートファイルを持っているものをいいます。

今回の変更で、gutenbergは、テーマが対応しているか識別して、対応していれば、自動的に、対応するようになったみたいです。

WordPressは、ブロックテンプレートを保持しているテーマがあれば、テンプレート階層 に従って該当のテンプレートをロードします。

ユーザーが、ブロックテンプレートメニューに、該当のテンプレートを持っていれば、それを優先してロードしますが、ユーザーが、テンプレートのデザインを変更すると、テーマのテンプレートではなく、変更は、カスタム投稿の中に保存され、テーマのテンプレートは使用されなくなります。

カスタマイザーや、ウィジェットが表示されなくなるだけではなく、固定ページなどもFSEが有効なテーマでは、使われなくなります。既存のPHPのテンプレートファイルも、使われなくなります。

現在のテーマとの隔たりを考えると従来テーマの延長線上にある新しい機能というよりは、全く新しいタイプ?

テーマが、ユーザがカスタマイズする前の一時的表示を担当するだけなら、一般的には、ワードプレスには、何らかのテーマを使用しなければならないなんてことは取っ払われて、テーマなしでも動くようになるのかもしれないですね。

そのようなテンプレートが該当しない場合は、(たぶん将来的に、)従来のphpテンプレートがロードされるといった仕組みのようです。

テーマが、fse対応かどうかをgutenbergは、どのようにチェックしているか

function gutenberg_is_fse_theme() {
     return is_readable( STYLESHEETPATH . '/block-templates/index.html' );
 }

現在のところ、block-templates/index.htmlがあるかどうかで判定しているので、fse非対応と判定させるためには、index.html を no-index.htmlなどにリネームしたり、フィルターを追加したりしておけば、非fse とfseの切り替えもできるかもしれません。

FSEをどのように処理するかというのは、結構悩み深くて簡単に、テーマと同等のスタイルを作り出すことは、難しそうな印象です。

例えば、emulsion テーマの場合ヘッダー画像の出力は、以下のようになるのですが

 <div id="wp-custom-header" class="wp-custom-header">
     <img src="" width="" height="" alt="Theme emulsion" layout="responsive" >
 </div>     

ブロックエディタでは、ブロックのhtmlがおまけでついてくるためテンプレートに

<!-- wp:post-featured-image /-->

を追加すると、

<div class="emulsion-fse-featured-image">
     <p class="wp-block-post-featured-image">
         <img width="2000" height="1200" class="attachment-post-thumbnail size-post-thumbnail wp-post-image lazyload" alt="" loading="lazy" sizes="" data-src="">
     </p>
 </div>

といった形で、テンプレートに出力されてしまい、HTML構造が変わってしまうので、従来テーマの感覚では、手に余る

fseテーマをインストールすると、以下のようなメッセージが表示されます。

WordPress Themeの標準的な作成方法

wordpress.orgにホスティングされるテーマは、2015年春に、Theme Customization APIを使用することが、テーマレビューチームのガイドラインになっており、標準的な作成方法に準拠している人たちは、結構右往左往するのではないかと思います。

仮に、今テーマを作っている人がいるとしたら、カスタマイザーでPHPのtheme_modとかoptionフィールドに、設定を保存するといった事でテーマを作っているでしょうが、荒っぽく言えばGutenbergが見せつつある、新たな未来は、「theme_modとかoptionフィールドに、設定を保存」なんてことは大幅に減少 というメッセージであり、

その値は投稿の本文に、例のhtmlコメント形式で記述されるというメッセージに他なりません。

今のところ、私は、カスタマイザーやウィジェットエリアがなくなったのは、プラグインでの開発の促進といった意味で受け取っていますが、先々WordPressがどのような変貌を遂げるのか、楽しみではあります。