Ajout de admin-ajax.php à l'interface. Bonne ou mauvaise idée?

15

J'aime admin-ajax.php. Mais je déteste avoir à localiser pour y pointer des scripts frontaux, et j'aimerais qu'il existe un fichier équivalent, facile à trouver, pour les thèmes. (Cela me dérange aussi de voir les requêtes de front-end passer par "/ wp-admin /". Aucune raison pratique, ça a l'air moche, IMO.)

J'ai donc simplement copié admin-ajax.php dans le répertoire racine à "/ajax.php", ajusté les chemins d'inclusion et supprimé la définition de constante WP_ADMIN. Semble fonctionner comme des gangbusters (je peux maintenant simplement diriger toutes mes requêtes AJAX frontales vers /ajax.php! Et je peux toujours utiliser les hooks wp_ajax dans mes plugins!).

Mais est-ce sécuritaire? Qu'est-ce qui pourrait mal tourner? Etant donné que cela n’est pas intégré au noyau, je suppose qu’il ya une bonne raison de ne pas le faire. Mais en regardant à travers le code, je ne vois pas de problèmes immédiats.

Vous êtes intelligent - dites-moi si cette approche est folle. Ou s'il y a une méthode plus simple que je néglige.

    
posée MathSmath 29.01.2013 - 18:36

3 réponses

16

Vous pouvez simplement utiliser un RewriteRule pour votre .htaccess au-dessus des règles habituelles de réécriture de liens permanents:

RewriteRule ^ajax$ /wp-admin/admin-ajax.php [L]

Envoyez maintenant vos requêtes AJAX à example.com/ajax et ne ratez plus les modifications apportées à ce fichier après les mises à niveau.

    
réponse donnée fuxia 29.01.2013 - 18:51
5

Premier: standardisation. Si vous envisagez d'utiliser des plugins de communauté, il est probable qu'ils ne se soucient pas de votre fichier /ajax.php dans la racine du document. Donc, ils ne l'utiliseront pas.

Si vous voulez tout rouler vous-même, ce n'est pas un problème.

Deuxièmement: que se passe-t-il si les mises à jour principales? Voulez-vous surveiller et modifier votre fichier ajax?

Troisième : malgré le fait que admin-ajax.php réside dans wp-admin , il ne charge aucun élément de la zone d'administration (par exemple, les tables de liste, etc.). Il ne vérifie pas non plus l'authentification ou n'expose aucun élément sensible aux utilisateurs non connectés. C'est comme un fichier frontal, en d'autres termes. Rien à craindre.

Quatrième: En ce qui concerne le premier problème, certains plug-ins vont vérifier avant de charger à l'aveuglette les fonctionnalités liées à ajax. Un exemple est ci-dessous. Votre ajax.php modifié ne provoquera probablement pas ce chargement.

<?php
if (is_admin() && defined('DOING_AJAX') && DOING_AJAX) {
    //  load ajax stuff
}

Enfin: vous vous plaignez, utiliser la localisation pour obtenir l'URL Ajax est une bonne chose à faire. Pourquoi? Parce que vos fichiers JS ne sont au courant de rien du côté serveur. Vous allez avoir du mal à créer une URL qui se brisera si / quand le site sera déplacé? Cela semble être un mauvais choix.

Si vous ne voulez vraiment pas localiser tous les scripts utilisant Ajax, branchez-le très tôt dans wp_head et crachez l'URL admin ajax. Le problème est résolu (c'est exactement ce que fait la zone administrative, au fait).

<?php
add_action('wp_head', 'wpse83650_lazy_ajax', 0, 0);
function wpse83650_lazy_ajax()
{
    ?>
    <script type="text/javascript">
    /* <![CDATA[ */
    var ajax_url = "<?php echo esc_js(admin_url('admin-ajax.php')); ?>";
    /* ]]> */
    </script>
    <?php
}
    
réponse donnée chrisguitarguy 29.01.2013 - 19:02
5

Comme dans WordPress, il existe un nombre presque infini de méthodes pour écorcher le chat. Bien que toutes les méthodes acceptées fonctionnent, j’ai trouvé qu’elles étaient moins "ordonnées" que d’utiliser wp_localize_script pour inclure la fonctionnalité ajax l'extrémité avant.

Découvrez ceci:

add_action( 'wp_enqueue_scripts', 'se83650_js' );
function se83650_js()
{
    wp_enqueue_script( 'se83650-js', plugin_dir_url( __FILE__ ) . 'js/se83650.js',  'jquery', '1.0.0', true );
    // First param is the name of the script you are attaching it to - in this case
    // it is the name of the custom script we added.  Second param is the name of 
    // the javscript Object that will be attached with your information.
    // Third param is an array of attributes, in this case, ajaxurl
    wp_localize_script( 'se83650-js', 'se83650Ajax', 
        array(
            // You can put any variables here you want for your script
            // such as plugin-specific variables or nonces, etc.
            'ajaxurl'    => admin_url( 'admin-ajax.php' )
        )
    );
}

Ensuite, dans le fichier se83650.js , vous feriez référence à votre variable avec se83650Ajax.ajaxurl .

L'avantage de cette technique est que, si vous vous retrouvez avec de nombreux plug-ins essayant de dupliquer cette fonctionnalité, ils n'incluent ni ne remplacent la même variable. ajaxurl est assez générique à inclure, cela vous rend plus contenu et il est plus agréable à jouer avec les autres développeurs.

    
réponse donnée bybloggers 05.02.2013 - 21:19

Lire d'autres questions sur les étiquettes