Cron WordPress не выполняется в FASTPANEL: правильный путь к PHP CLI

Почему WordPress Cron в FASTPANEL не выполняется, хотя задача добавлена?

Если cron-задание присутствует в FASTPANEL, но WordPress ничего не выполняет, сначала нужно посмотреть фактическую команду, PHP CLI и путь к сайту. Наличие строки в crontab подтверждает только настройку планировщика. Успешный запуск PHP и WordPress этим ещё не доказан.

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

Разделите проверку на четыре уровня:

1. системный cron запускает строку по расписанию;
2. указанный PHP CLI существует и стартует;
3. PHP открывает правильный файл wp-cron.php;
4. WordPress выполняет нужное событие или задачу плагина.

Ошибка на любом из этих уровней снаружи выглядит одинаково: «cron не работает». Если команда начинается просто с php, cron может получить системную версию PHP. Если PHP выбран правильно, но путь к сайту ошибочный, загрузка WordPress не начнётся. А если интерпретатор и путь верны, проблема уже может проявиться в виде PHP Fatal error внутри темы или плагина.

На этапе диагностики лучше не скрывать вывод команды, а временно записать stdout и stderr в отдельный файл:

/opt/php82/bin/php /var/www/USER/data/www/DOMAIN/wp-cron.php >> /tmp/wp-cron-test.log 2>&1

После тестового запуска откройте лог:

tail -n 50 /tmp/wp-cron-test.log

Если там No such file or directory, искать причину в WordPress пока рано. Если появляется PHP Fatal error, cron и PHP уже дошли до выполнения кода, поэтому следующий этап — CMS, плагины и окружение PHP.

Дополнительно стоит посмотреть фактический crontab и тот PHP, который доступен текущему пользователю:

crontab -l
php -v
command -v php
which php

Сначала отделяем планировщик от того, что он запускает. После этого проблема перестаёт выглядеть как один большой «неработающий cron» и разбивается на конкретные проверки.

Как определить, какой PHP CLI реально запускает cron в FASTPANEL?

PHP 8.2 в настройках сайта ещё не означает, что cron тоже запускает PHP 8.2. Версию для фоновой команды нужно проверять в CLI-контексте того пользователя, которому принадлежит cron-задание.

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

Почему php -v и PHP сайта могут показывать разные версии?

Команда php -v показывает CLI-интерпретатор текущего пользователя. WordPress в браузере в это же время может обслуживаться другой версией через PHP-FPM или FastCGI. Поэтому ситуация, когда сайт работает на PHP 8.2, а SSH показывает PHP другой ветки, сама по себе не говорит о неисправности FASTPANEL.

Начать можно с трёх команд:

php -v
command -v php
readlink -f "$(command -v php)"

php -v показывает версию, command -v php — путь, который shell связывает с командой php, а readlink помогает увидеть реальный бинарник, если используется символическая ссылка.

Затем сравните результат с конкретной альтернативной версией. Для PHP 8.2:

/opt/php82/bin/php -v

Полезна и ещё одна проверка:

/opt/php82/bin/php -r 'echo PHP_BINARY, PHP_EOL;'

Она выводит бинарник, которым реально выполняется команда. Если обычный php -v показывает одну ветку, а /opt/php82/bin/php -v — другую, источник расхождения уже найден.

Почему PHP CLI нужно проверять от имени пользователя cron?

Проверка под root может дать ложное ощущение, что всё настроено правильно. У root и владельца сайта могут отличаться PATH, PHP CLI, переменные окружения и доступ к файлам. Типичная картина: администратор запускает команду вручную под root — она работает; то же задание автоматически выполняется от пользователя сайта — и молчит.

Сначала выясните текущего пользователя:

whoami
id

Затем убедитесь, что просматриваете именно его задания:

crontab -l

Если есть административный доступ, тест нужно повторить в контексте того пользователя, которому принадлежит сайт и cron. Конкретный способ переключения пользователя зависит от прав на сервере, поэтому смысл проверки важнее универсальной команды: php -v должен выполняться в том же пользовательском контексте, что и будущее задание.

После изменения PHP CLI также не стоит полагаться на старую открытую SSH-сессию без повторной проверки. Откройте новую сессию или снова выполните php -v и command -v php, чтобы увидеть актуальное окружение.

Как найти правильный путь к PHP CLI в FASTPANEL?

Для альтернативной версии PHP в FASTPANEL лучше использовать полный путь к бинарнику и подтвердить его на конкретном сервере. Для PHP 8.2 может использоваться /opt/php82/bin/php, для PHP 7.4 — /opt/php74/bin/php. Подставлять номер версии по аналогии без проверки не нужно.

Сначала посмотрите доступные бинарники:

ls -l /opt/php*/bin/php

Если нужная версия найдена, сразу запустите её:

/opt/php82/bin/php -v

Нормальный результат — вывод ожидаемой версии PHP CLI без No such file or directory и других ошибок запуска.

Как проверить бинарник PHP перед добавлением cron?

Наличие файла само по себе ничего не говорит о версии. Поэтому две проверки лучше выполнять подряд:

ls -l /opt/php82/bin/php
/opt/php82/bin/php -v

Если известная структура не найдена, поиск можно расширить:

find /opt -maxdepth 3 -type f -name php 2>/dev/null

Начинать с широкого find обычно нет необходимости. Сначала достаточно посмотреть ожидаемые каталоги альтернативных версий, а затем уже искать глубже.

Отдельная ловушка — /usr/bin/php. Такой путь может существовать, команда может завершаться без ошибок, но это ещё не означает, что именно эта версия подходит текущему WordPress и его плагинам. Проверяем не просто наличие PHP, а конкретный runtime.

После того как бинарник подтверждён через -v, его полный путь можно переносить в cron. Тогда выбор интерпретатора больше не зависит от PATH.

Как составить рабочую cron-команду для WordPress в FASTPANEL?

Надёжная cron-команда WordPress содержит абсолютный путь к PHP CLI и абсолютный путь к wp-cron.php. Это убирает сразу две неопределённости: какой PHP будет запущен и из какого каталога cron попытается открыть файл WordPress.

Базовый шаблон:

/opt/php82/bin/php /полный/путь/к/wordpress/wp-cron.php

Каталог сайта на сервере с FASTPANEL может иметь структуру вида:

/var/www/USER/data/www/DOMAIN/

USER и DOMAIN здесь обозначают реального пользователя и домен. Их нужно заменить значениями конкретного сайта.

Рабочий шаблон получается таким:

/opt/php82/bin/php /var/www/USER/data/www/DOMAIN/wp-cron.php

Почему для cron лучше использовать абсолютные пути?

Команда php wp-cron.php часто работает в SSH только потому, что администратор перед этим перешёл в каталог сайта:

cd /var/www/USER/data/www/DOMAIN
php wp-cron.php

После этого та же строка переносится в cron и перестаёт работать. Причина простая: cron стартует не из каталога WordPress и не обязан видеть wp-cron.php в текущей рабочей директории.

Это легко воспроизвести вручную. Перейдите в домашний каталог и запустите короткую команду:

cd ~
php wp-cron.php

Если появляется ошибка о том, что файл не найден, проблема не в расписании. Команда просто зависела от предварительного cd.

Абсолютный вариант от текущей директории уже не зависит:

cd ~
/opt/php82/bin/php /var/www/USER/data/www/DOMAIN/wp-cron.php

На этапе диагностики добавьте лог:

/opt/php82/bin/php /var/www/USER/data/www/DOMAIN/wp-cron.php >> /home/USER/wp-cron.log 2>&1

После ручного запуска посмотрите код возврата:

echo $?

Код 0 означает, что процесс завершился без системной ошибки, но не доказывает выполнение конкретного события WordPress. Например, нужная задача может вообще не быть запланирована или плагин может обработать ошибку внутри собственного кода. Поэтому exit code — промежуточный критерий.

Cron любит абсолютные пути. В этой задаче они действительно убирают большую часть различий между ручным запуском и автоматическим выполнением.

Почему сайт работает на PHP 8.2, а WordPress Cron падает на ошибке PHP?

Работающий WordPress в браузере не гарантирует идентичное CLI-окружение. Веб-запросы могут идти через PHP 8.2, а cron — через другую версию, другой php.ini или другой набор расширений.

Симптомы здесь уже конкретнее: PHP Fatal error, синтаксическая ошибка, сообщение об отсутствующей функции или extension. Сам cron при этом может быть полностью исправен — он запустил команду и получил ошибку уже от PHP или WordPress.

Сначала сверяем бинарник и конфигурацию:

/opt/php82/bin/php -v
/opt/php82/bin/php -r 'echo PHP_BINARY, PHP_EOL;'
/opt/php82/bin/php --ini
/opt/php82/bin/php -m
/opt/php82/bin/php -i | grep memory_limit

В выводе php --ini обратите внимание на строку Loaded Configuration File. Она показывает, какой php.ini загрузил CLI. Если веб-PHP и CLI читают разные конфигурационные файлы, одинаковый номер версии ещё не означает одинаковое окружение.

Один из характерных случаев: версия в обоих контекстах совпадает, но cron падает примерно с такой ошибкой:

PHP Fatal error: Uncaught Error: Call to undefined function ...

Тогда повторно менять версию PHP уже не нужно. Следующий шаг — сравнить расширения через php -m. У веб-PHP может быть подключён модуль, который отсутствует у CLI. Это могут быть, например, curl, mbstring, intl или zip, если их использует конкретный код. Этот список не универсален — смотреть нужно на саму ошибку.

Похожая ситуация возникает с memory_limit, timezone и другими настройками. Сайт через браузер работает, а тяжёлая фоновая задача завершается только в CLI-контексте. Тогда сравнивать нужно уже не номер версии, а конфигурацию.

Если веб-PHP и CLI совпадают по версии, php.ini понятен, а нужные extensions доступны, можно переходить к самому WordPress. До этого момента проблема всё ещё находится на уровне runtime.

Как проверить WordPress Cron вручную до добавления задачи в FASTPANEL?

Перед сохранением cron-команды в FASTPANEL выполните её вручную в том же виде, в каком она будет запускаться автоматически. Это самый быстрый способ отделить ошибку PHP или WordPress от неисправности планировщика.

Последовательность:

1. Убедиться, что выбран нужный PHP CLI.
2. Проверить существование wp-cron.php.
3. Выполнить точную будущую команду.
4. Посмотреть stderr.
5. Проверить код завершения.
6. После успешного теста перенести строку в cron.

Проверка файла:

test -f /var/www/USER/data/www/DOMAIN/wp-cron.php && echo OK

Если выводится OK, запустите WordPress нужным PHP:

/opt/php82/bin/php /var/www/USER/data/www/DOMAIN/wp-cron.php
echo $?

Если задача выполняется подозрительно долго, сразу измерьте время:

time /opt/php82/bin/php /var/www/USER/data/www/DOMAIN/wp-cron.php

Если ручной запуск падает, расписание пока не трогаем. Cron не исправит неправильный путь, отсутствующий extension или Fatal error.

Команду также нужно тестировать в том же пользовательском контексте, в котором она будет выполняться автоматически. Успешный запуск под root не подтверждает, что владелец сайта имеет те же права и видит тот же PHP.

Что проверять, если правильный PHP CLI найден, но cron всё равно не работает?

Если /opt/php82/bin/php -v показывает правильную версию, wp-cron.php существует, а ручной запуск проходит, дальше нужно проверять сам планировщик, пользователя, рабочую директорию и конкретную задачу внутри WordPress. Повторно менять PHP в такой точке обычно уже некуда.

Выполняется ли cron от правильного пользователя?

Root и владелец сайта могут иметь разные PATH, права и CLI-настройки. Поэтому сначала фиксируем пользовательский контекст:

whoami
id
crontab -l

Если команда тестировалась по SSH под одним пользователем, а задание создано у другого, сравнение некорректно. Файлы WordPress также должны быть доступны пользователю cron.

При Permission denied не стоит сразу менять chmod или chown наугад. Сначала определите, какой пользователь запускает команду и на каком именно объекте возникает отказ.

Почему команда работает после cd, но не запускается из cron?

Одна из самых понятных микросцен выглядит так: администратор входит по SSH, выполняет cd в каталог WordPress, запускает php wp-cron.php и получает успешный результат. В cron переносится только последняя строка. Планировщик стартует из другого каталога и файл уже не находит.

Проверить зависимость от рабочей директории можно вручную:

cd ~
php wp-cron.php

Если команда перестала работать, проблема локализована. Используйте абсолютные пути:

/opt/php82/bin/php /var/www/USER/data/www/DOMAIN/wp-cron.php

Не скрывается ли ошибка из-за отсутствия логирования?

Cron может запускаться каждый раз по расписанию, а PHP каждый раз завершаться ошибкой. Если stderr перенаправлен в /dev/null или вообще нигде не сохраняется, внешне это выглядит как полное отсутствие выполнения.

На несколько запусков добавьте диагностический файл:

>> /home/USER/wp-cron-debug.log 2>&1

Сам планировщик можно проверить независимо от PHP:

* * * * * date >> /tmp/cron-alive.log

Если строки со временем появляются, cron выполняет задание. Следующий уровень — минимальный PHP-тест:

* * * * * /opt/php82/bin/php -r 'echo date("c"), PHP_EOL;' >> /tmp/php-cron-alive.log 2>&1

Получается простая диагностическая развилка:

• date не работает — смотрим cron, пользователя и расписание;
• date работает, PHP-тест нет — смотрим PHP CLI и права;
• PHP-тест работает, wp-cron.php падает — смотрим WordPress и PHP-окружение;
• wp-cron.php работает, но нужной операции нет — смотрим конкретное событие или очередь плагина.

Что делать, если wp-cron.php запускается, а задача плагина всё равно стоит?

Успешный запуск wp-cron.php подтверждает работу планировщика WordPress, но не гарантирует исправность каждой фоновой системы плагинов. Например, WooCommerce и некоторые другие плагины используют Action Scheduler. В таком случае сам WP-Cron может запускаться нормально, а конкретная очередь оставаться в состоянии Pending или накапливать Failed-задачи.

Если проблема касается WooCommerce, после проверки wp-cron.php уже нужно смотреть Scheduled Actions и ошибки конкретной очереди. Это другой уровень диагностики. Перенастраивать PHP CLI только потому, что одна задача плагина не завершилась, без дополнительных признаков не стоит.

Что делать, если wp-cron.php выполняется дольше интервала запуска?

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

Сначала посмотрите длительность вручную через time, а при подозрении на зависшие процессы — список запущенных команд:

ps -eo pid,user,etime,cmd | grep '[w]p-cron.php'

Если одновременно видны несколько долгоживущих процессов, не нужно просто уменьшать интервал cron. Сначала выясните, какая задача задерживает выполнение. Для тяжёлых сценариев иногда используют отдельную блокировку запуска, но добавлять flock вслепую тоже не стоит: сначала нужно подтвердить реальное перекрытие процессов.

Как правильно заменить встроенный WP-Cron системным cron в FASTPANEL?

Отключать встроенный WP-Cron можно только после того, как системный cron уже работает и выполняет события WordPress. Если сначала установить DISABLE_WP_CRON, а потом обнаружить ошибку в новой команде, фоновые события могут вообще перестать запускаться.

Последовательность можно сократить до четырёх этапов:

1. Подтвердить PHP CLI и абсолютный путь к wp-cron.php.
2. Запустить строку вручную и получить понятный результат.
3. Добавить системный cron и проверить несколько автоматических запусков.
4. После этого включить DISABLE_WP_CRON.

Пример задания раз в пять минут:

*/5 * * * * /opt/php82/bin/php /var/www/USER/data/www/DOMAIN/wp-cron.php

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

После подтверждения системного cron в wp-config.php можно добавить:

define('DISABLE_WP_CRON', true);

Во время первых запусков stderr лучше сохранить. Строка с полным подавлением вывода:

*/5 * * * * /opt/php82/bin/php /var/www/USER/data/www/DOMAIN/wp-cron.php >/dev/null 2>&1

подходит уже после диагностики. На этапе поиска проблемы она лишает администратора самого полезного источника информации.

PHP CLI или HTTP-запрос: как лучше запускать wp-cron.php?

WordPress Cron можно запускать не только через PHP CLI, но и HTTP-запросом к https://domain.example/wp-cron.php с помощью curl или wget. Для серверного cron прямой PHP CLI обычно проще диагностировать: можно явно выбрать бинарник и не зависеть от DNS, SSL, Nginx или Apache.

У HTTP-вызова есть свой плюс: WordPress и плагины получают окружение, более похожее на обычный веб-запрос. Это может помочь, если конкретный код рассчитывает на HTTP-переменные. Но при ошибке цепочка становится длиннее: отдельно приходится учитывать DNS, сертификат, веб-сервер и веб-PHP.

Поэтому для задачи «правильно запустить WordPress Cron через PHP CLI в FASTPANEL» логичнее начинать с прямого вызова PHP. Если он стабильно работает, добавлять HTTP-слой без причины не нужно.

Нужно ли использовать WP-CLI?

WP-CLI полезен для диагностики событий WordPress, если он уже установлен и настроен. Для базового запуска wp-cron.php он не обязателен.

wp cron event list
wp cron event run --due-now

Первая команда показывает зарегистрированные события, вторая помогает запустить те, срок которых уже наступил. Если wp-cron.php запускается без ошибок, но нужного события нет в списке, причина находится уже не в системном cron.

Как убедиться, что WordPress Cron после настройки действительно работает?

Работу WordPress Cron нужно подтверждать конкретным результатом: публикацией записи, выполнением фоновой задачи, изменением состояния очереди или другим ожидаемым событием. Успешный старт PHP и пустой stderr показывают только часть цепочки.

Контрольная проверка:

1. Убедиться, что полный путь запускает нужный PHP.
2. Выполнить cron-команду вручную.
3. Посмотреть stderr и код завершения.
4. На несколько запусков включить отдельный cron-log.
5. Дождаться автоматического выполнения.
6. Проверить timestamp лога.
7. Проверить фактическое событие WordPress или плагина.
8. Удалить временные тесты.

Проверка PHP:

/opt/php82/bin/php -v

Проверка времени изменения диагностического файла:

ls -l /home/USER/wp-cron-debug.log

Если лог обновился, это подтверждает запуск команды. Дальше нужен конечный эффект. Для запланированной публикации — сама публикация. Для фоновой операции плагина — изменение её состояния. Для WooCommerce с Action Scheduler — движение конкретных Scheduled Actions, а не просто отсутствие ошибок в wp-cron.php.

• PHP сайта и PHP CLI сверены.
• PHP CLI проверен в контексте нужного пользователя.
• Полный путь к бинарнику подтверждён через -v.
• Найден абсолютный путь к wp-cron.php.
• Команда работает без предварительного cd.
• Ручной запуск не выдаёт необъяснённых ошибок.
• stderr временно записывается в диагностический лог.
• Проверен пользователь crontab и права доступа.
• При необходимости отдельно проверены cron и PHP через тестовые задания.
• Если включается DISABLE_WP_CRON, системный cron проверен заранее.
• Подтверждено реальное событие WordPress или плагина.
• Нет необъяснённых долгих или перекрывающихся запусков wp-cron.php.
• Временные задания каждую минуту удалены.
• Диагностические логи отключены или контролируются.

Какая cron-команда для WordPress в FASTPANEL считается надёжно проверенной?

Базовый шаблон для PHP 8.2 выглядит так:

/opt/php82/bin/php /var/www/USER/data/www/DOMAIN/wp-cron.php

Но рабочей эту строку можно считать только при трёх условиях: она успешно выполняется вручную от нужного пользователя, cron запускает её по расписанию, а WordPress после запуска выполняет ожидаемое событие.

Если все три проверки проходят, временный debug-лог можно убрать и оставить рабочий интервал. Если хотя бы одна не проходит, уже понятно, где продолжать диагностику: до PHP, на уровне WordPress или внутри конкретной очереди плагина.