WordPressのGutenberg切り替えで困ったことまとめ

現職で携わっているECサイトはWordPressで構築されているのですが、大規模かつサービスが止まるとまずいのでWordPress本体やプラグインは自動更新にしていません。
先日、全サイトの全プラグインのバージョンと脆弱性のチェックをして更新をかけていったわけなのですが、その際に「もう旧エディタをやめてGutenbergにしていいんじゃないか」ということになり切替のための検証をしたので、そのときのことをまとめます。

Gutenberg切り替えの経緯

プラグイン側のセキュリティホールなどによるリスク回避のため、できる限り不要なプラグインや信頼できないプラグインは使用しないのが理想なのですが、WordPress公式プラグインのClassicEditorのサポートも2021年12月31日までとなっています。
（弊社サイトは今まではTinyMCEAdvancedを使用していました）

• Classic Editor

上記のプラグインページには

少なくとも2022年まで、または必要なくなるまでの間、完全にサポート・保守されます。

とありますが、この「2022年まで」という表現が日本語の曖昧なところで、実際には下記のとおり

• Make WordPress Core

The Classic Editor plugin will be officially supported until December 31, 2021.

ということなのかな？と思います。

「または必要なくなるまでの間」の方が採択されるかどうかの保証はないので、いずれなくなるという可能性に備えるに越したことはないと思われます。

WordPress本体やGutenbergのアップデートが進むことにより現状で不便な点も徐々に改善されることを期待し、Gutenbergのブロックエディタを使用する方針としたいわけですが、旧エディタが利用できなくなってから一斉に切り替えると作業者の学習が間に合わず、業務に支障を及ぼす可能性があるため、メインで動いているサイトではなくサテライトサイトから試験導入することにしました。

いくつかつまづいてしまったところとその対策については下記の通りです。

Gutenbergを正常に動作させるための対応

Gutenberg自体が機能しない場合

カスタム投稿タイプを作成する際に、CPTUIなどのプラグインを使わずにfunctions.phpに直接記述する方法をとっていると、ブロックエディタが使用できない場合がある。
原因と対策は以下の通り。

原因

GutenbergのブロックエディタはREST APIを使用する必要があるが、show_in_restの値がデフォルトではfalseになっているため。

カスタム投稿タイプをプラグインで作成するとこの値をプラグイン側で設定できるので問題が起きない。

対策

すべてのカスタム投稿タイプのパラメータ配列に下記を追加する。

'show_in_rest' => true,

固定ページのブロック挿入ができなくなる場合

Gutenbergの投稿画面では「ビジュアルエディター」「コードエディター」のエディター設定を切り替えられる。
これは旧エディタの「ビジュアル」「テキスト」の編集モードに該当する。

しかし、ブロックエディタでは、エディター設定が「コードエディター」になっている状態で新規ブロックを追加することはできない。
投稿画面で画像ブロックを追加して直接メディアアップロードしたい場合には「ビジュアルエディター」にする必要があるが、この切り替えメニューが表示されない場合がある。
原因と対策は以下の通り。

原因

HTMLコードの崩壊を防ぐなどの目的で、ユーザーに旧エディタの「ビジュアル」モードを使用させないために、

• WordPressのエディタをテキストエディタにデフォルトで開く設定
• WordPressの固定ページ編集時のみビジュアルエディタを使用できないようにする

こういった記事で紹介されているdisable_visual_editor_in_page()などの関数を使用しているケースで起こる。
また、デフォルトの表示を「テキスト」モードにし、「ビジュアル」モードへの切り替えを禁止している場合も同様。

対策

functions.phpから「ビジュアル」モードの使用を禁止している該当箇所のコードを削除する。

保存・更新に失敗しデータベース接続エラーが出る場合

原因

再利用可能ブロックで自身のIDを指定したコードを含んでいる場合に自己参照ループに陥る。

• 【WordPressメモリ不足】再利用可能ブロックが使えない・自己参照エラー
• 500 error and ‘Reusable’ tab disappears when a reusable block is embedded into itself

その結果メモリ不足を引き起こしてMySQLが落ちてしまう。

対策

気をつける…(´・ω・`)

いや全然対策になってないけど、気をつける以外にない…
これやってしまうと素人には復旧できないのでけっこうヤベー問題だと思う。
自身のIDが含まれる再利用ブロックを再利用ブロックの中に入れようとしてもできないようにして、アラートを出すべきかなと。

ブロックエディタで記事を作成する際の気になる点と対策

ブロックごとにwp:接頭辞つきのコメントが挿入される

<!-- wp:paragraph -->
<p>段落テキスト</p>
<!-- /wp:paragraph -->

「コードエディター」で削除することは可能だが運用としては非現実的。
（ちなみに削除するとクラシックブロック扱いになる。）

画像はfigure要素として挿入される

<!-- wp:block {"ref":996} /-->

<!-- wp:html -->
<p>新しいブロックで「HTMLとして編集」</p>
<div>HTMLベタ打ち可能</div>
<!-- /wp:html -->

<!-- wp:gallery {"ids":[891,854,849,839,949]} -->
<figure class="wp-block-gallery columns-3 is-cropped">
    <ul class="blocks-gallery-grid">
        <li class="blocks-gallery-item">
            <figure>
                <img src="

・・・

<!-- wp:block {"ref":996} /-->