Перенаправить на “Все записи” после обновления или публикации поста в редакторе блоков

Когда кто-либо нажимает Опубликовать или Обновить в Редакторе блоков для пользовательского типа записей (CPT), я хотел бы, чтобы его перенаправляло на страницу списка CPT. (Пользователи обычно редактируют много CPT одновременно, так что это сэкономит им шаг – и также предотвратит от повторного нажатия Обновить несколько раз, потому что они не уверены, были ли их изменения сохранены.)

Я пробовал два различных хуков:

Из вопроса 2013 года, redirect_post_location:

add_filter( 'redirect_post_location', 'wpse_124132_redirect_post_location' );
function wpse_124132_redirect_post_location( $location ) {
    if ( isset( $_POST['save'] ) || isset( $_POST['publish'] ) )
        return admin_url( 'edit.php?post_type=mycptslug' );
    return $location;
}

(Меня интересует, влияет ли это только на основные записи, поскольку хук содержит “post” в своем названии? Это почти не задокументировано. Изменилось ли это с 2013 года или просто не работает с новым редактором, он не перенаправлял.)

И из моих собственных знаний о хуке save_post:

add_action( 'save_post', 'wpse_redirect_to_dashboard', 40, 3 );
function wpse_redirect_to_dashboard( $post_id, $post, $update ) {
    global $_POST;
    // Поскольку save_post выполняется 4 раза, убедитесь, что это последний запуск
    if( count( $_POST ) > 0 && true === $update && 'mycptslug' === $post->post_type ) {
        wp_redirect( admin_url( 'edit.php?post_type=mycptslug' ) ); exit;
    }
}

(Я подтвердил, что условие if работает, как задумано – я временно записывал сообщение об успехе в текстовый файл, и оно срабатывало каждый раз, когда я нажимал Обновить в редакторе, – но не перенаправляло. Также пробовал перенаправлять на другие URL, на случай если часть admin_url() не работала, но по-прежнему не было перенаправления.)

К сожалению, ни один из этих хуков не работает с Редактором блоков. Пользователь по-прежнему остается в редакторе после обновления. Есть ли какой-то другой способ, например, во время регистрации CPT или с использованием другого хуку, чтобы успешно перенаправить пользователя после внесения изменений?

На основе ответа cjbj у меня есть этот обновленный код – но он все еще не перенаправляет. Я не совсем уверен, что значит загружать его поздно или как обеспечить его выполнение после ajax вызова сохранения. (Это работает для любого типа записей, однако):

function wpse_redirect_to_post_list() {
    ?>
    <script>
        // Получение типа записи из скрытого поля
        let postType=document.querySelector('form.metabox-base-form input#post_type').value;
        // При нажатии кнопки "опубликовать / обновить / отправить изменения" перенаправить на список cpt
        jQuery( document ).ready( function( $ ) {
            var url="/wp-admin/edit.php?post_type=" + postType;
            $( '.editor-post-publish-button__button' ).click( function() {
                window.location.href = url;
            });
        });
    </script>
    <?php
}
add_action( 'admin_print_footer_scripts', 'wpse_redirect_to_post_list' );

Насколько я вижу, функция redirect_post, где находится фильтр redirect_post_location, нигде не вызывается автоматически, так что этот фильтр не будет срабатывать. Хук save_post (или предпочтительно save_post_post_type) все еще работает, но не с метабоксами, так как Gutenberg сохраняет их отдельно используя ajax вызовы. Ajax вызовы работают в фоновом режиме и не влияют на текущую страницу. В результате перенаправления не работают.

Таким образом, вы не можете надежно перенаправить, вызывая сервер. Однако вы можете перенаправить на стороне пользователя, привязав дополнительное действие jQuery к кнопке сохранения. Что-то вроде этого:

jQuery( document ).ready( function( $ ) {
    var url="your_url/edit.php?post_type=mycptslug";
    $( '.editor-post-publish-button__button' ).on( 'click',
        function() {
            window.location.href = url;
            });
        }
    );
});

Примечание: Не тестировал jQuery, так что могут быть ошибки, но вы поняли суть. Убедитесь, что это выполняется после ajax вызова сохранения, загружая его поздно.