Предупреждение PHP при новой установке (Время ожидания подключения истекло)

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

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

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

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

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

$ telnet external.server.hostname.com 19235
Trying XXX.XXX.XXX.XXX...
telnet: Unable to connect to remote host: Connection timed out

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

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

$ telnet external.server.hostname.com 19235
Trying XXX.XXX.XXX.XXX...
Connected to external.server.hostname.com.
Escape character is '^]'.

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

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

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

Действительно длинный ответ для мазохистов: Запланированные сообщения сейчас не "сломаны" и никогда не были "сломаны". Разработчики 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 файл.