ブロックエディタの活用
Gutenberg(グーテンベルク)いわゆる、ブロックエディタと言われる編集画面に使い慣れてくると、それまでのビジュアルエディタがいかに古臭いものだったか思い知らされます。
Windows3.1(1991年)時代のボタンだらけのゴテゴテしたエディタを我慢して使うのはそろそろやめて、21世紀らしい感覚的インターフェースに慣れてみましょう。
これからはブロックエディタの時代
WordPress5.0から導入された悪名高きGutenberg(グーテンベルク)は、採用直後はWordPressのトップ画面に「無理してグーテンベルクを使わなくてもいいんですよ」という消極的なメッセージと、Gutenbergを強制解除するためのClassic Editorプラグインが案内されていました。
このプラグインは2022年まで、もしくは必要とされる限りサポートされます。と記載されており、では2022年以降はどうしようか?と不安になりましたが、2019年7月現在、少なくとも、私達のまわりではClassic Editorプラグインは必要なくなりました。
ブロックエディタの無効化
いくらブロックエディタが使いやすくても、どうしても採用したくない理由といえば、固定ページなどに直接HTMLを書き込んでいる場合ではないでしょうか?
Gutenbergは開いて保存するだけで、余計なPタグが入ったり、HTMLが整形しなおされたり、BRタグがなくなっていたり、意味のわからないエラーが出たりと、タグが破壊されてしまいます。
そんな時は、固定ページの場合はテキストエディタのみ。ブログの投稿はブロックエディタ。などと分けてみると良いでしょう。
add_filter('use_block_editor_for_post_type','set_block_editor',10,2);
function set_block_editor( $default, $post_type ) {
//固定ページの場合無効
if ( $post_type === 'page' ) return false;
return $default;
}
ビジュアルエディタの無効化
ブロックエディタを無効化しても、ビジュアルエディタが有効のままでは、やはりHTMLが破壊されてしまいます。ビジュアルエディタも忘れずに無効にしておきましょう。
add_filter('user_can_richedit','set_visual_editor');
function set_visual_editor( $default ) {
//固定ページの場合無効
$type = get_post_type();
if ( $type === 'page' ) return false;
return $default;
}
これを応用すれば、投稿タイプによってエディタを変更する事もできます。
また、使い慣れたビジュアルエディタを使いたい編集者や、すんなりとブロックエディタを受け入れる新しい人材、どうしてもテキストで編集したいコーディングマスターなど、ユーザーごとにエディタを分ける事もできます。
カスタム投稿タイプをブロックエディタに対応する
カスタム投稿タイプをブロックエディタに対応するためには、ちょっとしたコツが必要になります。
register_post_type(
'product',//投稿タイプ
array(
'labels' => array(
'name' => '商品紹介',
),
'public' => true,
'show_in_rest' => true,
↑このパラメーターが必要です
'descriptions' => '商品紹介の投稿',
'hierarchical' => true,
'has_archive' => true,
'supports' => array('title','editor')
)
);
show_in_restをtrueにするというのは、REST APIを有効にするという意味です。
じゃあそのREST(REpresentational State Transfer) APIとやらは何なのか?というと、誤解を恐れずに簡単に言ってしまうと、WordPress上でPHPを使わずにJavascriptで投稿データなどのデータベース情報を扱う事ができるようになる。という事です。
WordPressといえば、いちいち↓こんなようなものを書いたPHPを何度もリロードさせて処理しているイメージがあります。
if($query->have_posts()):
while($query->have_posts()):$query->the_post();
メインループ
endwhile;
endif;
ブラウザをリロードしないと新しいデータを扱えないし、処理もできないのがPHPの特徴です。
JavascriptとPHPを組み合わせれば、ユーザーが触らなくても自動的に処理を実行させたり、ユーザーの小さな動作を神経質に読み取って裏側で大きく処理する事ができます。
WordPressで、このJavascriptが積極的に使えたら、いかにもWordPressっぽい、ギッタンバッコンとリロードぐるぐるしては、んーパッ、んーパッとワンテンポ出遅れて表示されるというトロ臭さが解消されて、FacebookとかTwitterとかみたいに新しい時代っぽいインターフェースが作れるようになるはずです。
そして、そんな期待に応えて登場したのが、WordPress4.7以降で標準搭載されたREST APIとやらなのです。
Gutenbergというブロックエディタは、このREST APIを最大限に活用していて、編集画面の中で投稿内容をつかんで上下の順番を入れ替えたり、+を押してジャンジャン追加したり、マウスで選んでデリートボタンで削除。みたいなリアルタイムで反応する滑らかな革新的な編集画面を実現しています。
Gutenbergってそんなに凄いものだったんですが、デビューしたての時は、日本語にも対応しておらず、急に全画面になったりとユーザーを無意味に驚かせたり、なんだかダサくて使いにくくて、本来の素晴らしさが伝わってきませんでしたが、実はこの今の時代に合ったREST APIの発想を取り入れたものだったのです。
タクストミーのほうも設定が必要
カスタムタクストミーのほうでもREST APIを有効にしてください。
register_taxonomy(
'product-category',
'product',
array(
'labels' => array(
'name' => '商品カテゴリー',
),
'show_in_rest' => true,
↑このパラメーターが必要です
'hierarchical' => true,
'show_admin_column' => true,
'update_count_callback' => '_update_post_term_count',
'public' => true,
'show_ui' => true
)
);
これでカスタム投稿タイプでも安心してブロックエディタが使えます。
カスタムスタイル
ブロックエディタは使いやすいですが、吐き出すタグは決まった形になっているため、そのままでは思ったようなレイアウトにならないかもしれません。でも、タグはせいぜいがpとかdivとかspanとかliとかの組み合わせなので、class名さえ分けられればCSSのほうでなんとか出来てしまいます。
追加したブロックに特定の名前のクラスを追加したい場合は、ブロックの設定画面の中にある「高度な設定」を開き、追加CSSクラスにクラス名を書き込めば、クラスとして追記されます。
しかし、クラスとか言われても、HTMLとCSSを使いこなす人にとっては身近な表現ですが、HTMLに詳しくない編集者にはなんだか意味のわからない話です。
そこで、この設定画面をカスタマイズしてもうちょっと見て判断できるビジュアル的なインターフェースにしてみましょう。
設定にカスタムスタイルを追加する
以下のスクリプトを書いたjsファイルを作成し、テンプレートディレクトリのどこかに設置します。
wp.blocks.registerBlockStyle('core/button',{
name: 'magic-fire';,
label: 'Magic Fire';
});
例えばそのjsファイルをmy_wp_blocks.jsとします。
そして、functions.phpに以下のものを書いて登録します。
function myguten_enqueue(){
wp_enqueue_script(
'myguten-script',
get_template_directory_uri().'/my_wp_blocks.js',
array('wp-blocks')
);
}
add_action('enqueue_block_editor_assets','myguten_enqueue');
すると、ブロックエディターのスタイルにMagic Fireとという名前のボタンが作成され、押すと、is-style-magic-fireというクラスが割り当てられます。
設定されているスタイルを削除する
wp.blocks.unregisterBlockStyle('core/quote','large');
以上のようなカスタマイズ方法については、WordPressの公式サイトにまとめられています。
参考リンク(WordPress.org)
HTMLを大幅改造したい場合
CSSで調節する程度のものでは納得いかないほどHTMLを大幅に変更したい場合は、クラス名で受け渡し、PHPで出力した時に特定のクラス名で判別してHTMLを整形しなおす、という方法もあります。
これならブロックエディタの良い部分を取り入れながらも、かなり自由なレイアウトを自動出力させるような編集画面が実現できます。
WordPressを使う場合、制作スケジュールや予算が限られている案件が多く、手間をかけすぎて制作費が膨らみWebサイトの公開が伸びるよりも、こういった少々不格好な手段を使うほうがよかったりします。
カスタムブロックの追加
どんなに手間をかけても良いから、ブロックエディタそのものを自分のものとして大改造したい!という希望に沿う仕組みも用意されています。
ここではオリジナルブロックを作る方法を軽く説明します。
まず、編集画面に適用されるCSSを作成しそれをファイルで用意します。例えばそれをblockcustom.cssとします。
次に、jsファイルを用意し、これを仮にblockcustom.jsとします。
このblockcustom.jsの中に、カスタムブロックの全処理を書き込みます。ブロックエディタの処理はPHPではなく全てこのJavascriptで行っています。
以下、例えば、黄色いボーラーラインで囲んだ黄色い文字の注意書きというカスタムブロックを追加するサンプルです。
(function () {
var el = wp.element.createElement,
blocks = wp.blocks,
richText = wp.editor.RichText;
blocks.registerBlockType('my-plugin/myblock', {
title: '注意書き',←カスタムブロック名
icon: 'align-center',←カスタムブロックのアイコンを指定
category: 'layout',←カテゴリーを指定
attributes: {←処理の中で使う変数
content: {
type: 'array',
source: 'children',
selector: 'div',
},
},
↓以下、編集画面で出力する内容
edit: function (props) {
var myContent = props.attributes.content;
return el(
richText,
{
tagName: 'div',
className: "myblock",
style: {
color: '#ffcc00',
font-size:1.2em
border: double 10px #0000ff;
},
value: myContent,
onChange: function (changedContent) {
props.setAttributes({content:changedContent});
},
}
);
},
↓以下、公開ページで出力する内容
save: function (props) {
return el(richText.Content, {
tagName: 'div',
className: "myblock",
style: {
color: '#ffcc00',
font-size:1.2em
border: double 4px #ffcc00;
},
value: props.attributes.content,
});
},
});
})();
以上のCSSとjsを、functions.phpで読み込みます。
function add_my_cusblock() {
wp_enqueue_style(
'myblock-css',
get_stylesheet_directory_uri().'/css/blockcustom.css'
);
wp_enqueue_script('myblock-js',
get_stylesheet_directory_uri().'/js/blockcustom.js',
array(), "", true
);
}
add_action('enqueue_block_editor_assets', 'add_my_cusblock');
カスタムブロックは、ブロックエディタ編集画面用のHTMLと、公開ページで出力されるHTMLを2つ用意し、その双方を変数で繋げる仕組みを用意する事になります。
公式マニュアル(WordPress.org)
WordPress内蔵アイコン一覧(WordPress.org)
ES5とESNext(ES6)
カスタムブロックを追加する処理はJavascriptで書かれています。JavascriptならjQueryを使ってよく知ってる。という人でも、Gutenbergのカスタマイズレベルになると、かなり・・というか、ぜんぜん意味がわからない!と躓くかと思います。
サンプルを見てもわからないし、そもそもサンプルが全然動かない!
まずは、ES5とESNext(ES6)の違いから学んでいかないと、次の一歩を進める事ができないかと思います。
ES5とかES6というのは、Javascriptの記述方法です。基本的にWordPressはES5対応ですが、ライブラリなどを追加すればES6に対応する事ができます。しかし、多くのブラウザに対応しているのはES5です。
特にHTMLを出力する部分でES5は書きにくくて覚えにくく、ES6のほうが感覚的に理解しやすいスクリプトが書けるようになっていたりします。
WordPressが出力するものは、多くのユーザー環境に対応する必要がありますが、管理画面については環境を特定しても良いのではないかと考えます。なので、是非ともES6を使いたいところです。