¿Por qué no registrar códigos cortos si el panel de control is_admin?

Me he dado cuenta de que algunos complementos como Contact-form-7 , Nextgen-gallery , posiblemente otros, tienen una característica interesante de no registrar sus códigos cortos cuando is_admin()es cierto.

Lo problemático es que, si desea generar algún contenido dinámico (que puede tener código corto) a partir de ajax, y usar la forma wp "correcta" de hacerlo, admin-ajax.php, es imposible que WP_ADMIN sea verdadero. 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 le permitirán desarmar una constante definida (hacky), o puede haber una manera de meterse con el sistema WP_Screen indocumentado y $GLOBALS['current_screen']hacer que la is_admin()función devuelva falso. La solución más útil parece estar publicando 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 podría encontrar ninguna documentación o razón para ello, aparte de que puede ser una optimización prematura.

He observado el mismo problema con contact-form-7 hace un tiempo.

Pero tenga en cuenta que el registro de códigos cortos en función de is_adminestá haciendo_it_wrong ( consulte la respuesta de gmazzap )

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

1. (Poco probable) El autor del complemento intentó optimizar el script para registrar solo códigos cortos cuando se necesitaban. En este caso, el autor no consideró que el shortcode 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 shortcode en las solicitudes de Ajax. Con Contact-Form-7, este es posiblemente el caso porque los formularios se pueden configurar en "Enviar a través de Ajax". Sin embargo, esta función requiere el formulario para cargar archivos javascript adicionales que no se cargan cuando el código corto se analiza a través de Ajax y se agrega javascript a través de enqueue_scripts().

   El autor decidió deshabilitar el soporte de Ajax para evitar informes de errores como "No use esto: se muestra el formulario pero al hacer clic en el botón Enviar no funciona. ¡Perdida de tiempo completa!"

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

   Incorrecto porque : Verificar is_adminaquí es una mala práctica. La condición debe verificar si la constante DOING_AJAXestá 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 tengan debido a problemas en el pasado.

Cuando un shortcode simplemente está produciendo algo 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 archivos js o css, entonces tiene sentido limitar el uso a solicitudes que no sean de administrador / no ajax.

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

Si el autor de complementos desea deshabilitar el formulario de complementos Ajax, deberían 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 sucede, el shortcode no definido en el administrador no funcionará con él. Esto le da otra confirmación de que no hay razón para no registrar códigos cortos en el administrador: incluso los desarrolladores principales están trabajando en cosas que requieren códigos cortos disponibles en el administrador.

Dicho esto, tienes posibilidades:

1. contacte al autor de complementos y vea si pueden arreglar ese comportamiento
2. intenta encontrar una solución por ti mismo

Con respecto al n. ° 2, en realidad existen bibliotecas que pueden forzar is_admina ser verdad. Por hackes, y nunca los usaría en producción.

Un ejemplo es Patchwork .

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

En un complemento MU puedes hacer (completamente NO PROBADO):

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()return sea falso en las solicitudes ajax.

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

Otra cosa que puede hacer es registrar el controlador de shortcode del complemento en las solicitudes de administración.

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

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

entonces puedes escribir otro plugin que haga:

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

De esta manera, se agregará el shortcode en ambos casos.

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