PHP Попередження про свіжу установку (Час з'єднання вичерпано)

Я отримую це попередження PHP, коли отримую доступ до моєї нової установки WordPress 3.4.1 (норвезька мова).

Попередження: fopen (URL_TO_MY_WORDPRESS_PAGE / wp-cron.php? Doing_wp_cron = 1341476616.7605190277099609375000): не вдалося відкрити потік: з'єднання вимкнено в PATH_TO_MY_WP_FILES / wp-include / class-http.php on line

^{Це, звичайно, з встановленим WP_DEBUGпрапором true, оскільки він працює на сервері розробки.}

Це відбувається з перервами, тому, здається, це проблема wp-cron.

Можливо, це помилка в WordPress чи щось не так на моєму сервері? Чи варто хвилюватися?

Сервер - це свіжий сервер Ubuntu 12.04 VM зі стеком LAMP.

Пошук Google показує, що я не єдиний, хто переживає це. (Див. Буферовані / індексовані версії сторінок, перелічені, щоб побачити фактичні помилки.)

EDIT: Я також отримую це ж PHP попередження на першій сторінці. Чи може це бути пов’язано з тим, що веб-сервер створюється NATE? В даний час я встановив брандмауер для вказування порту 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.
Символ втечі - '^]'.

і я більше не отримую попередження 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', правда);

Цей альтернативний метод використовує підхід до перенаправлення, завдяки якому браузер користувачів отримує переспрямування, коли крону потрібно запустити, так що вони повертаються на сайт негайно, поки cron продовжує працювати в з'єднанні, яке вони щойно перервали. Цей метод іноді трохи іфій, тому це не за замовчуванням.

^{Джерело: http://wordpress.org/support/topic/scheduled-posts-still-not-working-in-282#post-1175405}

Як зазначено у цій чудовій та детальній публікації, якщо у вас немає контролю над конфігурацією ваших серверів або, якщо це застосовано, навколишнім середовищем - слід вирішити проблему.

define ('ALTERNATE_WP_CRON', правда);

у вашому файлі wp-config.php.