Admin ajax php грузит сервер что делать. Как ускорить WordPress — избавляемся от admin-ajax

Распространенный сценарий при работе с WordPress – диагностика повышенного использования admin-ajax.php. Если вы некоторое время работаете с WordPress, вы, скорее всего, сталкивались с этой проблемой при запуске сторонних тестов скорости или проверке серверных логов доступа. Обычно повышенное использование admin-ajax.php связано с применением сторонних плагинов либо частыми некэшируемыми запросами из панели администратора, основанными на Heartbeat API (к примеру, автосохранение черновиков). Очень важно сразу же выявлять такие высокие всплески обращений к admin-ajax.php, поскольку они могут вести к тому, что сайт будет недоступен. Ознакомьтесь с приведенными ниже рекомендациями по устранению проблем с admin-ajax.php в WordPress.

Сам по себе файл admin-ajax.php не является плохим при грамотном его использовании. Он выступает частью ядра. Файл был добавлен командой разработчиков WordPress в релизе 3.6. Цель admin-ajax.php – создать соединение между браузером и сервером с помощью AJAX. Это позволяет использовать расширенные функции, среди которых улучшенное автосохранение, отслеживание версий, таймауты логина, управление сеансом, а также уведомления о блокировке записи при редактировании ее несколькими авторами. Все эти возможности великолепны, особенно для тех пользователей, которые поддерживают сайты с несколькими авторами и администраторами.

«Идея состоит в том, чтобы реализовать относительно простой API, который будет отправлять XHR запросы на сервер каждые 15 секунд и запускать события (или callback) при получении данных. Другие компоненты тоже смогут «подцепляться» или получать уведомления об активности других пользователей. Это можно применять для блокировки одновременного редактирования виджетов или меню, либо выполнения других задач, требующих регулярных обновлений с сервера»

Если вы не являетесь технически подкованным пользователем, то в таком случае единственная ситуация, которая будет вам важна в контексте admin-ajax.php – это попытка понять, почему этот файл замедляет скорость в тестах (к примеру, в Pingdom). Либо вы можете увидеть кучу запросов к этому файлу в логах доступа хостинга.

Появление admin-ajax.php в тестах скорости и логах доступа обычно является результатом двух различных сценариев: одного во фронтэнде и второго в бэкэнде. Об этом мы поговорим далее.

Самая популярная проблема, с которой сталкиваются пользователи в контексте admin-ajax.php, вызвана сторонними плагинами. Обычно это видно во фронтэнде и отображается в тестах скорости. Разработчики используют этот файл или AJAX для добавления функционала к своим плагинам. Если вы видите запрос к admin-ajax.php, это еще не означает, что он обязательно будет замедлять сайт. AJAX загружается после представления страницы, и некоторые запросы могут загружаться асинхронно. Но это не всегда означает и то, что разработчик выполнил загрузку грамотно и написал эффективный код в плане производительности.

Ниже представлены примеры того, как мы быстро диагностировали замедление работы admin-ajax.php. Мы использовали GTmetrix, поскольку он позволяет нам изучать данные отдельных записей и ответов. Pingdom, к сожалению, не позволяет нам видеть запросы данных в формах. Вы также можете использовать Google Chrome Devtools или WebPageTest.

Ниже приведен наш WordPress сайт, на котором мы столкнулись с очень высокими задержками при использовании admin-ajax.php. Как вы можете видеть по GTmetrix, задержка запросов к admin-ajax.php составляет более 8 секунд. Остальная часть «водопада» выглядит нормально, но такую задержку нужно обязательно решать владельцам сайтов.

Если вы щелкнете по запросу POST admin-ajax.php, вы увидите следующие три вкладки: Headers, Post и Response. При диагностике рассматриваемых нами проблем нас будут интересовать только вкладки Post и Response. Подсказки можно видеть во вкладке Response. Мы видим, что часть запроса связана со скриптом vc_shortcodes-custom-css.

Быстрое копирование и вставка в Google помогают понять, что проблема вызвана плагином Visual Composer.

Следующий шаг для пользователя – убедиться в том, что плагин Visual Composer полностью обновлен. Если да, то в таком случае необходимо обратиться к разработчикам плагина и рассказать им о проблеме с admin-ajax.php. На самом деле это достаточно распространенная проблема, если судить по постам на Stack Overflow. Если разработчик не способен решить ее в своем плагине, всегда найдется несколько альтернативных плагинов, которые делают примерно то же самое – в этом и состоит мощь WP. К примеру, если вам нужны билдеры страниц, то вы можете попробовать Beaver Builder или Elementor.

Второй пример, с которым столкнулись мы сами, произошел после установки стороннего плагина. Мы заметили резкий подъем обращений к admin-ajax.php.

Опять же, если вы нажмете на запрос POST admin-ajax.php, то вы сможете исследовать все в деталях. Мы видим, что в данных присутствует строка «action=mtsnb_add_impression&bar_id=88&ab_variation=none».

Как правильно, первая часть действия post обычно относится к CSS классу плагина. Мы делаем быстрый поиск в Google по «mtsnb» и обнаруживаем, что этот класс используется в плагине Notification Bar, который запущен у нас на сайте.

Если вы разработчик, то есть и другие способы отследить, какой плагин может генерировать ответ POST, однако мы считаем, что и описанные в статье методы являются очень эффективными.

Выше мы привели несколько простых способов поиска плагина на WordPress сайте, который может приводить к данной проблеме с admin-ajax.php. По нашему опыту, эти способы работают в 99% случаев. Однако бывает и так, что данные POST или действия могут быть не такими понятными, а потому вам придется двигаться старым проверенным путем. Просто отключите все плагины на своем WordPress сайте. Запустите тест скорости. Если admin-ajax.php нигде не обнаружится, то включайте по очереди каждый плагин и проводите тест скорости. Таким образом вы быстро выявите проблемный плагин.

Вторая серьезная проблема заключается в том, что WordPress Heartbeat API использует admin-ajax.php для запуска вызовов AJAX от веб-браузера, что может вести к высокой нагрузке на CPU. Каждый AJAX запрос также загружает полный WordPress бэкэнд в обход всех форм кэширования. Как правило, вы не увидите этого в тестах скорости. Это особенно важно знать тем, кто использует дешевые виртуальные хостинги, поскольку у них нет большого пространства для маневров, когда дело касается CPU. Такая проблема всплывала с хостингом HostGator ранее.

Один из сценариев, с которым вы должны быть очень осторожны – автоматическое сохранение в WordPress и наличие открытых вкладок. К примеру, мы запустили новый проект на нашем сайте и оставили вкладку открытой. Heartbeat API по умолчанию опрашивает файл admin-ajax.php каждые 15 секунд, чтобы сделать автоматическое сохранение. Это видно по журналам доступа. Если бы мы оставили вкладку открытой на день, то один пост мог сгенерировать 5760 запросов за сутки.

Это слишком много запросов в бэкэнде для одного человека. Представьте, что будет, если у вас на сайте есть несколько редакторов. Эти запросы увеличатся в геометрической прогрессии. Мы сталкивались с таким во время нашего исследования DARTDrones, в котором мы помогали расширить их WooCommerce сайт для Shark Tank. У них было свыше 4100 вызовов admin-ajax.php за сутки, при этом посетителей было только 2000. Это не самое лучшее соотношение запросов к визитам. Наше исследование показало, что большинство запросов шло из консоли – они генерировались из-за того, что администраторы обновляли сайт, готовя его к показу.

Есть способ обнаружения некоторых проблем с обращениями к admin-ajax.php в бэкэнде, когда дело касается автосохранений, ревизий, блокировки записей и т.д. Для этого необходимо установить плагин Heartbeat Control .

Плагин Heartbeat Control в данный момент установлен на более 50 000 сайтов и имеет рейтинг 5 из 5. Прошло уже 2 года с момента его обновления, но он работает все так же, поскольку Heartbeat API тоже не обновлялся.

Плагин позволяет вам управлять частотой обращений к WordPress Heartbeat API с помощью пары щелчков мыши. Первая опция дает возможность управлять расположением heartbeat – к примеру, отключать его везде или разрешать только на страницах редактирования записей. Мы рекомендуем использовать последний вариант, поскольку полное отключение плагина может вести к тому, что некоторые плагины, зависящие от Heartbeat API, могут перестать работать.

Вторая опция позволяет вам задавать частоту опроса. Изменение с 15 сек до 60 сек позволит вам значительно сэкономить количество запросов и сохранить серверные ресурсы (снизив нагрузку на ЦП).

Вы можете также использовать премиум-плагин, такой как perfmatters , чтобы отключать heartbeat, менять частоту опросов, а также модифицировать интервал автосохранения.

Как вы можете видеть, есть несколько быстрых и простых опций для диагностирования и устранения проблем с admin-ajax.php. Как правило, они появляются из-за сторонних плагинов, которые могут конфликтовать друг с другом или иметь плохую кодовую базу.

Сталкивались ли вы с такой проблемой на своем сайте? Если да, то поделитесь своими историями.

Создать данный пост меня заставила проблема, которая все настойчивее стала стучаться на мой сайт. Проблема — открытие страниц сайта и работа в админпанели. Они стали настолько сильны и часты, что стало затруднительным составить даже небобольшое сообщение. Соединение с сервером постоянно пропадало. Высокая нагрузка на CPU, а значит превышение так называемого мягкого лимита происходила постоянно; на почту очень часто стали проиходить сообщения от Метрики и плагина Jetpack, о том что сайт часто бывает недоступен, даже в тот момент, когда я в нем не работал. Короче — ужас ужасный снова настиг меня на проблеме скорости работы сайта. И я снова обратился в службу подержки на своем хостинге «Джино»

Ответ пришел незамедлительно, а при дальнейшем диалоге с небольшими пояснениями, я понял суть проблем и смог их исправить.

Поддержка хостинга прежде всего обратила мое внимание на большое количество обращений к /wp-admin/admin-ajax.php. «Обращения создают действия в административной панели сайта. Такое поведение в ней характерно, если какой-то из плагинов работает не корректно. Отключайте плагины сайта по очереди и следите за его работой. Обнаружив проблемный плагин, попробуйте его обновить или установить стабильную версию, или замените аналогом, с которым не возникает проблем».

Плагинов на моем сайте установленно довольно много и проверять каждый в отдельности очень проблематично. Поэтому я обратил внимание на ссылку, которую мне оставили из техподдержки на плагин Heartbeat Control . Его установка и некоторые другие настройки решили мою проблему!

Служба техподдержки так же обратила на еще одну проблему и предложила провести некоторые действия в коррекции кода в файле wp-cron.php. Но об этой проблеме в конце сообшения.

Ну а теперь давайте перейдем к сути вышесказанного.

Слово «Heartbeat» переводится как «Сердцебиение» и назван он так для API не зря. Она обеспечивает определенную частоту запросов к серверу. По умолчанию и в зависимости от страницы админпанели, это происходит с разными интервалами: при редактировании записей — каждые 15 сек, при работе в Консоли — одну минуту. WordPress Heartbeat API — это функция, которая обеспечивает:

• Автосохранение при создании сообщений;
• Блокировки записей или страниц для других редакторов сайта, пока запись или страницу редактирует один человек;
• Обновление информации о том, что пользователь всё ещё находится в административной части (консоли или на странице редакции записей).

Данная функция, прописанная в движке WordPres очень важна, особенно тогда, когда на сайте могут работать несколько авторов и администрирование бывает коллективным. Однако она же может стать причиной «торможения» сайта и значительного увеличения нагрузки на сервер.

Если вы являетесь единственным автром сайта, то функцию Heartbeat API можно либо полностью отключить, либо настроить на удобный вам режим, позволяющий регулировать нагрузку на сервер.

Этот жесткий сценарий, который я не пожелал сделать, заключается в том, что нужно проделать некоторую операцию в файле functions.php вашей темы, установленной в данный момент на сайте.

Add_action("init", "stop_heartbeat", 1); function stop_heartbeat() { wp_deregister_script("heartbeat"); }

Разумеется, при обновлении этой темы или ее замены на другую, придется эту операцию делать заново.

Настроек всего и две и, несмотря на то, что плагин на английском, для незнающих этот язык, не трудно будет в них разобраться. Напомню, что настройка плагина по умолчанию (use default) означает, что Heartbeat API не отключен ни на одной из страниц, а интервал запросов к серверу — 15 сек. То есть все выглядет так, словно этого плагина на вашем сайте нет.

Для ясности делаю пояснения:

1. use default — использовать Heartbeat API по умолчанию;
2. disable everywhere — отключить Heartbeat API везде;
3. disable on dashboard page — отключить Heartbeat API на приборной страницe (консоль);
4. allow onli от post edit pages — использовать Heartbeat API только при редактировании страниц.

Тут все очень просто. Нужно лишь выбрать подходящий интервал запросов к северу. Чем реже «пульс» — тем реже запросы — тем меньше нагрузка на сервер.

После совершения настроек сохраняем измения.

Поскольку автоматическое сохрание сохрание записей во время их редактирования остается желанной функцией (удалить лишние редакции можно потом чисткой специальными плагинами), а потерять почти завершенную запись по каким-либо техническим причинам неприятно (пропал интернет или связь с сервером и т. п.) очень нежелательно. Поэтому настройку для перврого блока вполе можно установить в режим «use default» но вполне достаточно будет сделать настройки во втором блоке, так как установка таймера частоты запросов к файлу admin-ajax.php. в 60 сек. сократит расход ресурсов на данные запросы на целых 75% !

Разумеется, существует много причин замедления работы сайтов. Не имея должных знаний и работая с ними мы просто не знаем, что является причинами таких весьма нежелательных процессов. Наверное нам нужно чаще обращаться к специалистам, в том числе и в техподдержку хостинга.

В начале статьи я упомянул о том, что работники поддержки обратили мое внимание еще на одну причину сложности в работе моих сайтов. Причина —

Техподдержка в результате исследований работы моих сайтов, обратила внимание, что на них «наблюдаются процессы wp-cron.php». Они рекомендовали: «Если выполнение этого файла вызывает нездоровую нагрузку на сервер - можно отключить эти задачи».

Это все, друзья.

(Visited 304 times, 1 visits today)

Нам в редакцию часто пишут с просьбой разобраться с нагрузкой на сайт WordPress, и во многих случаях это связано с файлом admin-ajax.php. В этой статье мы расскажем за что отвечает данный файл и как бороться с его нагрузкой на сервер.

AJAX — это асинхронные HTTP запросы выполняемые на странице с помощью языка JavaScript, позволяющие общаться с веб-сервером без полной перезагрузки страницы. Это позволяет делать интерфейсы более быстрыми, отзывчивыми и динамичными.

В WordPress такой подход используется во многих местах: работа с медиафайлами, автоматическое сохранение записей, управление ревизиями, работа с произвольными полями, работа с виджетами и многое другое. И чтобы каждый раз не изобретать велосипед, файл admin-ajax.php в WordPress предоставляет удобный API для работы с AJAX запросами.

В данной статье мы не будем рассматривать сам API, но стоит отметить, что несмотря на присутствие слова «admin» в названии файла, через него могут проходить запросы и с лицевой части сайта, включая анонимные запросы из тем и плагинов WordPress. К сожалению многие источники ошибочно советуют отключить этот файл, или заблокировать его паролем — этого делать не стоит .

Как мы уже упомянули, файл admin-ajax.php вызывается при автоматическом сохранении записей, а также для обновления блокировок, чтобы два пользователя не могли редактировать одну и ту же запись одновременно. Это реализует API в WordPress под названием Heartbeat (сердцебиение), который построен на базе admin-ajax.php.

При редактировании записи Heartbeat отправляет запрос на admin-ajax.php каждые 15 секунд (или каждые 60 секунд, в случае если вкладка в браузере не является активной). Поэтому если вы видите в логах вашего веб-сервера большое количество запросов на admin-ajax.php стоит их проанализировать.

• С каких IP адресов приходят эти запросы
• С какой периодичностью они приходят
• Сколько времени в среднем занимает один такой запрос
• Каково содержание запроса

Итак, если эти запросы приходят с вашего IP адреса, или с IP адресов редакторов на вашем сайте, если их периодичность около 15-60 секунд, если каждый такой запрос занимает не более 0.5 сек, и содержание запросов не содержит ничего необычного, то все в порядке — файл admin-ajax.php не является источником нагрузки на ваш сервер, независимо от «большого» количества запросов. А если ваш уверяет вас в обратном, то советуем задуматься о его компетентности и о возможном переезде.

Рассмотрим несколько вариантов, когда admin-ajax.php действительно становится источником высокой нагрузки на ваш сервер, и как бороться с этой нагрузкой.

В среднем запросы на admin-ajax.php могут занимать около 300 мс. Если же на вашем сайте данные запросы выполняются более чем за одну секунду, то необходимо разобраться. Используйте средства , чтобы понять чем именно занят процесс все это время. Наверняка вы найдете медленную функцию в вашей теме или плагине, которая не имеет никакого отношения к AJAX запросам.

Если же вы не владеете средствами профилирования, или у вас нет времени разбираться в чужом коде, то попробуйте отключить все плагины и активировать стандартную тему WordPress. Затем активируйте плагины по порядку, чтобы понять какой из них является причиной медленных запросов на admin-ajax.php.

Бывает и такое, что запросы на admin-ajax.php становятся медленными не из-за конкретных плагинов или тем, а из-за неоптимальной конфигурации сервера MySQL. Такое бывает достаточно редко, и в этом случае следует заняться оптимизацией сервера базы данных.

Файл admin-ajax.php (и admin-post.php) часто выбирается злоумышленниками для того, чтобы использовать известную уязвимость в каком-нибудь плагине. В качестве примера можно привести с популярным плагином FancyBox, где именно admin-ajax.php (или admin-post.php) послужил точкой входа.

Эти файлы выбираются не спроста, ведь каждый из них исполняет admin_init даже для анонимных HTTP запросов. Многие разработчики плагинов и тем, ошибочно считают, что раз выполняется событие admin_init , значит пользователь выполнил вход и имеет права администратора. Это не так. Повторяем — событие admin_init выполняется даже для анонимных HTTP запросов.

Итак, в случае с уязвимостью плагина FancyBox for WordPress, вот примерно то, как выглядит «подозрительное содержание запроса»:

46.4.76.174 – – "POST /wp-admin/admin-ajax.php?page=fancybox-for-wordpress HTTP/1.1" 403 4207 INPUTBODY:action=update&mfbfw%5Bext...

Если вы обнаружили подобный запрос, необходимо понять на какой конкретно плагин или тему он нацелен, что именно он пытается сделать, удалось ли ему это. В подобных случаях мы рекомендуем обратиться к экспертам по безопасности WordPress.

Этот пункт тесно связан с предыдущим. Если вы увидели запросы на admin-ajax.php с неузнаваемых IP адресов, то необходимо проанализировать эти запросы, и понять чего именно пытается сделать злоумышленник. IP адреса можно заблокировать, например по шаблону с помощью .

Как мы уже упомянули, на активной вкладке при редактировании записи, WordPress выполняет AJAX запрос каждые 15 секунд, т.е. для достижения 1 запроса в секунду на сервере, вам необходимо 15 редакторов с открытой вкладкой. Если вы являетесь единственным редакторов на вашем сайте, а запросов на admin-ajax.php с вашего IP адреса более 1 в секунду (мы встречали и 20/с), то стоит с этим разобраться.

Самой частой причиной подобного поведения является тема или плагин, поэтому следует их деактивировать и включать по порядку, чтобы найти источник. Здесь стоит также упомянуть плагин Heartbeat Control , который позволяет изменять стандартную конфигурацию Heartbeat в WordPress, но учтите, что отключив Heartbeat вы скорее временно скрываете проблему, а не устраняете ее.

В этой статье мы рассмотрели несколько причин, по которым может возникать высокая нагрузка на хостинг-площадку через файл admin-ajax.php, но не исключено, что могут быть и другие.

В случае с любой «лишней» нагрузкой на сервер, рекомендуем всегда проверять факты, средства профилирования — ваши лучшие друзья. Результаты порой бывают удивительными, когда например некоторые из очень популярных плагинов для WordPress оказываются самыми медленными.

Как загружать любые файлы, например, картинки на сервер с помощью AJAX и jQuery? Делается это довольно просто! И ниже мы все обстоятельно разберем.

В те «древние» времена, когда еще не было jQuery, а может он был, но браузеры были не так наворочены, загрузка файла на сайт с помощью AJAX была делом муторным: через всякие костыли вроде iframe. Я те время не застал, да и кому это теперь интересно. А интересно теперь другое - что сохранение файлов на сайт делается очень просто. Даже не обладающий опытом и пониманием, того как работает AJAX, вебмастер, сможет быстро разобраться что-куда. А эта статья ему в помощь. Если подкрепить эти возможности функциями WordPress , то безопасная обработка и загрузка файлов на сервер становится совсем плевым и даже интересным делом (пример с WordPress смотрите в конце статьи).

Однако, как бы все просто не было, нужно заметить, что минимальный опыт работы с файлами и базовые знания в Javascript, jQuery и PHP все же необходимы! Минимум, нужно представлять как загружаются файлы на сервер, как в общих чертах работает AJAX и хоть немного надо уметь читать и понимать код.

Описанный ниже метод довольно стабилен, и по сути опирается на Javascript объект new FormData() , базовая поддержка которого есть во всех браузерах.

Для более понятного восприятия материала, он разделен на шаги. На этом все, полетели...

Начинается все с наличия на сайте input поля типа file . Нет необходимости, чтобы это поле было частью формы (тега ).

Таким образом, у нас есть HTML код с file полем и кнопкой «Загрузить файлы».

Загрузить файлы

Первым шагом, нужно получить данные загружаемых файлов.

При клике на file-поле, появляется окно выбора файлов, после выбора, данные о них сохраняются в input поле, а нам нужно их от туда «забрать». Для этого повесим на событие change JS функцию, которая будет сохранять имеющиеся данные file-поля в JS переменную files:

Var files; // переменная. будет содержать данные файлов // заполняем переменную данными, при изменении значения поля file $("input").on("change", function(){ files = this.files; });

Данные файлов у нас есть, теперь их нужно отправить через AJAX. Вешаем это событие на клик по кнопке «Загрузить файлы».

В момент клика создаем новый объект new formData() и добавляем в него данные из переменной files . С помощью formData() мы добьемся того, что отправляемые данные будут выглядеть, как если бы мы просто сабмитили форму в браузере.

Чтобы такой запрос состоялся, в jQuery нужно указать дополнительные AJAX параметры, поэтому привычная функция $.post() не подходит и мы используем более гибкий аналог: $.ajax() .

Два важных дополнительных параметра нужно установить в false:

ProcessData Отключает обработку передаваемых данных. По умолчанию, например, для GET запросов jQuery собирает данные в строку запроса и добавляет эту строку в конец URL. Для POST данных делает другие преобразования. Нам любые изменения исходных данных будут мешать, поэтому отключаем эту опцию... contentType Отключает установку заголовка типа запроса. Дефолтная установка jQuery равна "application/x-www-form-urlencoded . Такой заголовок не предусматривает отправку файлов. Если установить этот параметр в "multipart/form-data" , PHP все равно не сможет распознать передаваемые данные и выведет предупреждение «Missing boundary in multipart/form-data»... В общем, проще всего отключить эту опция, тогда все работает! // обработка и отправка AJAX запроса при клике на кнопку upload_files $(".upload_files").on("click", function(event){ event.stopPropagation(); // остановка всех текущих JS событий event.preventDefault(); // остановка дефолтного события для текущего элемента - клик для тега // ничего не делаем если files пустой if(typeof files == "undefined") return; // создадим объект данных формы var data = new FormData(); // заполняем объект данных файлами в подходящем для отправки формате $.each(files, function(key, value){ data.append(key, value); }); // добавим переменную для идентификации запроса data.append("my_file_upload", 1); // AJAX запрос $.ajax({ url: "./submit.php", type: "POST", // важно! data: data, cache: false, dataType: "json", // отключаем обработку передаваемых данных, пусть передаются как есть processData: false, // отключаем установку заголовка типа запроса. Так jQuery скажет серверу что это строковой запрос contentType: false, // функция успешного ответа сервера success: function(respond, status, jqXHR){ // ОК - файлы загружены if(typeof respond.error === "undefined"){ // выведем пути загруженных файлов в блок ".ajax-reply" var files_path = respond.files; var html = ""; $.each(files_path, function(key, val){ html += val +"
"; }) $(".ajax-reply").html(html); } // ошибка else { console.log("ОШИБКА: " + respond.error); } }, // функция ошибки ответа сервера error: function(jqXHR, status, errorThrown){ console.log("ОШИБКА AJAX запроса: " + status, jqXHR); } }); });

jQuery(document).ready(function($){ // ссылка на файл AJAX обработчик var ajaxurl = ""; var nonce = ""; var files; // переменная. будет содержать данные файлов // заполняем переменную данными, при изменении значения поля file $("input").on("change", function(){ files = this.files; }); // обработка и отправка AJAX запроса при клике на кнопку upload_files $(".upload_files").on("click", function(event){ event.stopPropagation(); // остановка всех текущих JS событий event.preventDefault(); // остановка дефолтного события для текущего элемента - клик для тега // ничего не делаем если files пустой if(typeof files == "undefined") return; // создадим данные файлов в подходящем для отправки формате var data = new FormData(); $.each(files, function(key, value){ data.append(key, value); }); // добавим переменную идентификатор запроса data.append("action", "ajax_fileload"); data.append("nonce", nonce); data.append("post_id", $("body").attr("class").match(/postid-(+)/)); var $reply = $(".ajax-reply"); // AJAX запрос $reply.text("Загружаю..."); $.ajax({ url: ajaxurl, type: "POST", data: data, cache: false, dataType: "json", // отключаем обработку передаваемых данных, пусть передаются как есть processData: false, // отключаем установку заголовка типа запроса. Так jQuery скажет серверу что это строковой запрос contentType: false, // функция успешного ответа сервера success: function(respond, status, jqXHR){ // ОК if(respond.success){ $.each(respond.data, function(key, val){ $reply.append(""); }); } // error else { $reply.text("ОШИБКА: " + respond.error); } }, // функция ошибки ответа сервера error: function(jqXHR, status, errorThrown){ $reply.text("ОШИБКА AJAX запроса: " + status); } }); }); })