Crayon Syntax Highlighter は JavaScript を切ってもきちんと表示され、外部スクリプトに依存しなかったりと、コードシンタックスハイライト系の WordPress プラグインの中でも優秀な部類に入るだろう。ただ、開発が滞っており、2018/11/11時点では、Gutenberg エディターに対応していない。
原因は REST API を介しての記事作成
Crayon Syntax Highlighter (以下CSH) を有効にして、投稿を Gutenberg で編集したり公開しても、シンタックスがハイライトされないので調べてみた。オンライン検索では全く出てこなかったので、プラグインコードにデバッグのコードを差し込んで調べた。
原因は Gutenberg が WordPress の REST API を介して記事の作成、編集を行うところにあるのを突き止めた。CSH は the_content以外にデータベースクエリで投稿が取得されたところのイベントにもフックしており、そこで、予めシンタックスをハイライトする記事が入ってるかどうかチェックしている。その時に、入ってなかったらもう後は動作させない、みたいな設計。で、そのチェックのための投稿IDの保管のためのルーティンが, save_post update_post wp_insert_post_dataなどにフックでされているのだけど、これが is_admin() の条件ブロック内で記述されているため、REST API で記事が作成される時に呼び出されない。
なので、それらを REST API のリクエスト時にもフックしてあげることで問題は解決できる。
Rest API Support for Crayon Syntax Highlighter
この問題は Gutenberg に限らず、REST API を使って記事の作成をする場合全てに当てはまるので、色んなケースで必要になるのではないかと重い、せっかくなのでプラグインにした。
使い方はプラグインを有効にするだけ。軽いプラグイン。
REST リクエストページロードの判定
ちなみに、今のところ、REST リクエストのページかどうかの判定の関数はないみたい。なので、$SERVER[ 'REQUEST_URI' ] に/wp-json/の文字列の有無で判定させている。ただ、これが完全に頼れるものかどうかはまだ検証不足。is_admin() が実行中 URL 内の /wp-admin/ で判定しないのは、ユーザー側でURLのストラクチャを変更できるような使い方を想定しているのか、何かしら理由があるのだろうけど、そのあたり深く詰めてはいない。
実際使用した関数は次の通り。
|
1 2 3 4 5 6 7 |
static public function isREST() { $_aURIParts = explode( '?', $_SERVER[ 'REQUEST_URI' ] ); if ( false === strpos( $_aURIParts[ 0 ], '/wp-json/' ) ) { return false; } return true; } |
それと、( defined( 'REST_REQUEST' ) && REST_REQUEST ) も使えるかな、と試したけど、これは parse_request アクションイベント内 で定義されており、wp アクションイベントのちょい手前でトリガーされる。なので、init アクションイベント時に判定しようとしても使えない。
Gutenberg の行方
色々物議を醸している Gutenberg 。確かに、既存のプラグインが使えなくなるというのはダメージだ。Gutenberg を除外するプラグインまで出る始末。そちらの方が断然評価が高かったりする。ユーザーからの抵抗は激しさを見せる中、WordPress はこのエディタを予定通り採用するのだろうか。そして、その結果、ユーザー数がどう推移するのか興味があるところ。
