web-dev-qa-db-fra.com

Pourquoi ne pas enregistrer les codes abrégés 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 un anti-caractéristique intéressant de ne pas enregistrer leurs codes courts lorsque is_admin() est vrai.

Le problème 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 comme 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 PHP extensions qui vous permettent de dé-définir une constante définie (hacky), ou il peut y avoir un moyen de jouer avec le système non documenté WP_Screen et $GLOBALS['current_screen'] pour que la fonction is_admin() renvoie 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 ne pourrais trouver aucune documentation ou raison à part cela, ce pourrait être une optimisation prématurée.

ajaxdashboard
10
NoBugs

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

Mais notez que l'enregistrement de codes abrégés basés sur is_admin est doing_it_wrong _ ( voir la réponse de gmazzap )

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

  1. (Peu probable) L'auteur du plug-in a essayé de optimiser le script pour enregistrer uniquement les codes abrégés lorsqu'ils sont nécessaires. Dans ce cas, l'auteur n'a pas considéré que le shortcode pourrait être utilisé dans les requêtes Ajax.

    Faux 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 configurés sur "Submit via Ajax". Toutefois, 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 de travail garanti, soit aucun formulaire.

    Faux parce que : Vérifier is_admin est une mauvaise pratique ici. 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. Toutefois, 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.

6
Philipp

En fait, il n'y a aucune raison de ne pas enregistrer de codes abrégés sur admin.

Si les plugins auteurs veulent désactiver le plugin Ajax, ils doivent le faire.

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

au lieu de vérifier est admin.

Notez que dans le futur, il est possible que Shortcake soit intégré au noyau car il s’agit d’un "plugin de fonctions".

Si cela se produit, le shortcode non défini dans admin ne fonctionnera pas. Cela vous confirme une fois de plus qu'il n'y a 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 sont requis codes abrégés disponibles sous 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. essayer de trouver une solution par vous-même

En ce qui concerne le n ° 2, il existe des bibliothèques capables de forcer is_admin à être vraies. Par ils sont hackish, et je ne les utiliserais jamais dans la 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 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 sur les requêtes ajax.

Cependant, comme indiqué, il s'agit d'un système assez fictif qui affectera le comportement d'autres plugins (et du noyau) avec des effets imprévisibles.

Une autre chose que vous pouvez faire est d’enregistrer le gestionnaire de shortcode du plugin sur les requêtes de l’administrateur.

Par exemple. si le code du plugin est:

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

then you peut écrire un autre plugin 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.

3
gmazzap