Gutenberg Block Editor だとさ | WordPressのカスタマイズ

自分的には全く必要無いものと思える Gutenberg Block Editor。
ではあるものの、いずれこれが主流となっていくのでしょう。
使ったことがなければこれが本当に良いものなのか、いらないものなのか、それさえもわからないし、とりあえずは、一度、じっくりと付き合ってみるしかありませんね。
とはいうものの、ただ画像を挿入するにしても、その吐き出される html は自分で設定しているものとは全く異なるものになってしまうので、そのあたりの対応からまず始めないといけないということになる。
今までは、画像をアップロードしたら、選択して一度に投稿に挿入できたものが、あ～っ！面倒くさいったらありゃしない。とりあえず、ギャラリーブロックでまとめて挿入し、それを画像ブロックに変換して、それぞれのブロックに必要な class を設定してやれば、とりあえずページの見た目的には、今までと同じ状況にすることはできるのだけれど。やっぱり、とても手間がかかってうっとうしいかぎり。いやはやなんともどうしたものか・・・？

と、いうことで、この投稿が初めての Gutenberg Block Editor を使っての投稿ということになりました。
で、少しでも投稿しやすいようにしなくては、と思いつつ、最も使うであろう <p>タグ、paragraph のブロック。これは標準のもので全く良いのですが、ページを生成させる時にその<p>タグが消されてしまうのがちょっと問題ではあります。（この記事を投稿した当初はそうだったと思うのだけれど、ver.5.9 となった現在では消されることはないよう）この件については、サイドバーにある『高度な設定』において、 追加クラスを設定してさえやれば、<p>タグが消されてしまうことはなくなるのですが、いちいち設定しなくてはならないというのも、やはり面倒くさい。あと、改行したくてリターンキーをおすと・・・、というのも周知のとおりの煩わしい問題。（まぁ、改行するということは段落がかわるということなのかもしれないけれど・・・）今までどおり改行したいときにリターンキーだけを打ってビシバシと文字を打っていきたい・・・！ならば、と、デフォルトでクラスの設定がしてあるブロックを作ればいいや、となりますね。

独自 custom block の作成、登録方法においては、本家 WordPress の Block Editor Handbook のページにあるチュートリアル → Writing Your First Block Type を読めばおおよそわかります。
大まかに言えば、プラグインの形式にして、php で プラグインとして必要な情報と、 block を登録する React で書かれた js ファイルの読み込みの登録。そして、その block 自体を登録する処理を書く。
React の js ファイルの方は、そちらはそちらで block をレジスターする関数を書くという具合。こちらの方が、block 登録の本丸となる。
ちなみに、js ファイルの方に複数の block 登録レジスター関数があっても、php の方は、その内の一つの block 登録が書いてあれば、他の block も js ファイルの方に書いてあるだけで登録されるよう。
ちなみに自分の場合の環境は windows10 で webpack やら BABEL やらは全く関わりなく、javascript も今の所 ES5 に固執しています。なのでややこしい環境設定を揃えなくても、簡単な block はなんとかなりそうです。
と、いうことでまずはその php 側の処理から。

2021/8/16 追記：
WordPress が 5.8 になり、php も 7.4 から 8.0 へと移行しつつあり、そして IE をもう気にかける必要がなくなった、と、この記事を公開したのは 2020/9/3。それから一年弱なんだけれど、時の流れは変化を促します。
改めて WordPress Gutenberg Handbook の tutorial を確認してみると、少し時間が経って、コードの書き方など、多少変更されています。で、Widget editor などの新しい機能が追加されたのは良いことですが、それにより Notice なども出るようになっているよう。
その辺りのことも含めて、以下、改めて編集して書き直している部分が多々あります。

wp-editor で php notice が出る問題

で、その Notice の1つ目。
読み込みファイルの登録において、その依存パッケージの読み込みを指定する件に関して。
ここで修正する以前は “wp-editor” を使用してた。それを “wp-block-editor” に変更してある。“wp-editor” は、この追記を書いている2021/8/16日 現在においても、チュートリアルにもしっかり記載されているもの。が、この “wp-editor” を使用していると、ちょっと気になることが出てくる。それは、いつからの新しい機能なのかはよく知らないのだけれど、Widget で block が使える Widget Editor において、以下のような PHP Notice が出てしまう。

「PHP Notice: wp_enqueue_script() が誤って呼び出されました。”wp-editor” script should not be enqueued together with the new widgets editor (wp-edit-widgets or wp-customize-widgets). 詳しくは <a href=”https://ja.wordpress.org/support/article/debugging-in-wordpress/”>WordPress のデバッグ</a>をご覧ください。 (このメッセージはバージョン 5.8.0 で追加されました) in C:\Apache24\htdocs\wp\wp-includes\functions.php on line 5535」

“wp-edit-widgets” もしくは “wp-customize-widgets” と “wp-editor” を一緒にエンキューするべからず！ということですね。それじゃ、代わりに何を使うのかとか、そういった情報がチュートリアルを探しても見つからない。どうすれば良いのかということが、ネットを探してもわからない。
とりあえず、この件とは関係なく、「“wp-editor” の機能の多くが、“wp-block-editor” に移行されている。」という、記述があるのをネットで見つけ、その “wp-block-editor” を代替として使用してみたところ、期待される機能は全て使え、new Widget Editor においても Notice は出なくなっています。
ただ、今の所、これでうまくいっていますが、たまたまなのか、はたしてこれで正解なのか確かではありません。その点、ご留意のほどを。いったい、この件に関してどこかに書いてあるのだろうか？

と、いいつつプラグイン Simplistic Prism Highlighter Loader の <pre><code> の自作ブロックをちょっと修正しているときにふと気がついたのだけれど。実はこのブロックにおいてのコードでは、すでに “wp-block-editor” の方を使ってた。参考にさせてもらった GitHub のコードがそうなっていたからなのであるけれど、ちなみにこれを “wp-editor” に変えてみるとどうなるか。

普通に動くかと思いきや、コンソールには次のような deprecated がちゃんと出た。
「wp.editor.PlainText is deprecated since version 5.3. Please use wp.blockEditor.PlainText instead」
PlainText の場合はちゃんとお知らせしてくれてたようです。

Server Side Render に関する処理において 管理画面でも is_admin() が false となる

あと、その前にある “wp-server-side-render”。これは、server side render の以前の書き方だと必要なかったもの。現在においては、これを使用した書き方になっています。
で、その server side render に関しては、もう一つ疑問を抱えてしまった。というのは、管理画面においての処理を分岐させたい場合、それが server side render においての処理の中では、is_admin() が機能しないということ。

この件、同じことを GitHub で質問している件があった。-> 「is_admin returning false in backend in server side rendered block」
下の方法を教えてくれている。実際やってみるとちゃんと機能してくれた。ちなみにこの返答の最後には、「Maybe we should add this info to the support handbook?」と、あり。ははは・・・、たのみますよ、ほんとに。

<?php
    if ( defined( 'REST_REQUEST' ) && REST_REQUEST ) {
        return 'Backend';// 管理画面
    } else {
        return 'Frontend';
    };
?>

追記はここまで、主流にもどります。

３行目で js ファイル（ stx_cgb.js ）の読み込みの登録。
11行目と15行目でblock の登録。ということで、ここでは2つの block を登録してる。さっき、一つあれば他の block も js ファイル側に書いてあれば・・・、と言ったばかりなのに。まぁ、これは11行目の方がシンプルな paragraph block の登録で、15行目の方は server side render の ちょっと込み入った block であり、こっちは省くことができない設定があるので、省略するとなると paragraph の方なんだけれど、はじめという事で載せてます。
js ファイルの読み込み登録の wp_resister_script で重要なのはその６行目。js ファイルに書いてある block を登録するのに必要な関数のパッケージを指定する。あっ、ただこの場合だと ”wp-i18n” はいらなかったりして。”wp-i18n” は 翻訳に必要なパッケージ。その block 登録に必要なものだけここで指定します。逆に必要なものが指定されていないと当然のこと、うごかない。

<?php
function stx_cgb_register_block() {
    wp_register_script(
        'stx-img-1',// js ファイルのid名、下のblock 登録で指定する
        plugins_url( 'stx_cgb.js', __FILE__ ),
        array( 'wp-blocks', 'wp-components', 'wp-element', 'wp-i18n', 'wp-server-side-render', 'wp-block-editor' ),
        filemtime( plugin_dir_path( __FILE__ ) . 'stx_cgb.js' )
    );

    // namespace /block-name , namespace: spcific unique, both only use lowercase alphanumeric characters or dashes
    register_block_type( 'stx-parag/wrappedparag',// ブロックの名称
        array( 'editor_script' => 'stx-img-1',// js ファイルのidを指定
    ));

    register_block_type( 'stx-out-imgs/wrappedoutimages',			
        array( 'editor_script' => 'stx-img-1',// js ファイルのidを指定
            'render_callback' => 'stx_render_callback',// コールバック関数を指定
            'attributes' => array(// ブロックから取得しコールバック関数に渡すパラメータの設定
                'baseurl' => array( 'type' => 'string', 'default' => '' ),
                'imgs' => array( 'type' => 'string', 'default'=> '' ),
                'alt' => array( 'type' => 'string', 'default' => '' ),
            )
        )
    );
}

add_action( 'init', 'stx_cgb_register_block' );
?>

そして、javascript の方。
この js ファイルには3つの custom block が設定してあります。
一つは、デフォルトで class が設定してあるただの <p> タグ。
あとの2つは、他サイトにアップロードされている画像を、url を指定して表示するためのどちらも同じ機能を持つ block。自サイトで必要だったもの。複数の画像を指定できて、全体を <p> タグでラップする。ただ、一つは server side render であり、もう一つは フロントエンドにて React で実装させてる。まぁ、この場合は普通の投稿に画像を表示させるだけなので server side render を使う必要は全く無く、そもそもせっかくの React なんだからフロントエンドでやらせたほうが良いにきまってるし、動作も速い。
server side render の方は、js においては書くことがほとんど雛形どおりで、表示させたいことは php 側の render_callback 関数で書くことになる。ゆえに php に慣れている分には php で書いた方がよほど手っ取り早いので、緊急時、とりあえずという時にはごまかしにはなる。けれど、それは本来の使用目的にはそぐわない。
この block においては、オプションの設定は InspectorControls を使用してサイドバーにて指定出来るようにしてある。その ES5 における InspectorControls　に関しては Github にある　→　gutenberg/packages/block-editor/src/components/inspector-controls/
実は、この InspectorControls に関しての記述のある GitHub のページなんだけれど、ひさびさに覗いてみたら、ES5 での記述が ESNext にすっかりかわってた。あれま！と思ってがっかりしたのだけれど、もとの ES5 のページも別のアドレスにて残してくれていた。と、いうことでリンクは修正してあります。
なお、2つ目の方は php において resister 関数で登録していないけれど、ちゃんと認識されて使えています。

で、ここでちょっと後日追記：
その InspectorControls に関してなのだけれど。
これも以前は何の通知も出なかったけれど、その各 InspectorControls において使用される attributes の各値に初期値を設定しておかないと Warning が出るようにしたようです。初期値を設定していない undefined の状況では uncontrolled なコンポーネントとされていて、それに値を与えることで controlled なフラグに変わることが気に入らないよう。確かではないのだけれど、undefined ということなので、ならばと、default 値を設定したところ、Warning は出なくなった。
server side render は、上でも少し書いたけれど、書き方が以前とは変わっていて、依存ファイルの “wp-server-side-rende” を使用する書き方に変わってる。
あと、基本的な p タグなんかの書き方も、“blockEditor.useBlockProps” を使う方法に直しています。