Devo desativar o WP_CRON e acionar o wp-cron.php do servidor a cada poucos minutos?

Parece que o WordPress dispara desnecessariamente o WP CRON em cada carregamento de página. Penso que, em vez de executá-lo em todas as visitas, por que não agendá-lo para ser executado a cada 5 minutos via servidor? Eu poderia simplesmente acionar o wp-cron.php a cada cinco minutos e alcançar o resultado desejado?

Existe alguma desvantagem nisso?

Não há desvantagem para executar o WP CRON usando os trabalhos cron do servidor. De fato, esta é a prática recomendada.

De acordo com o documento oficial de desenvolvimento do plugin WordPress :

O WP-Cron não é executado continuamente, o que pode ser um problema se houver tarefas críticas que devem ser executadas dentro do prazo. Existe uma solução fácil para isso. Basta configurar o agendador de tarefas do seu sistema para executar nos intervalos que você deseja (ou no horário específico necessário).

Para fazer isso, você precisa primeiro desativar o comportamento padrão do cron em wp-config.php:

define('DISABLE_WP_CRON', true);

Em seguida, programe wp-cron.phpdo seu servidor. Para Linux, isso significa:

crontab -e

No entanto, em vez de executá-lo na linha de comando (CLI), execute-o como uma solicitação HTTP. Para isso você pode usar wget:

*/5 * * * * wget -q -O - https://your-domain.com/wp-cron.php?doing_wp_cron

O WordPress carrega todos os arquivos principais necessários, plugins etc. wp-cron.phpcom o seguinte CÓDIGO:

if ( !defined('ABSPATH') ) {
    /** Set up WordPress environment */
    require_once( dirname( __FILE__ ) . '/wp-load.php' );
}

Portanto, não se preocupe, pois o WordPress não carrega recursos importantes.

Existem algumas desvantagens: primeiro, ao usar o wp-cron.php como um cli, coisas como as variáveis ​​$ _SERVER não estão definidas. As pessoas superam essa limitação usando uma solicitação curl no wp-cron.php.

Em segundo lugar, porque o próprio WP não é carregado com o wp-cron.php; se você usar um plug-in de correspondência SMTP, ele não será carregado ao chamar o wp-cron. Novamente, o uso de uma chamada de curvatura substitui esse problema. A ondulação parece ser o método mais usado.

Contudo; Prefiro usar o wp-cli depois de definir as configurações de correio no postfix e (para nginx) o php-fpm config corretamente e definir um crontab como

*/5    *   *   *   *  wp cron event list --skip-plugins --skip-themes --path="/var/www/vhosts/example.com/httpdocs/wp" --fields=hook,next_run_relative --format=csv | awk -F, '$2=="now" {print $1}' | xargs -r wp --path="/var/www/vhosts/example.com/httpdocs/wp" cron event run $1

(Liste todos os crons com campos específicos no formato csv - hook sendo o nome do cron, o parente da próxima execução é o tempo. Retire os que mostrarem 'now' como a próxima execução (que estão vencendo agora) usando AWK, passe essa lista para xargs para chame wp cron event run $HOOKcada cron.) O uso do wp-cli carrega o WordPress corretamente (eu escolho pular plugins ao listar os crons, pois os erros de código e os avisos php estragam a saída com script; mas não os ignoram ao executar o cron com xargs, como o cron pode precisar que os plugins sejam carregados)

Espero que isso lhe dê algumas dicas sobre o que procurar.

Há muitos motivos para não desativar o wp-cron. De fato, é quase impossível encontrar um caso de uso para fazer isso. Ele não torna o site lento, e é usado para coisas que você talvez não saiba.

Muitos plugins usam o WP-Cron para agendar as coisas. Eles podem ficar confusos se você desligar o agendador.

Há uma proliferação de tutoriais sobre esse assunto porque é confuso e porque não faz muito para o seu site quando você o desabilita. O que ele fará é causar uma dor de cabeça ao desenvolvedor que precisa resolver o misterioso problema que ele cria em seis meses.

Além disso, o WP Heartbeat é acionado a cada 15 segundos na área administrativa, resolvendo esse problema para 99% das pessoas que acham que o têm.

Ainda estou para encontrar uma desvantagem real na transferência do wp-cron para o serviço externo. Faz isso há muitos anos.

Especialmente no mundo de hoje, onde você pode executar aplicativos como microsserviços.

Eu uso contêineres Docker separados para cada componente do WordPress - php, web, db, crontab, redis e assim por diante). Tendo o crontab como contêiner separado, chamando o wp-cron via http usando a rede local, sendo executado somente quando necessário.

Isso reduz o estresse nos nós de back-end e melhora a segurança por ter uma superfície de ataque menor.

Se o desenvolvedor não conseguir descobrir como fazer as coisas sem precisar chamar o wp-cron em cada carregamento da página, isso significa apenas inexperiência em seu nome. "Deixar sozinho", porque você não entende como as coisas funcionam não é um bom motivo para mantê-lo.