web-dev-qa-db-fra.com

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

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 également de voir les demandes des clients se faire passer par "/ wp-admin /". Aucune raison pratique, ça n'a pas l'air très beau, 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 normaux dans mes plugins!).

Mais est-ce sécuritaire? Qu'est-ce qui pourrait mal tourner? Étant donné que cela ne fait pas partie intégrante du noyau, je suppose qu'il y a 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.

themesajax
16
MathSmath

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

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

Envoyez maintenant vos demandes AJAX à example.com/ajax et ne manquez jamais les modifications principales apportées à ce fichier après les mises à niveau.

17
fuxia

Premièrement: normalisation. Si vous envisagez d'utiliser des plug-ins 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: et si les mises à jour de base? Voulez-vous surveiller et modifier votre fichier ajax?

Troisième : malgré 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: Relativement au premier problème, certains plugins vérifieront avant de charger aveuglément 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: Ce dont 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 une URL difficile à casser si/quand le site sera déplacé? Cela semble être un mauvais choix.

Si vous ne voulez vraiment pas localiser chaque script qui utilise Ajax, connectez-vous très tôt à wp_head et crachez l'URL admin ajax. Problème résolu (c'est exactement comme ça que l'administration le fait, d'ailleurs).

<?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
}
6
chrisguitarguy

Comme avec beaucoup de choses dans WordPress, il existe un nombre presque infini de façons de peau le chat. Bien que toutes les méthodes acceptées fonctionnent, j’ai trouvé qu’elles sont moins "ordonnées" que l’utilisation de wp_localize_script pour inclure la capacité ajax au niveau du frontal.

Regarde ça:

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 référencez 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.

5
bybloggers