¿Por qué no registrar shortcodes si is_admin dashboard?

10

Me he dado cuenta de que algunos complementos como Contact-form-7 , Nextgen-gallery , posiblemente otras, tienen una interesante función de no registrar sus códigos cortos cuando is_admin() es verdadero.

Lo problemático es que, si quieres generar algún contenido dinámico (que puede tener un código corto) desde ajax, y usar la forma wp "correcta" de hacerlo, admin-ajax.php, es imposible no tener WP_ADMIN ser cierto. Vea las primeras líneas de admin-ajax.php:

define( 'DOING_AJAX', true );
if ( ! defined( 'WP_ADMIN' ) ) {
    define( 'WP_ADMIN', true );
}

Ahora, parece que hay extensiones de PHP que te permitirán des-establecer una constante definida (hacky), o puede haber una manera de meterse con el sistema WP_Screen no documentado y $GLOBALS['current_screen'] para hacer que la función is_admin() devuelva falso ?? La solución más útil parece ser la publicación en la página o en la raíz del sitio.

¿Es común que los complementos registren sus códigos cortos cuando is_admin() es falso? Si es así, no pude encontrar ninguna documentación o razón por la cual no sea una optimización prematura.

    
pregunta NoBugs 21.05.2015 - 07:21

2 respuestas

6

Hace tiempo que observé el mismo problema con contact-form-7.

Pero tenga en cuenta que el registro de códigos breves basados en is_admin es doing_it_wrong ( vea la respuesta de gmazzap )

Hay dos razones por las que parecen legítimas a primera vista (y por qué están equivocadas):

  1. (Improbable) El autor del complemento intentó optimizar el script para registrar solo los códigos cortos cuando son necesarios. En este caso, el autor no consideró que el código abreviado pudiera usarse en las solicitudes de Ajax.

    Incorrecto porque : esta optimización no proporciona ninguna ganancia de rendimiento. Simplemente agrega un valor a la matriz global de "códigos cortos registrados".

  2. (Este es el más probable) El autor del complemento deshabilitó intencionalmente el soporte para el código corto en las solicitudes de Ajax. Con Contact-Form-7 este es posiblemente el caso porque los formularios se pueden configurar para "Enviar vía Ajax". Sin embargo, esta función requiere el formulario para cargar archivos javascript adicionales que no se cargan cuando se analiza el shortcode a través de Ajax y javascript se agrega a través de enqueue_scripts() .

    El autor decidió deshabilitar la compatibilidad con Ajax para evitar informes de errores como "No usar esto: se muestra el formulario, pero hacer clic en el botón Enviar no funciona. ¡Pérdida de tiempo completa!"

    Por lo tanto, el usuario verá un formulario de trabajo garantizado o ningún formulario.

    Incorrecto porque : la comprobación de is_admin es una mala práctica aquí. El estado debe verificar si la constante DOING_AJAX está definida y es verdadera.

Aunque la mayoría de los complementos no usan este tipo de condición, los pocos que tienen esa restricción posiblemente la tienen debido a problemas en el pasado.

Cuando un shortcode simplemente está haciendo algo de salida en la página, no hay razón para agregar ninguna condición de administrador. Sin embargo, cuando el shortcode también pone en cola los archivos js o css, entonces tiene sentido limitar el uso a solicitudes que no sean de administrador / ajax.

    
respondido por el Philipp 23.05.2015 - 17:37
3

En realidad, no hay razón para no registrar códigos cortos en admin.

Si el autor de los complementos desea deshabilitar el formulario Ajax, debería hacerlo

if (defined('DOING_AJAX') && DOING_AJAX)

en lugar de buscar es admin.

Tenga en cuenta que en el futuro, es posible que Shortcake se incruste en el núcleo porque es un "complemento de funciones".

Si ocurrirá, el shortcode no definido en admin no funcionará con él. Esto le da otra confirmación de que no hay razón para no registrar códigos cortos en admin: incluso los desarrolladores centrales están trabajando en cosas que requieren códigos cortos disponibles en admin.

Dicho esto, tienes posibilidades:

  1. contactar con el autor de los complementos y ver si pueden corregir ese comportamiento
  2. intenta encontrar una solución por ti mismo

Con respecto al # 2, en realidad existen bibliotecas que pueden hacer que is_admin sea verdadero. Por que son piratas, y nunca los usaría en producción.

Un ejemplo es Patchwork .

Al usarlo, puedes anular cualquier función personalizada de PHP.

En un complemento de MU puede hacerlo (completamente SIN PROBAR):

add_action('muplugins_loaded', function() {
  if ( defined('DOING_AJAX') && DOING_AJAX ) {
     require 'path/to/Patchwork.php';
     Patchwork\replace("is_admin", function() {
        return FALSE;
     });
  }
});

Esto hará que is_admin() devuelva false en las solicitudes de ajax.

Sin embargo, como se dijo, esto es bastante intrincado y afectará el comportamiento de otros complementos (y núcleo) con efectos impredecibles.

Otra cosa que puedes hacer es registrar el controlador de código corto del complemento en las solicitudes de administración.

Por ejemplo, si el código del plugin es:

if (! is_admin()) {
  add_shortcode( 'shortcode' , 'plugin_shortcode_handler' );
}

luego usted puede escribir otro complemento que lo haga:

if (is_admin()) {
  add_shortcode( 'shortcode' , 'plugin_shortcode_handler' );
}

De esta manera, el código abreviado se agregará en ambos casos.

Esto puede o no funcionar solo dependiendo de otro código de complemento, pero no hay una respuesta general para esto.

    
respondido por el gmazzap 24.05.2015 - 11:12

Lea otras preguntas en las etiquetas