O pesadelo que é wp-cron.php

Uma das maiores queixas que tenho com o WordPress é a implementação padrão do wp-cron.php. Se você está familiarizado com a forma como o WordPress usa o wp-cron.php por padrão, você pode querer pular para a próxima seção deste artigo.

O arquivo wp-cron.php é a parte do WordPress que lida com eventos agendados dentro de um site WordPress. Qualquer coisa que tenha a ver com agendamento de mensagens ou publicações e realmente qualquer coisa orientada a data/hora é governada pelo arquivo wp-cron.php.

Para que o wp-cron.php funcione corretamente, ele precisa ser executado com freqüência, mas não mais do que uma vez por minuto. No entanto, o comportamento padrão não requer que você configure um cron job de nível real no seu servidor. Ao invés disso, ele usa um método piggyback em cada pedido recebido. Quando uma solicitação chega ao site, o WordPress gera uma solicitação adicional de si mesmo para o arquivo wp-cron.php sobre HTTP(S). Isso parece bastante inócuo, certo?

Por que o comportamento padrão do wp-cron.php é um pesadelo?

O método padrão funciona perfeitamente bem em um site pequeno com muito poucos visitantes por hora. No entanto, quando implementado num site médio ou maior ou mesmo num site que está a ser digitalizado por bots (o que é muito comum nos dias de hoje), isto significa que você obtém o dobro do tráfego que estiver a tratar actualmente. Isto torna-se um ataque rudimentar de DDoS contra si mesmo. Isto é porque o cron está sendo executado várias vezes por minuto usando um pedido HTTP. A requisição HTTP gera overhead adicional por ter que gerar, negociar e estabelecer a conexão através de um socket de rede. Ela afeta até mesmo a capacidade efetiva do seu servidor web subjacente. Esta solução não se sai bem na maioria das situações, e honestamente, ela deve ser removida como comportamento padrão devido à sua propensão a ser abusada ou transformada em um vetor de ataque em um servidor apenas do tráfego regular.

Bem, quais são as alternativas?

A única alternativa real e a solução muito melhor é configurar um cronjob de sistema regular que executa o script wp-cron.php diretamente através do PHP a cada minuto. Isto assegura que qualquer tarefa agendada seja de facto executada na sua hora agendada. Isso também não deve ser feito através de uma requisição HTTP, mas uma execução direta do PHP para evitar prejudicar a capacidade do servidor web ou gerar sobrecarga de memória adicional na camada de rede.

Como eu desabilito o comportamento padrão do wp-cron.php?

Isso é bastante universal e simples de fazer. Você precisa atualizar seu arquivo wp-cronfig.php para incluir a seguinte configuração:

define('DISABLE_WP_CRON', true);

• Você normalmente pode encontrar seu arquivo wp-config.php no diretório public_html do seu site.
• Esta nova configuração deve ser colocada no arquivo logo após a linha do banco de dados DB_COLLATE que se parece com o seguinte

define('DB_COLLATE', '');

Como eu configuro um cron job do sistema?

Isto é simples no cPanel, assumindo que seu provedor de hospedagem tenha ativado o cron job na sua conta. A documentação do cPanel Cron Jobs vai para mais detalhes mas essencialmente você faz:

1. Entrar no cPanel para o seu domínio: yourdomain.tld/cpanel
2. Entrar “cron” na caixa de busca rápida perto do topo da página.
3. Clique no ícone “Cron Jobs” que aparece.

• Se não aparecer, a sua conta não tem a funcionalidade Cron Jobs activada e terá de falar com o seu fornecedor de alojamento para obter ajuda na configuração do cron ou mudar para um pacote que inclua a funcionalidade Cron Jobs.

1. Ponha a atenção na página Cron Jobs, ela irá fornecer-lhe a localização exacta do seu binário PHP. Você precisará copiar esse caminho para a caixa de comando no final da página e alterar o arquivo sendo executado pelo PHP para ser seu arquivo /home/username/public_html/wp-cron.php. Usando o caminho completo.
2. Selecione a primeira entrada (“*”) para cada parâmetro. Isto irá executar o arquivo wp-cron.php a cada minuto.
3. Clique no botão add cron e pronto.

Por que você é tão duro nessa prática, parece razoável e fácil de corrigir?

Eu acredito que cabe aos engenheiros de software que desenvolvem nosso mundo digital impressionar a si mesmos com o senso de responsabilidade por seus produtos. O WordPress é onipresente hoje em dia e com softwares instaladores automáticos, como o Softaculous, o WordPress é instalado em uma grande maioria de sites. Eles são instalados com o comportamento padrão habilitado, que é essencialmente um vetor de ataque em qualquer servidor. Agora com a indústria de hospedagem sendo tão predominante em nossas vidas, muitas pessoas têm sites WordPress e não sabem sobre este problema até que ele paralise o site deles. A integração padrão é extremamente inadequada e deve ser removida. Hoje, só em um servidor, eu encontrei mais de 500 instalações diferentes de WordPress e vi como um bot acertando cada site no servidor. Cada um desses sites de repente se tornou uma responsabilidade pela estabilidade do servidor.

Eu percebo que este problema é tratado caso a caso. No entanto, com tantas instalações ao redor do mundo, seria melhor resolvido pelo WordPress do que por todo provedor de hospedagem que tem que configurar condições especiais em seu servidor para proteger contra o buraco que este software gera. O custo de remover este comportamento e forçar os proprietários do site a gerar um cron do sistema deve ser uma linha de base e um aviso colocado dentro da interface de administração do WordPress que as tarefas agendadas não serão executadas até que uma tarefa cron do sistema seja criada corretamente. Isso está dentro das minhas habilidades de programação, então eu sei que está bem dentro das deles.

WordPress visa a facilidade de uso, então seus consumidores alvo são aqueles que tipicamente sabem pouco sobre os cuidados com a hospedagem de caveats. Eu acredito que a responsabilidade aqui é inteiramente do WordPress para corrigir e eles tomaram a atitude contra isso. Enquanto isso, os administradores do sistema na indústria de hospedagem têm que sofrer através desta terrível “característica” ao examinar servidores que caíram fora de controle devido a um bot rodando sobre uma instalação padrão do WordPress.