Quiero deshabilitar esto solo para un Tipo de publicación, ya que realmente no importa si hay otro usuario que lo esté editando (el área principal de edición de contenido es Ajaxified y los no administradores solo pueden ver eso).
Miré las funciones principales pero no pude encontrar un punto de entrada. Por la función, wp_set_post_lock
supongo que tendría que interceptar get_post_meta
, pero ¿hay alguna forma oficial de hacerlo?
Y hay un segundo bloqueo que no parece verse afectado por el filtro wp_check_post_lock_window
( como lo muestra birgire , aquí en una Respuesta). Lo he intentado remove_filter( 'heartbeat_received', 'wp_refresh_post_lock', 10, 3 );
en varios puntos, pero sigue latiendo sin respetar remove_filter
.
wp-admin
heartbeat-api
brasofilo
fuente
fuente
post_lock
no obstante.Respuestas:
Como complemento a la respuesta @birgire ...
Recomendaciones
register_post_type()
permite registrar un soporte de tipo de publicación, que también se puede hacer más adelante usandoadd_post_type_support()
. Y eso puede verificarse incluso más tarde usando el todo poderosopost_type_supports( $cpt, $feat )
.Un mini plugin general que agrega una nueva característica
Ahora el siguiente complemento (mu-) busca un nuevo tipo de soporte de tipo de publicación que deshabilite la función de bloqueo de publicación. Se llama
disabled_post_lock
.Un complemento por CPT
Luego, podemos agregar fácilmente mini complementos para deshabilitar el soporte de tipo de publicación para nuestros complementos propios o de terceros (ahorrándonos algo de ancho de banda y tamaño de base de datos en la metatabla del usuario):
Tan pronto como se active el segundo complemento, nuestro tipo de publicación de cerveza ya no tendrá más bloqueo de publicación. Esto debería funcionar bien y es fácilmente revertable a través de la pantalla de administración de complementos.
Deshabilitar la API de latidos
Extender el complemento para deshabilitar también la API de hearbeat:
fuente
admin-ajax.php
pieza (Q actualizado y A agregado)?wp.heartbeat.start();
su JavaScript.post_type_supports
para manejar esto para cada tipo de publicación personalizada, desearía poder darle más votos a favor ;-)Para eliminar la ventana emergente de bloqueo de edición , puede intentar:
No estoy seguro de si este es el camino a seguir, pero verifiqué la fuente
wp_check_post_lock()
y allí tenemos estas líneas:entonces la idea es cambiar,
$time_window
entonces laif
condición esfalse
.Actualizar:
Para aplicar esto en la
edit.php
pantalla, con el tipo de publicación personalizada,beer
por ejemplo:Y luego podemos agregar:
para eliminarlo también para la
post.php
pantalla.Más excavaciones ...
La función
_admin_notice_post_locked()
se define justo debajo de lawp_set_post_lock()
función. Contiene estas líneas:entonces uno también puede probar el
show_post_locked_dialog
filtro:fuente
__return_false()
como la primera verificación para$time
resumirlo como abool TRUE
?$time
defalse
modo que fui a$time_window
su lugar ...La combinación final que terminé de usar es
pero si alguien tiene otra opinión, me encantaría saberlo, ya que realmente no entiendo la imagen completa de los filtros disponibles.
fuente
get_current_screen()->post_type
en su lugar. Aquí hay un buen complemento llamado Current Admin Info para ayudarlo a recuperar dicha información.DOING_AJAX
cheque ... Y como lo entiendo, Ajax no tieneglobal $current_screen
(devuelto porget_current_screen()
).wp_is_autosave()
seguro de si eso tiene en cuenta cualquiera de esas acciones.add_filter( 'show_post_locked_dialog', '__return_false' );
, desde la función_admin_notice_post_locked()
, ¿es de alguna ayuda?wp_ajax_heartbeat()
(wp-admin / includes / ajax-actions.php) usando la cadenaload-$hook
->get_current_something()
. . . . . Además, hay 3 ganchos en esa función, pero no puedo detener el ritmo al usarlos (y tienen$screen_id
, que coincide con el tipo de publicación.Aquí está la solución final que funciona para mí. :
fuente