web-dev-qa-db-fra.com

PHP Avertissement sur la nouvelle installation (connexion expirée)

Je reçois ce PHP Avertissement lors de l’accès à ma nouvelle installation de WordPress 3.4.1 (en norvégien).

 Avertissement: fopen (URL_TO_MY_WORDPRESS_PAGE/wp-cron.php? Doing_wp_cron = 1341476616.76051907090607575000): échec de l'ouverture du flux: connexion interrompue dans la classe PATH_TO_MY_WP_FILES/wp.

Ceci est bien sûr avec l'indicateur WP_DEBUG défini sur true, car il est exécuté sur un serveur de développement.

enter image description here

Cela se produit par intermittence, donc il semble y avoir un problème avec wp-cron.

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

Le serveur est un serveur Ubuntu récent 12.04 VM avec la pile LAMP.

La recherche Google montre que je ne suis pas le seul à en être victime. (Voir les versions tamponnées/indexées des pages répertoriées pour connaître les erreurs réelles.)

EDIT: Je reçois aussi le même message PHP Warning sur la page d'accueil. Cela pourrait-il être lié au fait que le serveur Web est en cours de traitement? Actuellement, j'ai configuré le pare-feu pour qu'il pointe le port 19235 sur 80 sur le serveur de développement.

wp-cronwarnings
10
ohaal

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

Mauvaises configurations communes:

  1. Le serveur n'a pas de DNS et ne peut donc pas savoir qui est "exemple.com", même s'il est lui-même.
  2. Les administrateurs de serveur, dans une tentative de sécurité peu judicieuse, 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 dû à mon pare-feu (pfSense), qui a "Désactiver NAT reflet" par défaut (répertorié comme raison commune n ° 2).

Sur le serveur lui-même, j'ai essayé de me joindre via Telnet. Le résultat est le suivant:

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

Pour résoudre ce problème, je devais décocher Désactiver NAT reflet sur mon pare-feu. Dans mon cas, il s'agissait de l'interface Web de pfSense sous Système-> Avancé-> Pare-feu/NAT.
Source: http://forum.pfsense.org/index.php?topic=3473.0

enter image description here

Maintenant, je peux me connecter (sur le serveur lui-même) à travers le pare-feu, très bien:

 $ 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, en 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 publications programmées ne sont pas, et n'ont jamais été, "interrompues". Les développeurs de WordPress ne peuvent pas le réparer car il n'y a rien à réparer.

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 programmées à l'envoi de requêtes pingback aux requêtes ping XMLRPC, etc.

La façon dont cela fonctionne est assez simple. Chaque fois qu'une page WordPress est chargée, WordPress vérifie en interne si elle doit être déclenchée par wp-cron (en comparant l'heure actuelle à la dernière exécution de wp-cron). S'il doit exécuter wp-cron, il essaie de se connecter à nouveau via HTTP 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. Le fait de retarder l'utilisateur à voir sa page Web pendant qu'il parcourt un tas de choses est une mauvaise idée. Par conséquent, en rétablissant cette connexion, le programme wp-cron peut être exécuté 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, ayant été lancé, fait son travail jusqu'à ce qu'il soit terminé ou qu'il ne reste plus 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 , alors 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 savoir qui est "exemple.com", même s'il s'agit de lui-même.
  2. Les administrateurs de serveur, dans une tentative de sécurité peu judicieuse, 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 empêchant 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 à la définition de dans votre fichier wp-config.php:

define ('ALTERNATE_WP_CRON', true);

Cette autre méthode utilise une approche de redirection, ce qui permet au navigateur de l'utilisateur de recevoir une redirection lorsque le cron doit s'exécuter, de sorte qu'il revienne immédiatement sur le site pendant que cron continue de s'exécuter avec la connexion qu'ils ont récemment abandonnée. Cette méthode est parfois un peu risquée, ce qui explique pourquoi ce n'est pas la méthode par défaut.

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

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

define ('ALTERNATE_WP_CRON', true);

dans votre fichier wp-config.php.

10
ohaal