Agregar admin-ajax.php a la interfaz. ¿Buena o mala idea?

Puede usar una RewriteRule para su .htaccess por encima de las reglas regulares de reescritura de enlaces permanentes:

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

Ahora envíe sus solicitudes de AJAX a example.com/ajax , y nunca se pierda los cambios centrales en ese archivo después de las actualizaciones.

Primero: estandarización. Si planea usar complementos comunitarios, es probable que no se preocupen por su archivo /ajax.php en la raíz del documento. Así que no lo usarán.

Si vas a rodar todo por ti mismo, esto no es un problema.

Segundo: ¿qué sucede si se actualiza el núcleo? ¿Supervisará y cambiará su archivo ajax?

Tercero : a pesar de que admin-ajax.php reside en wp-admin , no carga ninguna de las cosas del área de administración (por ejemplo, listas de tablas, etc.). Tampoco verifica la autenticación o expone nada sensible a usuarios que no han iniciado sesión. Es como un archivo de front-end, en otras palabras. Nada de qué preocuparse.

Cuarto: En relación con el primer problema, algunos complementos comprobarán antes de cargar ciegamente la funcionalidad relacionada con ajax. A continuación se muestra un ejemplo. Es probable que su ajax.php modificado no haga que se cargue.

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

Finalmente: sobre lo que te quejas, usar la localización para obtener la URL de Ajax es algo bueno. ¿Por qué? Debido a que sus archivos JS no son conscientes de ninguna de las cosas del lado del servidor. ¿Va a utilizar una URL que se romperá si / cuando el sitio se mueva? Parece una mala elección.

Si realmente no desea localizar todos los scripts que usan Ajax, simplemente enganche en wp_head muy pronto y escupa la URL de administrador ajax. Problema resuelto (así es como lo hace el área de administración, por cierto).

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

Al igual que con muchas cosas en WordPress, hay un número casi infinito de formas de despellejar al gato. Si bien todos los métodos aceptados funcionan, he descubierto que son menos "neat" que el uso de wp_localize_script para incluir la capacidad de ajax en la parte delantera.

Mira esto:

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

Y luego, en el archivo se83650.js , harías referencia a tu variable con se83650Ajax.ajaxurl .

El beneficio de esta técnica es que si terminas con muchos complementos que intentan duplicar esta funcionalidad, no incluyen ni sobrescriben la misma variable. ajaxurl es bastante genérico de incluir, esto te hace más contenido y funciona mejor con otros desarrolladores.