Avertissement PHP lors d'une nouvelle installation (connexion expirée)

J'obtiens cet avertissement PHP lorsque j'accède à ma nouvelle installation de WordPress 3.4.1 (langue norvégienne).

Avertissement: fopen (URL_TO_MY_WORDPRESS_PAGE / wp-cron.php? Doing_wp_cron = 1341476616.7605190277099609375000): échec d'ouverture du flux: la connexion a expiré dans PATH_TO_MY_WP_FILES / wp-includes / class-http.php sur la ligne 923

^{Ceci est bien sûr avec l' WP_DEBUGindicateur défini sur true, car il s'exécute sur un serveur de développement.}

Cela se produit par intermittence, donc cela semble être un problème avec wp-cron.

Est-ce probablement une erreur dans WordPress ou quelque chose de mal sur mon serveur? Dois-je m'inquiéter?

Le serveur est une nouvelle machine virtuelle Ubuntu Server 12.04 avec la pile LAMP.

La recherche Google montre que je ne suis pas le seul à vivre cela. (Voir les versions tamponnées / indexées des pages répertoriées pour voir les erreurs réelles.)

EDIT: Je reçois également ce même avertissement PHP sur la première page. Cela pourrait-il être lié au fait que le serveur Web est NATé? Actuellement, j'ai configuré le pare-feu pour pointer le port 19235 à 80 sur le serveur de développement.

La réponse est apparemment OUI, je dois m'inquiéter . Après quelques recherches, j'ai trouvé que l'avertissement semble être lié à des erreurs de configuration sur le serveur sur lequel WordPress est hébergé (c'est-à-dire un problème avec mon serveur, pas WordPress).

Erreurs de configuration courantes:

1. Le serveur n'a pas de DNS et ne peut donc pas déterminer qui est "example.com", même s'il est lui-même.
2. Les administrateurs de serveur, dans une tentative erronée de sécurité, ont bloqué les demandes de "bouclage", de sorte qu'il ne peut pas réellement se rappeler.
3. Le serveur exécute quelque chose appelé "mod_security" ou similaire, qui bloque activement l'appel en raison d'une configuration mortelle.

Le problème dans mon cas était en fait provoqué par mon pare-feu (pfSense), qui a "Désactiver la réflexion NAT" par défaut (répertorié comme raison courante n ° 2).

Sur le serveur lui-même, j'ai essayé de me joindre en utilisant telnet, et le résultat était le suivant:

$ telnet external.server.hostname.com 19235
Essayer XXX.XXX.XXX.XXX ...
telnet: impossible de se connecter à l'hôte distant: la connexion a expiré

Pour résoudre ce problème, j'ai dû décocher la case Désactiver la réflexion NAT sur mon pare-feu. Dans mon cas, c'était dans l'interface Web de pfSense sous Système-> Avancé-> Pare-feu / NAT.
^{Source: http://forum.pfsense.org/index.php?topic=3473.0}

Maintenant, je peux me connecter à moi-même (sur le serveur lui-même) via le pare-feu:

$ telnet external.server.hostname.com 19235
Essayer XXX.XXX.XXX.XXX ...
Connecté à external.server.hostname.com.
Le caractère d'échappement est '^]'.

et je ne reçois plus l'avertissement PHP concernant wp-cron.

J'ai compris cela après avoir lu cette réponse détaillée concernant wp_cron, expliquant comment cela fonctionne.

Réponse courte: Ajoutez ceci aux définitions dans votre fichier wp-config.php: define ('ALTERNATE_WP_CRON', true);

Réponse vraiment longue, pour les masochistes: les messages programmés ne sont pas, et n'ont jamais été, "cassés". Les développeurs de WordPress ne peuvent pas le réparer car il n'y a rien à corriger.

Le problème réside dans le fait que votre serveur, pour une raison quelconque, ne peut pas exécuter correctement le processus wp-cron. Ce processus est le mécanisme de synchronisation de WordPress, il gère tout, des publications planifiées à l'envoi de pingbacks aux pings XMLRPC, etc.

La façon dont cela fonctionne est assez simple. Chaque fois qu'une page WordPress se charge, WordPress vérifie en interne si elle doit déclencher wp-cron (en comparant l'heure actuelle avec la dernière exécution de wp-cron). S'il a besoin d'exécuter wp-cron, il essaie de se reconnecter à lui-même en appelant le fichier wp-cron.php.

Cette connexion à elle-même est là pour une raison. wp-cron a beaucoup de travail à faire, et ce travail prend du temps. Retarder l'utilisateur de voir sa page Web pendant qu'il fait un tas de trucs est une mauvaise idée, donc en se reconnectant, il peut exécuter le programme wp-cron dans un processus séparé. Puisque WordPress lui-même ne se soucie pas du résultat du wp-cron, il n'attend qu'une seconde, puis revient au rendu de la page Web pour l'utilisateur. Pendant ce temps, wp-cron, après avoir été lancé, fait son travail jusqu'à ce qu'il soit terminé ou qu'il manque de temps d'exécution.

Cette connexion HTTP est l'endroit où certains systèmes mal configurés échouent. Fondamentalement, WordPress agit comme un navigateur Web. Si votre site était http://example.com/blog , WP appellera http://example.com/blog/wp-cron.php pour démarrer le processus. Cependant, certains serveurs ne peuvent tout simplement pas le faire pour une raison quelconque. Parmi les raisons possibles:

1. Le serveur n'a pas de DNS et ne peut donc pas déterminer qui est "example.com", même s'il est lui - même .
2. Les administrateurs de serveur, dans une tentative erronée de sécurité, ont bloqué les demandes de "bouclage", de sorte qu'il ne peut pas réellement se rappeler.
3. Le serveur exécute quelque chose appelé "mod_security" ou similaire, qui bloque activement l'appel en raison d'une configuration mortelle.
4. Autre chose.

Le fait est que pour une raison quelconque, votre serveur Web est configuré d'une manière non standard qui empêche WordPress de faire son travail. WordPress ne peut tout simplement pas résoudre ce problème.

Toutefois, si vous avez cette condition, il existe une solution de contournement. Ajoutez ceci aux définitions de to dans votre fichier wp-config.php:

define ('ALTERNATE_WP_CRON', true);

Cette méthode alternative utilise une approche de redirection, ce qui permet au navigateur des utilisateurs d'obtenir une redirection lorsque le cron doit s'exécuter, afin qu'ils reviennent immédiatement sur le site pendant que cron continue de s'exécuter dans la connexion qu'ils viennent de supprimer. Cette méthode est parfois un peu incertaine, c'est pourquoi ce n'est pas la valeur par défaut.

^{Source: http://wordpress.org/support/topic/scheduled-posts-still-not-working-in-282#post-1175405}

Comme indiqué dans cet article génial et détaillé, si vous n'avez aucun contrôle sur la configuration de vos serveurs ou, le cas échéant, l'environnement - une solution de contournement est de mettre

define ('ALTERNATE_WP_CRON', true);

dans votre fichier wp-config.php.