Предупреждение PHP при новой установке (Тайм-аут соединения)

Я получаю это предупреждение PHP при доступе к моей новой установке WordPress 3.4.1 (норвежский язык).

Предупреждение: fopen (URL_TO_MY_WORDPRESS_PAGE / wp-cron.php? Working_wp_cron = 1341476616.7605190277099609375000): не удалось открыть поток: истекло время соединения в PATH_TO_MY_WP_FILES / wp-includes / class-http.php в строке 923

^{Это, конечно, с установленным WP_DEBUGфлагом true, так как он работает на сервере разработки.}

Это происходит с перерывами, так что, похоже, проблема с wp-cron.

Это вероятно ошибка в WordPress или что-то не так на моем сервере? Должен ли я беспокоиться?

Сервер представляет собой новую виртуальную машину Ubuntu Server 12.04 со стеком LAMP.

Поиск Google показывает, что я не единственный, кто испытывает это. (См. Буферизованные / проиндексированные версии перечисленных страниц, чтобы увидеть реальные ошибки.)

РЕДАКТИРОВАТЬ: я также получаю это же предупреждение PHP на первой странице. Может ли это быть связано с тем, что веб-сервер NAT NAT? В настоящее время я настроил брандмауэр для указания порта с 19235 по 80 на сервере разработки.

Ответ, очевидно, ДА, я должен волноваться . После некоторых исследований я обнаружил, что предупреждение, по-видимому, связано с неправильной настройкой на сервере, на котором размещен WordPress (т.е. проблема с моим сервером, а не с WordPress).

Распространенные неправильные конфигурации:

1. Сервер не имеет DNS, и поэтому он не может понять, кто такой «example.com», даже если он сам по себе.
2. Администраторы сервера из-за ошибочной попытки безопасности заблокировали «петлевые» запросы, поэтому он не может сделать обратный вызов самому себе.
3. На сервере запущено нечто, называемое «mod_security» или аналогичное, которое активно блокирует вызов из-за тупой конфигурации.

Проблема в моем случае на самом деле была вызвана моим брандмауэром (pfSense), который по умолчанию имеет «Отключить отражение NAT» (указан как общая причина № 2).

На самом сервере я пытался дозвониться до себя с помощью telnet, и результат был следующим:

$ telnet external.server.hostname.com 19235
Попытка XXX.XXX.XXX.XXX ...
telnet: невозможно подключиться к удаленному хосту: время ожидания истекло

Чтобы это исправить, мне пришлось снять флажок Отключить отражение NAT на моем брандмауэре. В моем случае это было в веб-интерфейсе pfSense под System-> Advanced-> Firewall / NAT.
^{Источник: http://forum.pfsense.org/index.php?topic=3473.0}

Теперь я могу подключиться к себе (на самом сервере) через брандмауэр просто отлично:

$ telnet external.server.hostname.com 19235
Попытка XXX.XXX.XXX.XXX ...
Подключено к external.server.hostname.com.
Escape-символ '^]'.

и я больше не получаю предупреждение PHP о wp-cron.

Я понял это после прочтения этого подробного ответа относительно wp_cronобъяснения того, как это работает.

Краткий ответ: Добавьте это к определениям в вашем файле wp-config.php: define ('ALTERNATE_WP_CRON', true);

Действительно длинный ответ, для мазохистов: запланированные посты не сейчас и никогда не были «сломаны». Разработчики WordPress не могут это исправить, потому что нечего исправлять.

Проблема заключается в том, что ваш сервер по какой-то причине не может правильно выполнить процесс wp-cron. Этот процесс является механизмом синхронизации WordPress, он обрабатывает все, от запланированных сообщений до отправки пингбэков на эхо-запросы XMLRPC и т. Д.

Как это работает, довольно просто. Всякий раз, когда страница WordPress загружается, внутренне WordPress проверяет, нужно ли ему запускать wp-cron (сравнивая текущее время с последним, когда wp-cron запускался). Если ему нужно запустить wp-cron, он пытается установить HTTP-соединение обратно к себе, вызывая файл wp-cron.php.

Эта связь с самим собой существует по причине. У wp-cron много работы, и эта работа требует времени. Задержка просмотра пользователем своей веб-страницы, когда она делает кучу вещей, - плохая идея, поэтому, установив это соединение обратно на себя, он может запустить программу wp-cron в отдельном процессе. Поскольку сам WordPress не заботится о результате wp-cron, он только ждет секунду, а затем возвращается к отображению веб-страницы для пользователя. Между тем, wp-cron, после запуска, выполняет свою работу до тех пор, пока не завершится или не истечет время выполнения.

В этом HTTP-соединении происходит сбой некоторых плохо настроенных систем. По сути, WordPress работает как веб-браузер. Если ваш сайт был http://example.com/blog , то WP позвонит по адресу http://example.com/blog/wp-cron.php, чтобы начать процесс. Однако некоторые серверы просто не могут этого сделать по какой-то причине. Среди возможных причин:

1. Сервер не имеет DNS, и поэтому он не может понять, кто такой «example.com», даже если он сам по себе .
2. Администраторы сервера из-за ошибочной попытки безопасности заблокировали «петлевые» запросы, поэтому он не может сделать обратный вызов самому себе.
3. На сервере запущено нечто, называемое «mod_security» или аналогичное, которое активно блокирует вызов из-за тупой конфигурации.
4. Что-то другое.

Дело в том, что по какой-то причине ваш веб-сервер настроен нестандартным способом, который мешает WordPress выполнять свою работу. WordPress просто не может это исправить.

Однако, если у вас есть это условие, есть обходной путь. Добавьте это к определениям в вашем файле wp-config.php:

define ('ALTERNATE_WP_CRON', true);

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

^{Источник: http://wordpress.org/support/topic/scheduled-posts-still-not-working-in-282#post-1175405}

Как указано в этом замечательном и подробном сообщении, если у вас нет контроля над конфигурацией серверов или, если применимо, средой - это обходной путь.

define ('ALTERNATE_WP_CRON', true);

в вашем файле wp-config.php.