Adicionando admin-ajax.php ao frontend. Boa ou má ideia?

Você poderia simplesmente usar um RewriteRule no seu .htaccess acima das regras normais de regravação de permalink:

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

Agora, envie suas solicitações AJAX para example.com/ajax e nunca perca as alterações principais no arquivo após as atualizações.

Primeiro: padronização. Se você planeja usar plug-ins da comunidade, é provável que eles não se importem com o arquivo /ajax.php na raiz do documento. Então eles não vão usá-lo.

Se você for rolar tudo sozinho, isso não é um problema.

Segundo: e se o núcleo for atualizado? Você irá monitorar e alterar seu arquivo ajax?

Terceiro : apesar de admin-ajax.php residir em wp-admin , ele não carrega nenhum material da área administrativa (por exemplo, tabelas de listas, etc). Nem verifica a autenticação ou exponha qualquer coisa sensível a usuários não logados. É como um arquivo front-end, em outras palavras. Nada para se preocupar.

Quarto: Relacionado ao primeiro problema, alguns plugins serão verificados antes de carregar cegamente a funcionalidade relacionada ao ajax. Um exemplo está abaixo. Seu ajax.php modificado provavelmente não causará o carregamento.

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

Finalmente: O que você reclama, usando a localização para obter o Ajax URL é uma boa coisa a fazer. Por quê? Porque seus arquivos JS não estão cientes de nenhuma das coisas do lado do servidor. Você está indo duro uma URL em que vai quebrar se / quando o site se move? Parece uma má escolha.

Se você realmente não quiser localizar todos os scripts que usam o Ajax, conecte-se com wp_head no início e cuspa a URL do administrador ajax. Problema resolvido (isto é exatamente como a área de administração faz, a propósito).

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

Como acontece com muitas coisas no WordPress, há um número quase infinito de maneiras de esfolar o gato. Embora todos os métodos aceitos funcionem, descobri que eles são menos "legais" do que usar wp_localize_script para incluir o recurso ajax em o front end.

Verifique isso:

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, em seguida, no arquivo se83650.js , você faria referência à sua variável com se83650Ajax.ajaxurl .

O benefício desta técnica é que, se você acabar com muitos plugins que tentam duplicar essa funcionalidade, eles não estão incluindo ou sobrescrevendo a mesma variável. ajaxurl é bastante genérico para incluir, isso deixa você mais contido e funciona melhor com outros desenvolvedores.