admin ajax php что это
Правильный robots.txt для Вордпресс
Наверное, только ленивый не писал про то, как должен выглядеть правильный Robots.txt для Вордпресс. Я попробую объяснить, почему многие старые способы больше не работают.
Прежде напомню, на дворе 2017-й год — прогресс не стоит на месте, технологии развиваются. Кто давно в теме — знают, что поисковые системы за последнее десятилетие сильно эволюционировали. Поисковые алгоритмы стали более сложными. Сложными стали и факторы ранжирования, их количество существенно увеличилось. Естественно, всё это не могло не отразиться на методах поисковой оптимизации сайтов и отрасли в целом.
Robots.txt — это текстовый файл, находящийся в корневой директории сайта, в котором записываются специальные инструкции для поисковых роботов, разработан Мартином Костером и принят в качестве стандарта 30 июня 1994 года.
В то же время, кривая настройка robots.txt может нанести проекту огромный вред. Рассуждать о правильности того или иного примера robots.txt можно бесконечно долго. Предлагаю остановиться на фактах.
Еще недавно Google был настолько примитивен, что видел сайты лишь в виде HTML-кода. В прошлом году, с приходом алгоритма Panda 4, Google стал видеть сайты такими же, какими их видят пользователи. Вместе с CSS и исполненным JavaScript.
Это изменение коснулось и Вордпресс.
На многих сайтах используются старые приёмы, которые блокируют индексацию системной директории /wp-includes/, в которой часто хранятся JS-библиотеки и стили, необходимые для работы сайта. А это значит, Google увидит сайт уже не таким, каким его видят посетители.
Получается, что старая практика больше не работает.
На многих Вордпресс-сайтах закрывалась от индексации и другая системная директория /wp-admin/. Что правильно, по-сути. Но если на сайте используется асинхронная загрузка страниц (AJAX), это может блокировать загрузку внутренних страниц. Потому что admin-ajax.php, который за всё это отвечает, расположен в /wp-admin/.
Директорию /wp-admin/ можно оставить закрытой от индексации, но тогда необходимо отдельно разрешить индексацию admin-ajax.php.
Если в вашем Вордпресс используется один из старых способов оформления robots.txt, нужно обязательно проверить какие конкретно директории скрываются от индексации и удалить все запреты, блокирующие загрузку страниц.
Для проверки рекомендую использовать Google Search Console, в котором необходимо предварительно зарегистрироваться, добавить проверяемый сайт и подтвердить права на него. Это делается очень просто.
Как проверить Robots.txt
Проверить robots.txt на ошибки можно с помощью инструмента проверки файла robots.txt — именно так и называется этот инструмент в разделе «Сканирование» Google для веб-мастеров.
Кстати, проверить robots.txt на ошибки можно и в Яндекс Вебмастере. Но в Google Search Console все равно нужно зарегистрироваться, потому что только там можно проверить видимость сайта поисковыми пауками Гугла. Конкретно это делается в разделе «Сканирование» с помощью инструмента «Просмотреть как Googlebot».
Если сайт выглядит таким же как и в браузере, значит все в порядке, robots.txt ничего не блокирует. Если же имеются какие-то отличия, что-то не отображается или сайт не виден вообще, значит придется выяснить, где происходит блокировка и ликвидировать её.
Как же должен выглядеть правильный Robots.txt для Вордпресс
Я все больше убеждаюсь, что лучше делать сразу минимальный robots.txt и закрывать только /wp-admin/. Естественно, открыв admin-ajax.php, если есть AJAX-запросы. И обязательно указываем Host и Sitemap.
Мой robots.txt чаще всего выглядит так:
В заключение
Создать универсальный правильный robots.txt для всех сайтов на Вордпресс невозможно.
На каждом сайте работает конкретная тема, набор плагинов и типов данных (CPT), которые генерируют свой уникальный пул URL.
Robots.txt часто корректируется уже в процессе эксплуатации сайта. Для этого осуществляется постоянный мониторинг индекса сайта. И если в него попадают какие-то ненужные страницы, они исключаются. Например, в индекс иногда попадают страницы с параметрами ?p и ?s.
Их можно исключить.
Иногда даже попадают фиды, которые тоже можно закрыть.
Вообще, задачи по исключению страниц из индекса правильнее решать на уровне кода, закрывая страницы от сканирования с помощью метатега «noindex».
Для Яндекса инструкции в robots.txt и метатег «noindex» работают одинаково — страница удаляется из индекса. А вот для Гугла robots.txt — это запрет на индексирование, а метатег «noindex» — запрет на сканирование. И если, допустим, страница заблокирована в robots.txt, поисковый робот может просто не обнаружить метатег «noindex» на этой странице, и она останется в индексе. Об этом прямо написано в Справке Search Console.
Как видим, Robots.txt может быть очень опасен для сайта.
Бездумные действия с этим файлом могут привести к печальным последствиям. Не спешите с помощью него закрывать все подряд директории. Пользуйтесь плагином Yoast SEO — он позволяет настроить правильные запреты с помощью метатегов.
Делаю сайты на Вордпресс с 2008 года, занимаюсь их оптимизацией, беру на поддержку, делюсь опытом в блоге и соцсетях (ссылки ниже, подпишитесь)
Мой роботс для гугла под WordPress. И то под каждый шаблон желательно его подтачивать, так как некоторые плагино-делы могут делать ссылки, контент и тд по левым урлам =(
Как уменьшить нагрузку на сервер с помощью admin-ajax в WordPress
Главное меню » Блог-платформа wordpress » Как уменьшить нагрузку на сервер с помощью admin-ajax в WordPress
Во время тестирования скорости вашего сайта на WordPress с помощью онлайн инструментов тестирования скорости, вы, возможно, заметили, что файл admin-ajax.php отвечает за медленный опыт загрузки. В этой статье мы расскажем об этом файле, и как вы сможете уменьшить время отклика сервера и загрузку процессора за счет уменьшения количества запросов, генерируемых admin-ajax.php.
Что такое admin-ajax.php в WordPress?
Еще в 2013 году, WordPress представил WordPress Heartbeat API, который обеспечил несколько важных функций, такие как функция автосохранения, по истечении логина предупреждения блокировки в то время как другой пользователь пишет или редактирует пост на WordPress.
Две очень характерные особенности Heartbeat API:
1. Автосохранение
Всякий раз, когда вы сохраняете проект поста и продолжаете работу над ним, WordPress автоматически сохраняет дополнения к посту. Существует четкое различие между автосохранением и сохранением проекта вручную. Проверьте следующий скриншот, который показывает оба типа экономит:
2. Сообщение блокировки
Всякий раз, когда вы пытаетесь изменить пост, с которым работает другой пользователь, появится всплывающее предупреждение о ситуации. Есть три действия, доступные для вас.
Вышеперечисленные особенности стали возможными благодаря API WordPress Heartbeat, который создает связь между сервером и браузером для соответствующего сообщения и ответов.
WordPress Heartbeat API генерирует запросы для связи с сервером и запускает события на прием/ответ данных. Как правило, это увеличивает нагрузку на сервер и в конечном итоге замедляет панель администратора WordPress.
Живой пример
Мы вошли в приборную панель WordPress и приступили к редактированию поста. Далее, мы оставили вкладку открытой в течение нескольких минут, и начали просмотр других вкладок. Приборная панель по – прежнему в системе, и вы можете увидеть, что admin-ajax непрерывно посылает запросы.
В соответствии с упомянутым выше билетом, администратор-ajax.php в WordPress генерирует запросы через каждые 15 секунд. Запросом может быть любая связь с сервером.
Ускорить панель администратора WordPress
Чтобы ускорить бэкэнд WordPress, лучший подход, это отключить Heartbeat API или по крайней мере установить более продолжительный промежуток времени, так чтобы он не генерировал запросы на сервере через каждые несколько секунд.
Установить плагин Heartbeat Control
Войдите в админку WordPress и перейдите к Плагины >> Добавить новый, найдите Heartbeat Control, установите и активируйте его.
Настройка плагина Control Heartbeat
Перейдите на вкладку Настройки >> Настройки Control Heartbeat. Там вы найдете три раскрывающихся меню для настройки плагина.
1. Разрешить Heartbeat:
Вы можете выбрать ту область, где Heartbeat API будет работать. Есть три варианта на выбор:
2. Отключить Heartbeat:
Выберите этот параметр, если хотите, чтобы WordPress Heartbeat API отключался в определенных местах. Будьте осторожны при выборе местоположения, потому что другие плагины могут также использовать WordPress Heartbeat API. Если вы единственный пользователь серверной части WordPress, я бы предложил отключить его везде, а затем проверить, нарушает ли он веб-сайт. Тем не менее, если ваш сайт имеет более одного пользователя, который регулярно вносит свой вклад, мы бы предложили, чтобы вы разрешили Heartbeat API только на страницах редактирования публикации.
3. Изменить Heartbeat:
Эта выпадающее меню позволяет установить интервал времени, в пределах 0 – 300 секунд, чтобы выполнить админ Ajax запросы. Если установить его на 120 секунд, то запрос будет сгенерирован через каждые 120 секунд. Это позволит значительно снизить нагрузку на сервер. Настройте его в соответствии с вашими потребностями.
Создание нескольких правил
Вы можете создать несколько правил, основанных на ваших требованиях. Например, вы хотите WordPress вызвать каждые 120 секунд, но после редактирования срабатывать на 60 секунд. Для этого необходимо создать два правила. Один для панели мониторинга WordPress и другой для редактора постов и установить их частоту в 120 и 60 соответственно.
Обнаружение плагинов, которые используют Heartbeat API
Теперь, когда вы настроили все, настало время, проверить, какие плагины замедляют веб-сайт с помощью файла admin-ajax.php.
Заключительные слова
Учитывая его набор функций, Heartbeat API является очень полезным на вашем сайте WordPress. Однако, если он не используется правильно, это может увеличить время загрузки на бэкэнд WordPress и на сам сайт, посылая туда и сюда запросы в WordPress.
Есть только два решения этой проблемы. Либо отключить Heartbeat API/включить его только в нескольких местах.
Если вы используете какой – либо плагин кэширования, например, W3TC, не забудьте отключить кэш объектов. Это также ускорит приборную панель WordPress.
Если у вас есть какие-либо предложения или запрос, не стесняйтесь оставить комментарий ниже.
Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.
Ajax в WordPress
Цель этой статьи показать, как использовать AJAX при создании тем и плагинов.
Видео уроки об AJAX в WordPress:
AJAX в админ-панели WordPress
С тех пор, как AJAX был встроен в админ-панель WP, использовать функционал AJAX в плагинах стало очень удобно. Небольшой пример. Все делается в одном файле (файле плагина или файле темы functions.php ).
#1. Добавляем javascript
Сначала добавляем на страницу админки javascript код, который будет посылать AJAX запрос.
#2. Создаем PHP функцию
Теперь, создадим PHP функцию, которая будет обрабатывать переданный AJAX запрос. Для этого добавляем следующий код в functions.php (можно в плагин):
Примера выше достаточно, чтобы начать использовать AJAX в админ-панели WordPress.
По возможности всегда используйте wp_die() вместо die() или exit(), в функции обработки AJAX запроса. Так вы добьетесь лучшей интеграции с WordPress и в случае ошибок в коде, получите данные о них.
AJAX на фронтэнде (в теме)
Т.е. чтобы создать обработчик запроса для всех пользователей: авторизованных и нет, PHP функцию нужно прикреплять сразу к двум хукам:
‘wp_ajax_nopriv_(action)’ можно не указывать, если не нужно, чтобы AJAX запрос обрабатывался для неавторизованных пользователей.
Переменная ajaxurl
В результате, получим в head части сайта прямо перед скриптом ‘twentyfifteen-script’:
Пример AJAX кода для фронт энда
Логичное подключение AJAX хуков
Я не стал усложнять чтение и не говорил, как правильно подключать AJAX через хуки в коде. Впрочем все что написано ниже не обязательно, потому что работать будет и так, но это рекомендуется.
Функции обработчики установленные хукам:
Оба хука всегда удовлетворяют условию wp_doing_ajax():
А значит сами хуки нужно подключать, только если срабатывает это условие.
Используя это правило, можно не подключать хуки там где в этом нет смысла. Например, при генерации страницы шаблона или страницы админки. Эта маленькая деталь добавит больше логики в код и в некоторых случаях может избавить от багов.
Пример того, как рекомендуется подключать все AJAX хуки.
В этом случае хуки будут подключены только во время AJAX запроса и не будут подключены при простом посещении фронта, админки, REST или CRON запросе.
Защита: используем nonce и проверяем права
Нет острой необходимости проверять AJAX запрос, если он потенциально не опасный. Например, когда он просто получает какие-то данные. Но когда запрос удаляет или обновляет данные, то его просто необходимо дополнительно защитить с помощью nonce кода и проверкой прав доступа.
Разработчики часто ленятся ставить такую защиту, получая самый неожиданный результат. Недобросовестные пользователи могут каким-либо образом заставить юзера с правами сделать то что им нужно и в итоге навредить сайту над которым вы работали долгие месяцы, годы.
Существует два вида защиты, которые нужно использовать в AJAX запросах в большинстве случаев.
1. Код nonce (случайный код)
Для начала создадим nonce код:
twentyfifteen-script это название основного скрипта темы (см. выше), который подключается на сайте с помощью wp_enqueue_script().
Затем, в AJAX запросе добавим переменную с кодом nonce :
Теперь, в обработке заброса необходимо проверить nonce код:
check_ajax_referer() работает на основе функции wp_verify_nonce() и по сути является её оберткой для AJAX запросов.
Обратите внимание, что в данном случае Nonce код создается в HTML коде. А это значит, что если у вас установлен плагин страничного кэширования, то этот код может и наверняка будет устаревать к моменту очередного AJAX запроса, потому что HTML код кэшируется.
2. Проверка прав доступа
Особенность тут в том, что не авторизованные пользователи тоже должны видеть сообщение об ошибке при AJAX запросе. Поэтому для них тоже нужно обрабатывать запрос и вернуть сообщение об ошибке:
Включаем кэширование для AJAX запросов
По умолчанию все AJAX запросы НЕ кэшируются браузером для этого PHP устанавливает специальные заголовки функцией nocache_headers().
Чаще всего AJAX запросы кэшировать и не надо, потому что они должны возвращать свежие данные, но бывают случаи когда такое кэширование может сэкономить ресурсы и увеличить скорость работы скрипта. Например, если у нас есть сложный фильтр товаров который юзеры используют постоянно. Тут было бы разумно кэшировать все результаты фильтра например на пару часов, все равно товары не добавляются с такой скоростью.
Как включить кэширование для указанных AJAX запросов смотрите во втором примере функции nocache_headers().
Отлавливаем баги, PHP ошибки
Проблемы могут возникнуть при AJAX запросе и появлении ошибок PHP. Заметки или сообщения могут изменить возвращаемый результат или вызвать ошибку javascript.
Дебаг (вывод ошибок на экран)
Вариант:
Как правило запросы отправляются с браузера в файл. Поэтому чтобы увидеть результат запроса, ошибку или что-либо еще, можно открыть панель разработчика, выбрать именно наш запрос среди многих и посмотреть что он вернул.
Вариант: включаем показ ошибок в AJAX запросах
WordPress по умолчанию не показывает ошибки для AJAX запросов даже если константа WP_DEBUG включена! Видно это в коде функции wp_debug_mode().
Несмотря на это такой показ можно включить, ведь на рабочих проектах у нас все равно WP_DEBUG отключена и боятся нам нечего, а вот баги выловить это помогает на ура!
Чтобы включить показ ошибок при AJAX запроса, нужно вставить такой код в файл темы functions.php или в плагин. Но лучшее его вставить как можно раньше, чтобы видеть ранние ошибки, лучше всего в MU плагины.
Вариант: вывод данных в лог файл
Вариант: вывод PHP ошибок в лог файл
Чтобы выводить PHP заметки и ошибки в лог файл, нужно включить константу WP_DEBUG_LOG. Такой лог файл появится в папке wp-content.
Вариант:
Если не получается увидеть сообщение об ошибке и нужно работать в режиме разработчика, можно очистить буфер сразу перед возвратом данных:
После этого нужно посмотреть что возвращает запрос через дебаг браузера или как-то еще.
Вариант:
Также, для дебага можно воспользоваться инструментом FirePHP, который записывает ошибки в консоль браузера.
Ошибка при возвращении данных
Плагины
Качественный и надежный сервис по продвижению в Телеграмме предлагает совершить недорогую покупку подписчиков в группу. На сайте Вы найдете массу выгодных предложений с индивидуальными условиями для каждого сообщества. Например, Вы можете выбрать оптимальную скорость поступления ресурса, которая доходит до 1000 единиц в сутки. Успейте сделать заказ, пока на сайте действуют оптовые скидки.
Отключаем от admin-ajax.php — снижаем блокировки сессий в PHP на сервере
В мне часто задают вопросы, связанные с работой скрипта admin-ajax.php на хостинге (часто его работа прерывается, заканчивается ошибкой или вызывает нагрузку на хостинг). Как решить все проблемы?
Что такое admin-ajax.php
Скрипт admin-ajax.php (так называемый WordPress heatbeat, включен с версии WordPress 3.5.2) выполняет продление пользовательской сессии WordPress — для удобства использования административной панели. Если администратор или редактор часто работает с сайтом, то это избавляет от необходимости каждый раз вводить логин/пароль. Но для 99% посетителей сайта этот функционал, скорее всего, не нужен: они ведь только читает контент, не редактируют его.
В ряде случаев admin-ajax.php может отвечать за повышенное потребление памяти и CPU на хостинге: за счет частых — каждые 15 секунд — обращений к базе данных на фоне других запросов (большинство из которых уже могут быть закэшированы). Поскольку функционал admin-ajax.php является динамическим (его нельзя кэшировать), то облако Айри, как и любой другой кэширующий инструмент, пропускает все запросы напрямую к серверу, создавая существенную нагрузку.
Как бороться с admin-ajax.php
Лучшим способом устранение нагрузки от admin-ajax.php является полное отключение этого функционала. Лучше всего это осуществить либо редактированием внутри движка WordPress, либо путем установки соответствующего плагина.
Для отключения WordPress Heartbeat для всех страниц, кроме страницы создания новой записи, нужно добавить в header.php или function.php вашей темы:
Для решения этой проблемы через плагины WordPress можно использовать AJAX Heartbeat Tool или Heartbeat Control.
Критическая уязвимость в admin-ajax.php
На прошлой неделе столкнулся с крайне неприятным фактом. Зайдя на свой сайт, обнаружил, что он переадресовывает меня на неведомый мне ресурс, на который крайне сильно ругается антивирус Dr. Web
Сайт работает на WordPress актуальной версии 5.1
Все выходящие обновления для движка, плагина и темы устанавливаются вовремя. Плагины только из официального репозитория, тема тоже.
Незамедлительно был скачан бэкап сайта, просканирован антивирусным ПО (Dr. Web, Kaspersky, AI-BOLIT) – но результатов никаких не было, все чисто.
Были проверены вручную файлы темы и некоторых плагинов, но снова не было результата.
При проверке дампа базы в таблице «wp_options» в параметре «siteurl» — таился чужой URL. Собственно на него и была переадресация.
Происходило это по принципу: при загрузке страницы параметр «siteurl» подставлялся во все
При этом происходила подгрузка вот такого скрипта:
Как чужой URL попал в базу, осталось загадкой. Сменив URL на нужный, все заработало снова, но на следующий день при проверке я снова увидел как Dr. Web ругается на переадресованную страницу. В базе снова был изменён этот параметр.
После этого были скачаны свежие логи доступа к сайту и логи ошибок. Ошибок не оказалось, а вот в логах доступа нашелся крайне интересный запрос к сайту:
Снова исправив настройки и проверив, что все работает, попробовал повторить данный запрос на сайте, но ничего не получилось. Настройка в базе не сменилась.
Надо отметить, что на сайте открыта регистрация и пользователи получают роли «Подписчика», доступ до административной части полностью закрыт.
Была предпринята попытка зарегистрировать нового пользователя, авторизоваться и после чего данный запрос к сайту сработал, настройка в базе изменилась.
В итоге получается, что если на сайте открыта регистрация пользователей, даже с ролью «Подписчик» и закрыт доступ до админки, все равно этот запрос срабатывает.
Проверено было еще на другом сайте, предварительно выключив все плагин и установив тему по умолчанию – результат такой же.
Как бороться, кроме как выключить регистрацию и удалить подозрительных пользователей – решения пока не нашел.