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

10

J'ai remarqué que certains plugins tels que Formulaire de contact 7, Nextgen-gallery , peut-être d’autres, ont un anti-fonctionnalité intéressant consistant à ne pas enregistrer leurs codes abrégés lorsque is_admin() est true.

Le problème, c’est que si vous voulez générer du contenu dynamique (qui peut avoir un shortcode) à partir de ajax, et utiliser la méthode "correcte" de wp, admin-ajax.php, il est impossible de ne pas avoir WP_ADMIN. Sois sincère. 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 existe des extensions PHP qui vous permettent de dé-définir une constante définie (hacky), ou il existe un moyen de jouer avec le système non documenté WP_Screen et à $GLOBALS['current_screen'] de faire en sorte que la fonction is_admin() retourne false ?? 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 codes abrégés lorsque is_admin() est false? Si tel est le cas, je n’aurais pas trouvé de documentation ni de raison autre que l’optimisation prématurée.

    
posée NoBugs 21.05.2015 - 07:21

2 réponses

6

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

Notez cependant que l'enregistrement de codes courts basés sur is_admin est doing_it_wrong ( voir la réponse de gmazzap )

Il y a deux raisons qui paraissent légitimes à première vue (et pourquoi elles se trompent):

  1. (Peu probable) L'auteur du plug-in a tenté de optimiser le script afin d'enregistrer les codes abrégés uniquement 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 parce que : cette optimisation ne procure aucun gain de performances. Il ajoute simplement une valeur au tableau global "shortcodes enregistrés".

  2. (C’est le cas le plus probable) L’auteur du plug-in a désactivé intentionnellement la prise en charge du shortcode dans les requêtes Ajax. Avec Contact-Form-7, c'est peut-être le cas, car les formulaires peuvent être réglés sur "Soumettre via Ajax". Cependant, cette fonctionnalité nécessite le formulaire pour charger 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 empêcher les rapports de bogues du type "Ne pas utiliser ceci: le formulaire est affiché, mais cliquer sur le bouton Soumettre ne fonctionne pas. Perte de temps totale!"

    Ainsi, l'utilisateur verra soit un formulaire dont le fonctionnement est garanti, soit aucun formulaire.

    Mauvais car : la vérification de is_admin est une mauvaise pratique dans ce cas. La condition doit vérifier si la constante DOING_AJAX est définie et vraie.

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

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

    
réponse donnée Philipp 23.05.2015 - 17:37
3

En fait, il n'y a aucune raison de ne pas enregistrer les codes courts sur l'administrateur.

Si l'auteur d'un plugin souhaite désactiver le plugin sous la forme 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 le Shortcake soit intégré au noyau car il s’agit d’un "plug-in de fonctionnalité".

Si cela se produit, le shortcode non défini dans admin ne fonctionnera pas avec cela. Cela vous confirme une fois de plus qu’il n’ya aucune raison de ne pas enregistrer de codes abrégés sous admin: même les développeurs principaux travaillent sur des tâches qui exigent des codes abrégés disponibles sous admin.

Cela dit, vous avez des possibilités:

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

En ce qui concerne le n ° 2, il existe des bibliothèques qui peuvent forcer is_admin à être vrai. Par ils sont hackish, et je n’utiliserais jamais ceux de la production.

Un exemple est Patchwork .

En l'utilisant, vous pouvez remplacer n'importe quelle fonction personnalisée PHP.

Dans un plug-in MU , vous pouvez effectuer (complètement UNTESTED):

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

Ceci fera que is_admin() retournera false pour les requêtes ajax.

Cependant, comme indiqué précédemment, il s’agit d’un projet assez rudimentaire qui affectera le comportement d’autres plugins (et du noyau) avec des effets imprévisibles.

Vous pouvez également enregistrer le gestionnaire de shortcode du plug-in sur les requêtes de l'administrateur.

E.g. si le code du plugin est:

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

alors vous pouvez écrire un autre plug-in qui:

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

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

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

    
réponse donnée gmazzap 24.05.2015 - 11:12

Lire d'autres questions sur les étiquettes