Ajout de admin-ajax.php au frontend. Bonne ou mauvaise idée?

J'adore admin-ajax.php. Mais je déteste devoir localiser pour y pointer des scripts frontaux, et j'aimerais qu'il y ait un fichier équivalent et facile à trouver pour les thèmes. (Cela me dérange également de voir les demandes frontales 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 de "/ajax.php", ajusté les chemins d'inclusion et supprimé la définition de la constante WP_ADMIN. Semble fonctionner comme des gangbusters (je peux maintenant diriger toutes mes requêtes AJAX frontend vers /ajax.php! Et je peux toujours utiliser les hooks wp_ajax normaux dans mes plugins!).

Mais est-ce sûr? Qu'est-ce qui pourrait mal tourner? Comme cela n'est pas intégré au cœur, je suppose qu'il y a une bonne raison de ne pas le faire. Mais en parcourant le code, je ne vois aucun problème immédiat.

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

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

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

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

Premièrement: la normalisation. Si vous prévoyez d'utiliser des plugins de communauté, il est probable qu'ils ne se soucieront pas de votre /ajax.phpfichier à la racine du document. Ils ne l'utiliseront donc pas.

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

Deuxièmement: que faire si le noyau est mis à jour? Allez-vous surveiller et modifier votre fichier ajax?

Troisièmement : bien qu'il admin-ajax.phpréside wp-admin, il ne charge aucun élément de la zone d'administration (par exemple, les listes de tables, etc.). Il ne vérifie pas non plus l'authentification et n'expose rien de sensible aux utilisateurs non connectés. C'est comme un fichier frontal, en d'autres termes. Rien à craindre.

Quatrièmement: liés 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 d'aucun élément côté serveur. Vous allez durer une URL qui se cassera si / quand le site se déplace? Semble être un mauvais choix.

Si vous ne voulez vraiment pas localiser tous les scripts qui utilisent Ajax, connectez-vous wp_headtrès tôt et crachez l'URL ajax admin. Problème résolu (c'est exactement la façon dont la zone d'administration le fait, soit dit en passant).

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

Comme pour beaucoup de choses dans WordPress, il existe un nombre presque infini de façons de dépouiller le chat. Bien que toutes les méthodes acceptées fonctionnent, j'ai trouvé qu'elles sont moins "soignées" que l'utilisation de wp_localize_script pour inclure la capacité ajax sur le front-end.

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' )
        )
    );
}

Et puis dans le se83650.jsfichier, vous référenceriez votre variable avec se83650Ajax.ajaxurl.

L'avantage de cette technique est que si vous vous retrouvez avec de nombreux plugins qui essaient de dupliquer cette fonctionnalité, ils n'incluent pas ou n'écrasent pas la même variable. ajaxurlest assez générique à inclure, cela vous permet de mieux vous contenir et il joue mieux avec d'autres développeurs.