Apparentemente la risposta è SÌ, dovrei preoccuparmi . Dopo alcune ricerche, ho scoperto che l'avviso sembra essere correlato a errate configurazioni sul server su cui è ospitato WordPress (ad esempio un problema con il mio server, non WordPress).
Errori di configurazione comuni:
- Il server non ha DNS e quindi non riesce a capire chi sia "example.com", anche se è esso stesso.
- Gli amministratori di server, in un tentativo errato di sicurezza, hanno bloccato le richieste di "loopback", quindi non possono effettivamente richiamare se stesse.
- Il server esegue qualcosa chiamato "mod_security" o simile, che blocca attivamente la chiamata a causa di una configurazione cerebrale.
Il problema nel mio caso è stato effettivamente causato dal mio firewall (pfSense), che ha "Disabilita riflessione NAT" per impostazione predefinita (elencato come motivo comune n. 2).
Sul server stesso, ho provato a raggiungermi utilizzando Telnet e il risultato è stato il seguente:
$ telnet external.server.hostname.com 19235
Prova di XXX.XXX.XXX.XXX ...
telnet: impossibile connettersi all'host remoto: timeout della connessione
Per risolvere questo problema, ho dovuto deselezionare Disable NAT reflection sul mio firewall. Nel mio caso, questo era nell'interfaccia web di pfSense in Sistema-> Avanzate-> Firewall / NAT.
Fonte: http://forum.pfsense.org/index.php?topic=3473.0
Ora posso collegarmi a me stesso (sul server stesso) attraverso il firewall bene:
$ telnet external.server.hostname.com 19235
Prova di XXX.XXX.XXX.XXX ...
Collegato a external.server.hostname.com.
Il carattere di escape è '^]'.
e non ricevo più l'avviso PHP su wp-cron.
L'ho capito dopo aver letto questa risposta dettagliata in merito wp_cron, spiegando come funziona.
Risposta breve: aggiungi questo parametro a nel file wp-config.php: define ('ALTERNATE_WP_CRON', true);
Risposta davvero lunga, per masochisti: i posti programmati non sono ora, e non sono mai stati, "spezzati". Gli sviluppatori di WordPress non possono risolverlo perché non c'è nulla da correggere.
Il problema sta nel fatto che il tuo server, per qualche motivo, non può eseguire correttamente il processo wp-cron. Questo processo è il meccanismo di temporizzazione di WordPress, gestisce tutto, dai post programmati all'invio di pingback ai ping XMLRPC, ecc.
Il modo in cui funziona è piuttosto semplice. Ogni volta che viene caricata una pagina WordPress, WordPress internamente verifica se è necessario spegnere wp-cron (confrontando l'ora corrente con l'ultima volta in cui wp-cron è stato eseguito). Se è necessario eseguire wp-cron, prova a ristabilire una connessione HTTP a se stesso, chiamando il file wp-cron.php.
Questa connessione a se stessa è lì per un motivo. wp-cron ha molto lavoro da fare e quel lavoro richiede tempo. Ritardare l'utente a vedere la sua pagina Web mentre fa un sacco di cose è una cattiva idea, quindi ripristinando questa connessione a se stesso, può eseguire il programma wp-cron in un processo separato. Poiché WordPress stesso non si preoccupa del risultato di wp-cron, attende solo un secondo, quindi ritorna al rendering della pagina Web per l'utente. Nel frattempo, wp-cron, dopo essere stato avviato, fa il suo lavoro fino al termine o al termine del tempo di esecuzione.
Quella connessione HTTP è dove falliscono alcuni sistemi mal configurati. Fondamentalmente, WordPress si comporta come un browser web. Se il tuo sito era
http://example.com/blog , WP chiamerà
http://example.com/blog/wp-cron.php per avviare il processo. Tuttavia, alcuni server semplicemente non possono farlo per qualche motivo. Tra i possibili motivi:
- Il server non ha DNS e quindi non riesce a capire chi sia "example.com", anche se è esso stesso .
- Gli amministratori di server, in un tentativo errato di sicurezza, hanno bloccato le richieste di "loopback", quindi non possono effettivamente richiamare se stesse.
- Il server esegue qualcosa chiamato "mod_security" o simile, che blocca attivamente la chiamata a causa di una configurazione cerebrale.
- Qualcos'altro.
Il punto è che per qualsiasi motivo, il tuo server web è configurato in un modo non standard che impedisce a WordPress di fare il suo lavoro. WordPress semplicemente non può risolverlo.
Tuttavia, se si dispone di questa condizione, esiste una soluzione alternativa. Aggiungi questo a per definire nel tuo file wp-config.php:
define ('ALTERNATE_WP_CRON', true);
Questo metodo alternativo utilizza un approccio di reindirizzamento, che consente al browser degli utenti di ottenere un reindirizzamento quando il cron deve essere eseguito, in modo che tornino immediatamente al sito mentre cron continua a essere eseguito nella connessione che hanno appena abbandonato. Questo metodo è un po 'incerto a volte, motivo per cui non è l'impostazione predefinita.
Fonte: http://wordpress.org/support/topic/scheduled-posts-still-not-working-in-282#post-1175405
Come indicato in questo post dettagliato e dettagliato, se non si ha alcun controllo sulla configurazione dei server o, se applicabile, sull'ambiente, è necessario mettere una soluzione
define ('ALTERNATE_WP_CRON', true);
nel tuo file wp-config.php.
allow_url_fopenimpostato su ON?