WordPress の新エディター Gutenberg 雑感(テーマ開発者向け)

Gutenberg はまだ正式リリースではなく、プラグインとして提供されていて、僕もさわりはじめたばかりなので、ここに書いていることはあくまで僕のファーストインプレッションとなります!

もうしばらく前から Gutenberg はプラグインとしてリリースされていて、GitHub のリポジトリにも大量の issue がたち、活発に開発が進められていました。

でも僕みたいなレイトマジョリティはなかなか先立って触るのが億劫で、誰かが日本語で開発者向けの情報だしてくれるまで待っておこうとか思っていたのですが、先日リリースされた WordPress 4.9.8 からダッシュボードに Gutenberg の案内がでるようになり、Snow Monkey のユーザーが Gutenberg をインストールしだすと考えると、さすがに待ってるのはまずいなということで、ちょっと触り始めてみました。

といっても Gutenberg を使って記事を書いたりはしていないので、オリジナルのブロックをつくってみたり、テーマのスタイルを Gutenberg のブロックにも反映したりしてみたテーマ開発者向けの雑感になります。

情報源

Gutenberg ハンドブック

1つめが WordPress.org の中にある Gutenberg ハンドブック です。英語ではありますが、この中にカスタムブロックのサンプルコードが掲載してあるので、基本的なものであればこのサンプルコードを書き写してちょこちょこ変更するだけで動くものはつくれるのじゃないかと思います。

サンプルコードは ES5 版と ESNext 版が掲載してあり、ES5 版はそのままコピペで動きますが、ESNext 版は Webpack と Babel なんかを使ってビルドが必要です。分かる人は自分で環境をつくれると思いますが、僕はよくわかってなかったのでビルド環境つくるのにもちょっと苦労しました。

手前味噌ではありますが、僕のカスタムブロック集は Webpack + Babel でビルドするようにしているので、下記のリポジトリの .babelrcwebpack.config.jspackage.json あたりをコピペして NPM Script のところを適当に変更してもらえれば、とりあえずビルドできるんじゃないかと思いますので試してみてください。

Gutenberg のリポジトリ

前述したハンドブックでも基本的なことはできるのですが、全ての API やコンポーネントの情報が載っているわけではないので、もう一歩進んだことをやろうとすると、どうやってやるんだ…となってしまいました。

Gutenberg はもうだいぶ API も固まってきたんじゃないかなぁと想像していますが、これまですごい勢いでどんどん開発されてきているので、ググってでてきた情報を試してみても動かなかったりすることがあります。

そこでおすすめなのは GitHub にある Gutenberg のリポジトリを覗いてみることです。つまりソースを見るということですね。プラグインとしてインストールした Gutenberg にはビルド後のファイルしか入っていないので見てもよくわからないのですが、リポジトリにはビルド前のファイルがあるので、コアブロックのソースファイルとかをみるとかなり参考になります。

「いや、難しくてわかるわけない」という方も多いとは思いますが、僕は Gutenberg どころか React もはじめてですし、JavaScript は雰囲気で書いているタイプなので僕もよくはわかっていません。でもオリジナルのブロックをつくろうとすればどうせコードを書く必要がありますし、それならネット上の断片的で不確かな情報より、今動く本家のコードを読んだほうがムダな時間を過ごさずに済むはずです(コアで提供されているブロックより高度なことをしたいならもっと深いところをハックしないといけないと思うので、それは健闘を祈ります)。

テーマのデザインとエディタのデザイン

「デザイン」という言葉が適切かどうかはわかりませんが…。Snow Monkey は「表側の記事のデザインと、TinyMCE 上のデザインをなるべく同じにする」ということにかなり拘っています。

例えば見出しとか引用のデザインが表側でもエディタ側でも同じであるとか、ショートコードだとエディタ側ではただの文字列で、初心者からすればそれはただの「コード」で難しいので HTML を記事中に直接挿入する機能をつくったり、しかもそれにもちゃんと表側と同じデザインが反映される、というようなことですね。

ここまではわりと多くのテーマでもやられていると思いますが、意外に対応されてないなと思うのは、カスタマイザーで設定したカラー設定等々がエディタには反映されてない、とかですね。この辺は editor-style の仕組みみたいに簡単ではなくて、TinyMCE にフックしてスタイルを突っ込んだりしないといけなくて、情報もそんなに無いしめんどくさいので対応していないことが多いのかなと思いますが、Snow Monkey はその辺りも頑張ってアクセントカラーが反映されるようにしたりしています。

で、Gutenberg ですが、エディタの仕組み自体が全く変わるので、そのようなこれまでの TinyMCE エディタ向けのやり方は全て反映されなくなります。つらい…。

単純にエディタ向けのスタイルを反映させるだけであれば、

add_action( 'after_setup_theme', function() {
    add_editor_style( [
        'assets/css/editor-style.min.css',
    ] );
} );

とかやってたのを

add_action( 'enqueue_block_editor_assets', function() {
    wp_enqueue_style(
        ’editor-style',
        'assets/css/editor-style.min.css',
        [],
        false
    );
} );

のように置き換えるだけですが、TinyMCE と Gutenberg では HTML の構造も変わっていますし、Gutenberg ではエディタ内の要素にデフォルトのスタイルが若干強めにあたってるので、これまでの editor-style を使い回すだけではうまくいきませんでした。

TinyMCE は iframe でまっさらな HTML を呼び出してスタイルをあてますが、Gutenberg は iframe ではなく同じページ上にエディタが展開されているので、そういう意味でもスタイルの当て方を工夫する必要があります。

例えば、今まで editor-style で

ul {
    margin-left: 1em;
}

とかしてたとして、それは iframe 内にしか影響がなかったのでそれで良かったわけですが、Gutenberg では同じページ上に展開されるので、ダッシュボードのメニューだとか、そういうところにも影響がでちゃうわけです。そういうわけで、まぁ TinyMCE のときもテーマのスタイルをそのまま editor-style にできるわけじゃなくて多少調整が必要ではありましたが、そのときよりもよく考えて CSS 設計をして調整し、Gutenberg 用のスタイルをつくる必要があります。

ちょびっと具体例

全部書こうとするとコード見たほうが早いとなるので、僕がやってみた方法をちょびっとだけ書きます(まだ試している最中なので、これがベストだとは思っていませんし、今後変更する可能性は大です。なので参考まで…)。

.edit-post-visual-editor .editor-writing-flow {
  // .c-btn とかオリジナル class のスタイル
  @import 'object/component/component';

  // デフォルトと p のスタイルを上書き
  &, p {
    color: $_color-text;
    font-family: $_font-family;
    font-size: $_base-font-size-px;
  }

  // コンテンツ部分のスタイルを適用
  > div > div > .editor-block-list__layout > [data-type^="core/"] .components-autocomplete {
    @include entry-content(); // ここが展開されると > h2 とか、> table とかになる
  }
}

まず、全体を .edit-post-visual-editor .editor-writing-flow で囲いました。このクラスが管理画面上での Gutenberg エディタの class になります。

次に、そのエディタと、p 要素に文字色、フォント、文字サイズを適用しています。「なんであえて p にも?」と思われた方がいらっしゃるかもしれませんが、Gutenberg は p 要素にもなぜか文字色とかフォントを設定してるので、こうしないと明朝体で表示されちゃったりするんですよね。

で、その次にコンテンツ部分のスタイルを適用しています。僕はコンテンツ部分の HTML 要素のデフォルトスタイルは子孫セレクタを使って設計するのが好きなのですが、Gutenberg は見出しとか段落とかの各ブロック毎にいくつかの div でラップされるので、そのままでは全然デザインが適用されなくなってしまいました。そういうことでいろいろ試行錯誤して、今のところ上記のようなセレクタを追加して、その中で子孫セレクタでデザインを適用する、というような感じにしています。

こうすることでコンポーネント(Gutenberg のカスタムブロックじゃなくて CSS のコンポーネントです)にも詳細度的に何か問題がでそうでかなり不安ではあるのですが、運用してみてトライアンドエラーで調整が必要かなと思っています。こうしたほうが良いとか知見をお持ちの方がいましたらぜひ情報交換しませう…。

カスタムブロックをつくるときの注意点

カスタムブロックは、前述したようにつくるだけならサンプルコードやコアブロックのコードを真似して結構簡単につくれます。

僕が結構大変だなと思ったのは、カスタムブロックが出力する HTML を変更すると、すでに埋め込んだブロックが「このブロックでエラーが発生したためプレビューできません」となってしまうことです。

きちんと事前に設計して、「もう絶対にこのブロックの HTML はこれで確定!」と自信を持てる人であれば問題ないと思いますが、僕は結構ちょこちょこ「いやこうしたほうが良いな」とか調整してしまうタイプなので、安易に適当につくってリリースしちゃうと簡単に変更が入れられなくて大変になるからリリース前によーく考えてリリースしないといけないなと思いました。

そういう仕様になっているのも理由があって、ハンドブックには書かれているのですが、僕の英語力ではちゃんと理解できているのか怪しいので、ぜひご自身でお読みください…(Deprecated Blocks)。一応どうしても変更したい場合の対処法もコードが掲載されてたりしますが、試していないのでそこはよくわかっていません。

これまでの記事はどうなるのか

これまでの記事は、「クラシックブロック」という1まとまりのブロックとして扱われるようになります。Gutenberg は見出し、段落、画像、など本来それぞれの要素毎に1ブロックなので、「クラシックブロック」をそれら個別のブロックに変換できるようになっています。

僕も試しに適当な記事をブロックに変換してみたところ、全体的にはなんとなく大丈夫っぽいけど一部何かおかしい…。で、よくよくみてみると、なんと HTML の class が全部削除されてしまっているではないですか!

例えば、a.c-btn のようにしてボタンとして表示したりしてたのですが、.c-btn という class が消されて、ただのリンクとして表示されるようになっていました。Snow Monkey はまだ良いとして、仕事で Web サイトをつくっているとエディタに複雑につくりこんだ HTML をコピペしてページをつくることがあると思うのですが、全部 class が消えちゃうというのはなかなかの破壊力だなぁと思いました…。

GitHub ではディスカッションがされているようだったので、今後どうなるかはわかりませんが、少なくとも今の段階では、過去の記事はクラシックエディタのまま編集するのがベターかなと思います。

全体的な感想

いろいろやってて感じたのは、「テーマはレイアウト部分をデザインしてね、コンテンツ部分は Gutenberg に任せろ!」ということなんじゃないかなぁということです(ちゃんとハンドブックを読み込んだりリポジトリの issue を読み込んだりしているわけではないので完全に僕の想像です)。

だからこれまでの TinyMCE のように表側とエディタで完全に見た目を一致させようと頑張るんじゃなくて、どの環境でも Gutenberg は Gutenberg として共通の執筆体験を提供できるように表側とのデザインの一致度は良い塩梅にしておいて、というくらいの付き合い方がベターなのかなと思ったり。

これまで Snow Monkey で提供していた「HTML コンポーネント挿入機能」も Gutenberg では使えなくなるので、似たようなものを Gutenberg のカスタムブロックでつくってみたりしていて、なるべく表側と同じ見た目で入力ができるようにとやってはいるのですが、なんか実はそんなことせず、Gutenberg 側では ACF のカスタムフィールド的に入力欄だけ提供して、というのが良いんじゃないかなーとかも思ったりしました。デザインを適用するというのがやはりなかなか CSS 設計的に難しいので。

ACF がカスタムフィールドのスタンダードになったように、Gutenberg のカスタムブロックも似たようなプラグインがでてくるのではないかという予想を聞くこともありますが、実際どうなんでしょうね。前述したように HTML 変えるとブロック壊れちゃいますし。個人的にはあんまりカスタムブロックつくたりしないでコアのブロックでできる範囲にしておいて、それ以上をやりたかったらカスタムフィールドとか、Elementor のようなページビルダープラグインを使うほうが変に大変にならないのでは?と感想を持ちました。

現場からは以上です。

おまけ:とりあえずつくってみてるやつ

 

この記事を書いた人

キタジマ タカシ

長崎県長崎市在住。地元のWeb制作会社でWebデザイナー/エンジニアとして従事した後、2015年にフリーランス [ モンキーレンチ ] として独立。WordPress のテーマやプラグイン、ライブラリ、CSS フレームワーク等、多数のプロダクトをオープンソースで開発・公開しています。

この記事が気に入ったら
いいね!しよう

最新の情報をお届けします

Snow Monkey オンラインコミュニティ

Snow Monkey をより良いテーマにするために、今後の機能開発等について情報共有したりディスカッションをしたりする場所です。より多くのユーザーの交流があったほうがより良いプロダクトに育っていくと思いますので、ぜひご参加ください!