Не каждый сайт живёт на своём сервере. Часть наших проектов работает на виртуальном хостинге, и там свои правила: панель вместо crontab, консоль со старым PHP, защита от ботов, которая мешает проверкам. Настройка одной задачи крона на таком хостинге заняла три захода — вот что мы на них узнали.
Это 12-я часть цикла «Сервер для WordPress». Речь об одном конкретном хостинге, но устроены похоже многие.
Планировщик: «Минуты: 1» — это раз в час
Поля планировщика в панели — обычные поля crontab, и цифра означает «ровно в этот момент», а не «каждые столько».
| Что ввели | Что получилось |
|---|---|
Минуты: 1, остальное * | раз в час, на первой минуте |
все пять полей * | раз в минуту |
Минуты: */10 | раз в 10 минут |
Адрес — не команда
В поле команды хочется вписать адрес https://site.ru/wp-cron.php. Планировщик выполняет строку в оболочке, и получается command not found. Ошибку хостинг присылает письмом на почту аккаунта — оттуда и узнали.
# без HTTP — надёжнее: мимо редиректов и защиты от ботов
/usr/local/bin/php8.2 ~/site.ru/public_html/wp-cron.php
# через HTTP — с самой командой curl и адресом в кавычках (из-за ? и =)
/usr/bin/curl -s -o /dev/null "https://site.ru/wp-cron.php?doing_wp_cron=1"
Тильда в пути раскрывается. А вот посмотреть задачи из консоли нельзя: crontab -l по SSH недоступен, задачи живут только в панели. Работает ли задача — проверяйте по следствию: обновилась ли отметка последнего запуска в самом приложении.
PHP в консоли — 5.6
Команда php в консоли хостинга запускает PHP 5.6. Современный код на нём не разбирается, и скрипт молча ничего не делает. Версии лежат рядом, вызывать нужную явно: /usr/local/bin/php8.2. Версию, на которой работает сам сайт, видно в заголовке X-Powered-By или в панели.
Защита от ботов на POST
POST-запрос от незнакомого клиента — например, проверка ajax-адреса через curl — получает не ответ сайта, а страницу со скриптом, которая ставит куку и перезагружается. Для проверок кука подставляется явно:
curl -s -X POST "https://site.ru/wp-admin/admin-ajax.php" \
-b "beget=begetok" -A "Mozilla/5.0" -d "action=..."
GET-запросы проходят без неё.
Дамп базы с ошибкой, которая не ошибка
mysqldump: Error: 'Access denied; you need (at least one of) the PROCESS privilege(s)
for this operation' when trying to dump tablespaces
Дамп при этом делается полностью. Проверять не по этой строке, а по целостности архива (gzip -t) и по строке -- Dump completed в конце файла.
Реквизиты базы для дампа удобнее достать из wp-config.php текстом, а не подключать его в скрипт: в конце он загружает весь WordPress.
DB_NAME=$(sed -n "s/^ *define( *'DB_NAME' *, *['\"]\([^'\"]*\)['\"].*/\1/p" wp-config.php)
Время — московское
Сервер хостинга живёт по Москве, а не по UTC. Прибавлять три часа «для перевода» не нужно — это уже Москва. Проверять date и date -u рядом, прежде чем ставить задачу «на 3 ночи».
Ещё ограничения
- журналы nginx по SSH не отдаются — только в панели;
- сборка фронта на виртуальном хостинге может не уложиться в память — собирать лучше у себя и выкладывать готовое.
Задачи по расписанию на хостинге «не срабатывают»?
Пришлите, что настроено в панели, — найду, почему крон молчит.
// загружаю комментарии…