Pourquoi ne pas enregistrer les shortcodes si le tableau de bord is_admin?

J'ai remarqué que certains plugins tels que Contact-form-7 , Nextgen-gallery , peut-être d'autres, ont une anti-fonctionnalité intéressante de ne pas enregistrer leurs shortcodes quand is_admin()c'est vrai.

Le problème est que, si vous voulez générer du contenu dynamique (qui peut avoir un shortcode) à partir d'ajax et utiliser la manière wp "correcte" de le faire, admin-ajax.php, il est impossible de ne pas avoir WP_ADMIN vrai. Voir les premières lignes de admin-ajax.php:

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

Maintenant, il semble qu'il y ait des extensions PHP qui vous permettront de dé-définir une constante définie (hacky), ou il pourrait y avoir un moyen de jouer avec le système WP_Screen non documenté et $GLOBALS['current_screen']de faire en sorte que la is_admin()fonction retourne faux ?? La solution de contournement la plus utilisable semble être la publication sur la page ou la racine du site.

Est-il courant que les plugins enregistrent leurs shortcodes quand is_admin()c'est faux? Si c'est le cas, je n'ai trouvé aucune documentation ou raison autre que celle-ci, il peut s'agir d'une optimisation prématurée.

J'ai observé le même problème avec contact-form-7 il y a quelque temps.

Mais notez que l'enregistrement de shortcodes basé sur is_adminest doing_it_wrong ( voir la réponse de gmazzap )

Il y a deux raisons qui semblent légitimes à première vue (et pourquoi elles ont tort):

1. (Peu probable) L'auteur du plugin a essayé d' optimiser le script pour n'enregistrer les shortcodes que lorsqu'ils sont nécessaires. Dans ce cas, l'auteur n'a pas considéré que le shortcode pouvait être utilisé dans les requêtes Ajax.

   Mauvais car : Cette optimisation n'apporte aucun gain de performances. Il ajoute simplement une valeur au tableau global "shortcodes enregistrés".

2. (C'est le plus probable) L'auteur du plugin a intentionnellement désactivé la prise en charge du shortcode dans les requêtes Ajax. Avec Contact-Form-7, c'est probablement le cas car les formulaires peuvent être définis sur "Soumettre via Ajax". Cependant, cette fonctionnalité nécessite que le formulaire charge des fichiers javascript supplémentaires qui ne sont pas chargés lorsque le shortcode est analysé via Ajax et que javascript est ajouté via enqueue_scripts().

   L'auteur a décidé de désactiver le support Ajax pour éviter les rapports de bogues comme "Ne pas utiliser ceci: le formulaire est affiché mais cliquer sur le bouton Soumettre ne fonctionne pas. Perte de temps complète!"

   Ainsi, l'utilisateur verra soit un formulaire de travail garanti, soit aucun formulaire du tout.

   Mauvais parce que : la vérification is_adminest une mauvaise pratique ici. Le conditon doit vérifier si la constante DOING_AJAXest définie et vraie.

Bien que la plupart des plugins n'utilisent pas ce type de condition, les rares qui ont cette restriction l' ont peut- être en raison de problèmes dans le passé.

Lorsqu'un shortcode effectue simplement une sortie sur la page, il n'y a aucune raison d'ajouter une condition d'administration. Cependant, lorsque le shortcode met également en file d'attente les fichiers js ou css, il est logique de limiter l'utilisation aux demandes non admin / non ajax.

En fait, il n'y a aucune raison de ne pas enregistrer de shortcodes sur admin.

Si l'auteur des plugins souhaite désactiver le plugin sous Ajax, il doit le faire

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

au lieu de vérifier est admin.

Notez qu'à l'avenir, il est possible que Shortcake soit intégré dans le noyau car il s'agit d'un "Plugin de fonctionnalités".

Si cela se produit, le shortcode non défini dans admin ne fonctionnera pas avec. Cela vous donne une autre confirmation qu'il n'y a aucune raison de ne pas enregistrer les shortcodes sur admin: même les développeurs principaux travaillent sur des choses qui nécessitent des shortcodes disponibles sur admin.

Cela dit, vous avez des possibilités:

1. contacter l'auteur des plugins et voir s'ils peuvent résoudre ce problème
2. essayez de trouver une solution par vous-même

Concernant # 2, il existe en fait des bibliothèques qui peuvent forcer is_adminà être vraies. Par elles sont hackish, et je ne les utiliserais jamais en production.

Un exemple est Patchwork .

En l'utilisant, vous pouvez remplacer toute fonction personnalisée PHP.

Dans un plugin MU, vous pouvez faire (complètement non testé):

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

Cela rendra le is_admin()retour faux sur les requêtes ajax.

Cependant, comme dit, c'est assez hackish et affectera le comportement d'autres plugins (et core) avec des effets imprévisibles.

Une autre chose que vous pouvez faire est d'enregistrer le gestionnaire de shortcode de plugin sur les demandes d'administration.

Par exemple, si le code du plugin est:

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

alors vous pouvez écrire un autre plugin qui fait:

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

De cette façon, le shortcode sera ajouté dans les deux cas.

Cela peut ou non fonctionner seul en fonction d'un autre code de plugin, mais il n'y a pas de réponse générale à cela.