Aggiunta di admin-ajax.php al frontend. Buona o cattiva idea?

Adoro admin-ajax.php. Ma odio dover localizzare al fine di indirizzare gli script frontend e desidero che ci sia un file equivalente e facile da trovare per i temi. (Mi disturba anche vedere le richieste di frontend passare attraverso "/ wp-admin /". Nessun motivo pratico, sembra solo brutto IMO.)

Quindi ho semplicemente copiato admin-ajax.php nella directory principale in "/ajax.php", modificato i percorsi di inclusione e rimosso la definizione costante WP_ADMIN. Sembra funzionare come un gangbuster (ora posso solo indirizzare tutte le mie richieste AJAX frontend a /ajax.php! E posso ancora usare i normali hook wp_ajax nei miei plugin!).

Ma è sicuro? Cosa potrebbe andare storto? Dal momento che questo non è integrato nel core, presumo che ci sia una buona ragione per non farlo. Ma guardando attraverso il codice, non riesco a vedere alcun problema immediato.

Sei intelligente - dimmi se questo approccio è pazzo. O se c'è un metodo più semplice che sto trascurando.

Puoi semplicemente usare RewriteRule per il tuo .htaccess sopra le normali regole di riscrittura del permalink:

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

Ora invia le tue richieste AJAX a example.com/ajax, e non perdere mai le modifiche principali a quel file dopo gli aggiornamenti.

Primo: standardizzazione. Se prevedi di utilizzare i plug-in della community, è probabile che non si occuperanno del tuo /ajax.phpfile nella radice del documento. Quindi non lo useranno.

Se lancerai tutto da solo, questo non è un problema.

Secondo: cosa succede se il core si aggiorna? Monitorerai e modificherai il tuo file Ajax?

Terzo : nonostante admin-ajax.phprisieda in wp-admin, non carica alcun elemento dell'area di amministrazione (ad es. Tabelle di elenchi, ecc.). Né verifica l'autenticazione o espone nulla di sensibile agli utenti non registrati. È proprio come un file front-end, in altre parole. Nulla di cui preoccuparsi.

Quarto: in relazione al primo problema, alcuni plugin controlleranno prima di caricare ciecamente la funzionalità relativa a Ajax. Un esempio è sotto. Probabilmente il tuo ajax.php modificato non lo farà caricare.

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

Infine: di cosa ti lamenti, utilizzare la localizzazione per ottenere l'URL Ajax è una buona cosa da fare. Perché? Perché i tuoi file JS non sono a conoscenza di nessuna delle cose sul lato server. Hai intenzione di inserire un URL che si interromperà se / quando il sito si sposta? Sembra una cattiva scelta.

Se davvero non vuoi localizzare tutti gli script che usano Ajax, aggancia wp_headmolto presto e sputa l'URL ajax dell'amministratore. Problema risolto (questo è esattamente come fa l'area di amministrazione, a proposito).

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

Come per molte cose in WordPress, ci sono un numero quasi infinito di modi per scuoiare il gatto. Mentre tutti i metodi accettati funzionano, ho scoperto che sono meno "puliti" rispetto all'uso di wp_localize_script per includere la funzionalità ajax sul front-end.

Controllalo:

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

E poi nel se83650.jsfile, faresti riferimento alla tua variabile se83650Ajax.ajaxurl.

Il vantaggio di questa tecnica è che se finisci con molti plugin che provano a duplicare questa funzionalità, non stanno includendo o sovrascrivendo la stessa variabile. ajaxurlè piuttosto generico da includere, questo ti rende più contenuto e gioca meglio con altri sviluppatori.