A resposta é aparentemente SIM, eu deveria me preocupar . Após algumas pesquisas, descobri que o aviso parece estar relacionado a configurações incorretas no servidor em que o WordPress está hospedado (ou seja, um problema no meu servidor, não no WordPress).
Configurações incorretas comuns:
- O servidor não possui DNS e, portanto, não consegue descobrir quem é "example.com", mesmo que seja ele próprio.
- Os administradores de servidor, em uma tentativa equivocada de segurança, bloquearam solicitações de "loopback", de modo que não é possível fazer uma chamada de volta para si mesma.
- O servidor está executando algo chamado "mod_security" ou similar, que bloqueia ativamente a chamada devido à configuração com morte cerebral.
O problema no meu caso foi realmente causado pelo meu firewall (pfSense), que tem "Desativar reflexão do NAT" por padrão (listado como motivo comum nº 2).
No próprio servidor, tentei me acessar usando telnet, e o resultado foi o seguinte:
$ telnet external.server.hostname.com 19235
Tentando XXX.XXX.XXX.XXX ...
telnet: Não foi possível conectar ao host remoto: a conexão expirou
Para corrigir isso, tive que desmarcar a opção Desativar reflexão NAT no meu firewall. No meu caso, isso estava na interface da web do pfSense em Sistema-> Avançado-> Firewall / NAT.
Fonte: http://forum.pfsense.org/index.php?topic=3473.0
Agora eu posso me conectar (no próprio servidor) através do firewall:
$ telnet external.server.hostname.com 19235
Tentando XXX.XXX.XXX.XXX ...
Conectado ao external.server.hostname.com.
O caractere de escape é '^]'.
e não estou mais recebendo o aviso do PHP sobre o wp-cron.
Eu descobri isso depois de ler esta resposta detalhada sobre wp_cron, explicando como funciona.
Resposta curta: adicione isso ao define no seu arquivo wp-config.php: define ('ALTERNATE_WP_CRON', true);
Resposta realmente longa, para masoquistas: as postagens agendadas não são agora e nunca foram "quebradas". Os desenvolvedores do WordPress não podem consertá-lo porque não há nada para consertar.
O problema está no fato de que seu servidor, por algum motivo, não pode executar corretamente o processo wp-cron. Esse processo é o mecanismo de sincronização do WordPress, ele lida com tudo, desde postagens agendadas até o envio de pingbacks a pings XMLRPC, etc.
O modo como funciona é bem simples. Sempre que uma página do WordPress é carregada, o WordPress verifica internamente se é necessário acionar o wp-cron (comparando a hora atual com a última vez que a wp-cron foi executada). Se ele precisar executar o wp-cron, ele tentará estabelecer uma conexão HTTP novamente, chamando o arquivo wp-cron.php.
Essa conexão de volta para si existe por um motivo. O wp-cron tem muito trabalho a fazer, e esse trabalho leva tempo. Adiar o usuário a ver sua página da Web enquanto faz várias coisas é uma má idéia; portanto, ao fazer essa conexão voltar a si, ele pode executar o programa wp-cron em um processo separado. Como o WordPress em si não se importa com o resultado do wp-cron, ele espera apenas um segundo e volta a renderizar a página da web para o usuário. Enquanto isso, o wp-cron, tendo sido lançado, faz seu trabalho até terminar ou ficar sem tempo de execução.
Essa conexão HTTP é onde alguns sistemas mal configurados falham. Basicamente, o WordPress está agindo como um navegador da web. Se seu site era
http://example.com/blog , o WP ligará para
http://example.com/blog/wp-cron.php para iniciar o processo. No entanto, alguns servidores simplesmente não podem fazer isso por algum motivo. Entre os possíveis motivos:
- O servidor não possui DNS e, portanto, não consegue descobrir quem é "example.com", mesmo que seja ele próprio .
- Os administradores de servidor, em uma tentativa equivocada de segurança, bloquearam solicitações de "loopback", de modo que não é possível fazer uma chamada de volta para si mesma.
- O servidor está executando algo chamado "mod_security" ou similar, que bloqueia ativamente a chamada devido à configuração com morte cerebral.
- Algo mais.
O ponto é que, por qualquer motivo, seu servidor da Web está configurado de alguma maneira não padrão que impede o WordPress de fazer seu trabalho. WordPress simplesmente não pode consertar isso.
No entanto, se você tiver essa condição, há uma solução alternativa. Adicione isso ao define no seu arquivo wp-config.php:
define ('ALTERNATE_WP_CRON', verdadeiro);
Esse método alternativo usa uma abordagem de redirecionamento, que faz com que o navegador dos usuários obtenha um redirecionamento quando o cron precisar ser executado, para que eles retornem ao site imediatamente enquanto o cron continuar sendo executado na conexão que acabaram de cair. Este método é um pouco duvidoso às vezes, e é por isso que não é o padrão.
Fonte: http://wordpress.org/support/topic/scheduled-posts-still-not-working-in-282#post-1175405
Conforme declarado nesta publicação excelente e detalhada, se você não tiver controle sobre a configuração dos servidores ou, se aplicável, o ambiente - uma solução alternativa é colocar
define ('ALTERNATE_WP_CRON', verdadeiro);
no seu arquivo wp-config.php.
allow_url_fopendefinido como ON?