Je souhaite désactiver cela uniquement pour un type de publication, car cela n'a pas vraiment d'importance si un autre utilisateur le modifie (la zone principale de modification du contenu est Ajaxified et les non-administrateurs ne peuvent que le voir).
J'ai regardé les fonctions principales mais je n'ai pas trouvé de point d'entrée. D'après la fonction, wp_set_post_lock
je suppose que je devrais intercepter le get_post_meta
, mais y a-t-il un moyen officiel 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 , ici dans une réponse). J'ai essayé remove_filter( 'heartbeat_received', 'wp_refresh_post_lock', 10, 3 );
à plusieurs reprises mais ça continue de battre sans respecter remove_filter
.
la source
post_lock
quand même un crochet approprié .Réponses:
En complément de la réponse @birgire …
Résultats
register_post_type()
permet d'enregistrer un support de type post, qui peut aussi bien être fait plus tard en utilisantadd_post_type_support()
. Et cela peut être vérifié encore plus tard en utilisant le tout puissantpost_type_supports( $cpt, $feat )
.Un mini plugin général qui ajoute une nouvelle fonctionnalité
Maintenant, le plugin (mu) suivant vérifie un nouveau type de support de type de publication qui désactive la fonction de verrouillage de publication. C'est nommé
disabled_post_lock
.Un plugin par CPT
Ensuite, nous pouvons facilement ajouter des mini plugins pour désactiver la prise en charge du type de post pour nos propres plugins ou tiers (nous économisant de la bande passante et de la taille de la base de données dans la méta-table utilisateur):
Dès que le deuxième plugin est activé, notre type de poste de bière n'a plus de verrouillage de poste. Cela devrait fonctionner correctement et est facilement réversible via l'écran d'administration des plugins.
Désactiver l'API Heartbeat
Extension du plugin pour désactiver également l'API Hearbeat:
la source
admin-ajax.php
pièce (Q mis à jour et A ajouté)?wp.heartbeat.start();
dans votre JavaScript.post_type_supports
pour gérer cela pour chaque type de message personnalisé, j'aimerais pouvoir vous donner plus de votes positifs ;-)Pour supprimer la fenêtre contextuelle de verrouillage d'édition , vous pouvez essayer:
Je ne sais pas si c'est la voie à suivre, mais j'ai vérifié la source de
wp_check_post_lock()
et là nous avons ces lignes:donc l'idée est de changer
$time_window
laif
conditionfalse
.Mise à jour:
Pour appliquer cela à l'
edit.php
écran, avec le type de message personnalisébeer
par exemple:Et puis on peut ajouter:
pour le supprimer également pour l'
post.php
écran.Plus de fouilles ...
La fonction
_admin_notice_post_locked()
est définie juste en dessous de lawp_set_post_lock()
fonction. Il contient ces lignes:donc on peut aussi essayer le
show_post_locked_dialog
filtre:la source
__return_false()
place comme premier contrôle pour$time
résumer simplement en tant quebool TRUE
?$time
àfalse
alors je suis allé à la$time_window
place ...La combinaison finale que j'ai fini d'utiliser est
mais si quelqu'un a une autre prise, je serais ravi d'entendre, car je ne comprends pas vraiment l'ensemble des filtres disponibles.
la source
get_current_screen()->post_type
place. Voici un joli plugin appelé Current Admin Info pour vous aider à récupérer ces informations.DOING_AJAX
vérifications ... Et si je comprends bien, Ajax n'a pasglobal $current_screen
(retourné parget_current_screen()
).wp_is_autosave()
- je ne sais pas si cela explique l'une de ces actions.add_filter( 'show_post_locked_dialog', '__return_false' );
la fonction_admin_notice_post_locked()
est utile?wp_ajax_heartbeat()
(wp-admin / includes / ajax-actions.php) en utilisant la chaîneload-$hook
->get_current_something()
. . . . . De plus, il y a 3 crochets dans cette fonction, mais je ne suis pas en mesure d'arrêter le rythme en les utilisant (et ils en ont$screen_id
, ce qui correspond au type de message.Voici la solution finale qui fonctionne pour moi. :
la source