Je souhaite désactiver cette option uniquement pour un type de publication, car cela n'a pas vraiment d'importance si un autre utilisateur le modifie (la zone d'édition principale du contenu est Ajaxified et les non-administrateurs ne peuvent que le voir).
J'ai regardé les fonctions principales mais je n'ai pas pu trouver de point d'entrée. De la fonction wp_set_post_lock
Je suppose que je devrais intercepter le get_post_meta
, mais existe-t-il un official moyen de le faire?
Et il y a un deuxième verrou qui ne semble pas être affecté par le filtre wp_check_post_lock_window
( comme le montre birgire , dans une réponse). J'ai essayé remove_filter( 'heartbeat_received', 'wp_refresh_post_lock', 10, 3 );
à différents moments, mais il continue de battre sans respecter remove_filter
.
En complément de@birgireanswer…
register_post_type()
permet d’enregistrer un support de type publication, qui peut également être effectué ultérieurement à l’aide de add_post_type_support()
. Et cela peut être vérifié même plus tard en utilisant le très puissant post_type_supports( $cpt, $feat )
.
Maintenant, le plug-in (mu-) suivant recherche un nouveau type de support de type post qui désactive la fonction post-verrouillage. Il s'appelle disabled_post_lock
.
<?php
defined( 'ABSPATH' );
/** Plugin Name: (#120179) Maybe Disable Post Type Support */
add_action( 'load-edit.php', 'wpse120179MaybeDisablePostLock' );
function wpse120179MaybeDisablePostLock()
{
if ( post_type_supports( get_current_screen()->post_type, 'disabled_post_lock' ) )
add_filter( 'wp_check_post_lock_window', '__return_false' );
}
Ensuite, nous pouvons facilement ajouter des mini-plugins pour désactiver la prise en charge des post-types pour nos propres plugins ou des plugins tiers (en nous épargnant de la bande passante et de la taille de la base de données dans la table méta de l'utilisateur):
<?php
defined( 'ABSPATH' );
/** Plugin Name: (#120179) Disable Post Type Support for "Beer" Posts */
add_action( 'init', function()
{
add_post_type_support( 'beer', 'disabled_post_lock' );
} );
Dès que le second plugin est activé, notre typebeerpost n'a plus de post lock. Cela devrait fonctionner correctement et est facilement réversible via l'écran d'administration des plugins.
Extension du plug-in pour désactiver également l'API Hearbeat:
<?php
defined( 'ABSPATH' );
/** Plugin Name: (#120179) Maybe Disable Post Type Support */
add_action( 'load-edit.php', 'wpse120179MaybeDisablePostLock' );
function wpse120179MaybeDisablePostLock()
{
if ( post_type_supports( get_current_screen()->post_type, 'disabled_post_lock' ) )
{
add_filter( 'wp_check_post_lock_window', '__return_false' );
add_filter( 'heartbeat_settings', function( $settings )
{
return wp_parse_args( [ 'autostart' => false ], $settings );
} );
}
}
Pour supprimer la fenêtre edit-lock popup, vous pouvez essayer:
add_filter( 'wp_check_post_lock_window', '__return_zero' );
Je ne suis pas sûr que ce soit la voie à suivre, mais j'ai vérifié la source de wp_check_post_lock()
et nous avons ces lignes:
...cut...
$time_window = apply_filters( 'wp_check_post_lock_window', 120 );
if ( $time && $time > time() - $time_window && $user != get_current_user_id() )
return $user;
return false;
...cut...
l'idée est donc de changer $time_window
pour que la condition if
soit false
.
Pour appliquer cela à l'écran edit.php
, avec le type d'article personnalisé beer
, par exemple:
function wpse_120179()
{
if( 'beer' === get_current_screen()->post_type )
add_filter( 'wp_check_post_lock_window', '__return_zero' );
}
add_action( 'load-edit.php', 'wpse_120179' );
Et puis on peut ajouter:
add_action( 'load-post.php', 'wpse_120179' );
pour le supprimer également pour l'écran post.php
.
La fonction _admin_notice_post_locked()
est définie juste en dessous de la fonction wp_set_post_lock()
. Il contient ces lignes:
...cut...
if ( ! apply_filters( 'show_post_locked_dialog', true, $post, $user ) )
return;
...cut...
donc on peut aussi essayer le filtre show_post_locked_dialog
:
add_filter( 'show_post_locked_dialog', 'wpse_120179_close_dialog', 99, 3 );
function wpse_120179_close_dialog( $show, $post, $user )
{
if( 'beer' === $post->post_type )
return FALSE;
return $show;
}
Voici la solution finale qui fonctionne pour moi. :
function my_remove_post_locked() {
$current_post_type = get_current_screen()->post_type;
// Disable locking for page, post and some custom post type
$post_types_arr = array(
'page',
'post',
'custom_post_type'
);
if(in_array($current_post_type, $post_types_arr)) {
add_filter( 'show_post_locked_dialog', '__return_false' );
add_filter( 'wp_check_post_lock_window', '__return_false' );
wp_deregister_script('heartbeat');
}
}
add_action('load-edit.php', 'my_remove_post_locked');
add_action('load-post.php', 'my_remove_post_locked');
La dernière combinaison que j'ai terminée est d'utiliser
# Takes care of the message "Someone else is editing this"
add_action( 'load-edit.php', function()
{
if( 'beer' === get_current_screen()->post_type )
add_filter( 'wp_check_post_lock_window', '__return_false' );
});
# Takes care of post.php and the "User has taken over" message
add_filter( 'show_post_locked_dialog', function( $bool, $post, $user )
{
if( 'beer' === $post->post_type )
return false;
return $bool;
},
10, 3 );
mais si quelqu'un a une autre prise, j'aimerais entendre, car je ne comprends pas vraiment l'image complète des filtres disponibles.
Auparavant, en utilisant
load-edit.php
+load-post.php
, je devais supprimer le filtrewp_refresh_post_lock
avec:add_action( 'admin_init', function() { if( !defined('DOING_AJAX') || !isset( $_POST['screen_id'] ) || 'beer' !== $_POST['screen_id'] ) return; remove_filter( 'heartbeat_received', 'wp_refresh_post_lock', 10 ); });
mais charger à chaque
admin_init
ne semble pas une bonne idée.