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

Me encanta admin-ajax.php. Pero odio tener que localizar para apuntar guiones frontend a él, y desearía que hubiera un archivo equivalente y fácil de encontrar para los temas. (También me molesta ver que las solicitudes frontend pasan por "/ wp-admin /". No hay razón práctica, solo se ve feo en mi opinión).

Así que simplemente copié admin-ajax.php en el directorio raíz en "/ajax.php", ajusté las rutas de inclusión y eliminé la definición constante WP_ADMIN. Parece funcionar como gangbusters (¡ahora puedo dirigir todas mis solicitudes de AJAX frontend a /ajax.php! ¡Y aún puedo usar los ganchos wp_ajax normales en mis complementos!).

¿Pero es esto seguro? ¿Qué podría salir mal? Como esto no está integrado en el núcleo, supongo que hay una buena razón para no hacerlo. Pero mirando a través del código, no puedo ver ningún problema inmediato.

Eres inteligente, dime si este enfoque es una locura. O si hay un método más simple que estoy pasando por alto.

Podrías usar una RewriteRule en tu .htaccess por encima de las reglas normales de reescritura de enlaces permanentes:

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

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

Primero: estandarización. Si planea usar complementos de la comunidad, es probable que no les importe su /ajax.phparchivo en la raíz del documento. Para que no lo usen.

Si va a rodar todo usted mismo, esto no es un problema.

Segundo: ¿qué pasa si el núcleo se actualiza? ¿Monitorearás y cambiarás tu archivo ajax?

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

Cuarto: relacionado con el primer problema, algunos complementos se comprobarán antes de cargar a ciegas la funcionalidad relacionada con ajax. Un ejemplo está abajo. Es probable que tu ajax.php modificado no haga que se cargue.

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

Finalmente: de qué te quejas, es bueno usar la localización para obtener la URL de Ajax. ¿Por qué? Porque sus archivos JS no conocen ninguna de las cosas del lado del servidor. ¿Vas a crear una URL que se romperá si / cuando el sitio se mueve? Parece una mala elección.

Si realmente no desea localizar todas las secuencias de comandos que utilizan Ajax, simplemente enganche wp_headmuy pronto y escupe la URL de administrador ajax. Problema resuelto (por cierto, así es exactamente como lo hace el área de administración).

<?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 desollar al gato. Si bien todos los métodos aceptados funcionan, he descubierto que son menos "ordenados" que usar wp_localize_script para incluir la capacidad ajax en el front-end.

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 se83650.jsarchivo, haría referencia a su 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. ajaxurles bastante genérico para incluir, esto te hace más contenido y juega mejor con otros desarrolladores.