araki tech

for developers including me

WordPress Gutenbergで投稿公開・更新後にそのページへリダイレクトさせる方法

はじめに

WordPress のブロックエディタ (Gutenberg) のエディタ仕様は、投稿を公開したり更新した場合には、そのエディタのページに留まったままです。

“投稿を表示するボタン” が出てくるのですが、場合によってはその投稿ページに自動でリダイレクトされた方が都合が良い場合があります。

例えば私の場合は、とあるチーム内のドキュメントツールとして運用が手軽であるWordpressをベースに、MyWikiをカスタマイズして利用していますが、ユーザには管理者ページに止まるメリットはほとんどありません。

新規投稿・投稿更新したら、そのページ (というか非管理者ページ) に遷移した方が次の作業に取り掛かりやすいです。

今回は、その実現方法がわかったのでメモ。

ちなみにNode.jsは未使用で実現できる方法です。

実現方法

結論ですが、ブロックエディタ用のフックを利用します。

フックで発火するJavascriptから見ていきましょう。

テーマディレクトリ直下に /my-block/block.js のようなファイルを作成してください。

block.js

( function( blocks, element, data ) {
    observePostSaving(data);
}(
    window.wp.blocks,
    window.wp.element,
    window.wp.data,
) );

function observePostSaving(data) {
    data.subscribe(
        function () {
            const editor = data.select('core/editor');
            if (
                editor.isSavingPost() &&
                !editor.isAutosavingPost() &&
                editor.didPostSaveRequestSucceed() &&
                editor.isCurrentPostPublished()
            ) {
                setTimeout(function() { window.location.href = editor.getPermalink(); }, 1000);
            }
        }
    );
}

関数名などは自由です。

ここで、注目すべきなのはThe Post Editor’s Data (data.select('core/editor')) の部分です。

wp.dataにはWordpress内で扱われる様々なデータが管理されていて、今回はエディタに関するデータを扱います。

data.subscribeで様々なイベントを監視できます。

条件式については下記のとおりです。

  • editor.isSavingPost() … エディタが投稿を保存しているイベントか否か
  • editor.isAutosavingPost() … エディタが自動保存しているイベントか否か (今回は自動保存ではリダイレクトしてほしくないので条件反転しています)
  • editor.didPostSaveRequestSucceed() … 保存リクエストが成功したか (失敗しているのにも関わらずリダイレクトしてしまうと下書きデータが失われる可能性があるので入れています)
  • editor.isCurrentPostPublished() … 現在の投稿が投稿されているか (投稿が完全になされる前に上記3つは呼ばれるタイミングがあるので、完全に保存されたタイミング = 投稿完了 時点での評価をします)

そして

setTimeout(function() { window.location.href = editor.getPermalink(); }, 1000);

ですが、即座にリダイレクトしようとすると、ブラウザが注意ダイアログを出してきてしまったので1秒だけリダイレクトを遅延させています。

この処理については少し強引なので、もしかしたら他に良い手があるかもしれません…。

function.php

block.jsが完成したら実際にフックを登録します。

function block_enqueue(): void {
    wp_enqueue_script(
        'core/editor',
        get_theme_file_uri('/my-block/block.js'),
        array( 'wp-blocks', 'wp-element', 'wp-data', 'wp-editor'),
        filemtime(get_theme_file_path('/my-block/block.js'))
    );
}
add_action('enqueue_block_editor_assets', 'block_enqueue');

これで完了です。

おわりに

WordPressのブロックエディタは非エンジニアのユーザにとっては直感的であるのは大きなメリットですが、カスタマイズを細かくしようとすると一苦労です。

なかなか情報も見つからず、私も今回の実装方法に辿り着くまでそれなりに時間を要してしまいました…。

最近ブロックエディタのカスタマイズをしていて思うのは、Wordpress側もGutenbergについてはかなり拡張性を考慮した設計をしているということ。

それをドキュメントでわかりやすくまとめてくれていたら助かるのですが。。。

この記事も誰かの役に立てば幸いです。