Додавання admin-ajax.php до фронтену. Гарна чи погана ідея?

Я люблю admin-ajax.php. Але я ненавиджу локалізувати, щоб вказати на нього сценарії фронтену, і я хотів би, щоб за темами був рівноцінний, простий у пошуку файл. (Це також просто заважає мені бачити, що запити на передній план проходять через "/ wp-admin /". Без практичних причин, просто виглядає негарно IMO.)

Тому я просто скопіював admin-ajax.php в кореневий каталог на "/ajax.php", відкоригував шляхи включення та видалив постійне визначення WP_ADMIN. Здається, це працює як гангстери (зараз я можу просто направляти всі свої запити AJXFrontend на /ajax.php! І я все ще можу використовувати звичайні гачки wp_ajax у своїх плагінах!).

Але це безпечно? Що може піти не так? Оскільки це не вбудовано в ядро, я припускаю, що є вагомі причини, чому ні. Але переглядаючи код, я не бачу негайних проблем.

Ви розумні - скажіть, чи такий підхід божевільний. Або якщо є більш простий метод, який я не помічаю.

Ви можете просто використовувати RewriteRule до свого .htaccess над звичайними правилами перезапису постійної посилання:

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

Тепер надсилайте ваші запити AJAX example.com/ajaxта не пропускайте основні зміни цього файлу після оновлення.

Перший: стандартизація. Якщо ви плануєте використовувати плагіни спільноти, швидше за все, вони не піклуються про ваш /ajax.phpфайл у корені документа. Тому вони не будуть використовувати його.

Якщо ви все збираєтеся згортати, це не проблема.

Друге: що робити, якщо ядро ​​оновлюється? Чи будете ви відстежувати та змінювати файл ajax?

Третє : незважаючи на admin-ajax.phpпроживання в сwp-admin ньому, він не завантажує жодного з елементів адміністративної області (наприклад, таблиці списків тощо). Він також не перевіряє аутентифікацію та не піддає щось чутливе до користувачів, які не ввійшли в систему. Іншими словами, це просто як передовий файл. Не про що хвилюватися.

Четверте: пов'язані з першим випуском, деякі додатки перевірять перед тим, як сліпо завантажувати функціонал, пов'язаний з ajax. Приклад наведено нижче. Ваш змінений ajax.php, ймовірно, не призведе до завантаження.

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

Нарешті: те, на що ви скаржитеся, використовуючи локалізацію для отримання URL-адреси Ajax - це добре зробити. Чому? Тому що ваші файли JS не знають жодного з елементів сервера. Ви будете вводити важку URL-адресу, яка зламається, якщо / коли сайт рухатиметься? Здається, поганий вибір.

Якщо ви дійсно не хочете локалізувати кожен сценарій, що використовує Ajax, просто зачепіть його wp_headдуже рано і виплюньте URL-адресу адміністратора ajax. Проблема вирішена (до речі, саме це робить область адміністратора).

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

Як і у багатьох речах у WordPress, існує майже нескінченна кількість способів зняти шкіру з кішкою. Хоча всі прийняті методи працюють, я виявив, що вони менш "акуратні", ніж використання wp_localize_script для включення можливості ajax на передньому кінці.

Заціни:

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

А потім у se83650.jsфайлі ви б посилалися на свою змінну se83650Ajax.ajaxurl.

Перевага цієї методики полягає в тому, що якщо у вас є багато плагінів, які намагаються скопіювати цю функціональність, вони не включають та не перезаписують одну і ту ж змінну. ajaxurlдосить загальне для включення, це дає вам більше вмісту, і це чудово грає з іншими розробниками.