Módulo 7 · 7.3

Cron, Action Scheduler e staging

Módulo 7: Ser encontrado e alojamento · Tempo de leitura: 10 minutos

Objetivo de aprendizagem: Após esta lição, saberá explicar como o WooCommerce executa tarefas em segundo plano, verificar as ações agendadas e repará-las em caso de problemas, e configurar um ambiente de staging para uma loja de forma a que nenhum cliente, pagamento ou encomenda real seja afetado.

Conceitos-chave: WP-Cron, cron real, DISABLE_WP_CRON, Action Scheduler, ações agendadas, pendente, concluída, falhada, limpeza, staging para uma loja, modo de teste do fornecedor de pagamentos, e-mail desligado, webhooks, integrações, não repor a base de dados por cima da produção

O que acontece quando ninguém está a ver

Uma loja faz muito trabalho que não está diretamente ligado a um clique de um visitante:

cancelar encomendas não pagas quando termina o tempo para manter stock (lição 3.4);
enviar e-mails após uma alteração de estado, e webhooks para integrações;
atualizar relatórios e estatísticas na administração;
limpar sessões expiradas e dados temporários;
aplicar os prazos de conservação definidos em Contas e privacidade (lição 2.3);
com subscrições ou integrações de contabilidade: cobrar pagamentos e transmitir dados.

Para isso, o WordPress usa o WP-Cron e o WooCommerce usa, por cima deste, o Action Scheduler. Se não funcionarem bem, não o notará de imediato. Notará quando encomendas não pagas continuarem a reter stock, os relatórios ficarem vazios ou uma integração ficar dias atrasada.

WP-Cron e cron real

O funcionamento do WP-Cron e a razão pela qual um cron job real é melhor estão explicados no curso de WordPress, lição 6.3: o WP-Cron é executado com as visitas, não segundo um relógio, o que é pouco fiável com poucos visitantes e pesado com muitos visitantes. A solução: DISABLE_WP_CRON no wp-config.php e um cron job no seu painel de alojamento que execute o wp-cron.php de poucos em poucos minutos.

Para uma loja, isto não é uma otimização, mas um requisito:

De noite, quando há poucas visitas, as encomendas não pagas têm mesmo assim de ser canceladas a tempo.
Durante uma campanha movimentada, não quer precisamente que uma tarefa pesada em segundo plano seja executada à boleia do pedido de página de um cliente que está a finalizar a compra.

Na WebOké, cria uma tarefa destas no DirectAdmin em Tarefas Cron Jobs (DA 15.1, KB 48), com /usr/local/bin/php como caminho para o PHP; noutros fornecedores de alojamento funciona de forma semelhante no respetivo ecrã de cron. Escolha para uma loja um intervalo de um a cinco minutos, de preferência a dez. Uma tarefa executada a cada minuto que não tem nada para fazer quase não consome recursos.

Action Scheduler: a fila de espera do WooCommerce

O Action Scheduler é uma fila de espera para tarefas em segundo plano, incluída no WooCommerce e utilizada também por muitos outros plugins (subscrições, integrações de contabilidade, e-mail marketing). Cada tarefa é uma ação com uma data e hora e um estado. A fila é processada através de uma tarefa do WP-Cron (action_scheduler_run_queue), pelo que também aqui se aplica: sem um cron fiável, a fila fica atrasada.

Pode ver tudo em WooCommerce > Estado > Acções agendadas (Scheduled Actions). Existem separadores por estado:

Estado	Significado	O que fazer
Pendente (Pending)	Ainda tem de ser executada	Se houver centenas com uma data no passado, a fila está atrasada: verifique o seu cron
Em curso (In-progress)	Está a ser executada agora	Se uma ação ficar bloqueada muito tempo, consulte o registo ao lado
Concluída (Complete)	Feita	Nada; são limpas automaticamente
Falhada (Failed)	Deu um erro	Leia a mensagem de erro na coluna Registo; muitas vezes trata-se de um plugin ou de uma integração inacessível
Cancelada (Canceled)	Intencionalmente não executada	Normalmente nada

Segundo o código-fonte, o Action Scheduler limpa por predefinição as ações concluídas e canceladas ao fim de um mês e as falhadas ao fim de três meses. Se a tabela crescer mesmo assim muito, é provável que estejam a ser executadas muitas ações que falham ou são criadas repetidamente; descubra qual o plugin que as cria (a coluna Grupo e o nome do hook ajudam), em vez de se limitar a esvaziar a tabela.

Um exemplo prático na Theehuis Example: depois de uma alteração de palavra-passe, a integração com o programa de contabilidade colocava cada encomenda na fila como ação falhada. Ao fim de uma semana havia 400 ações falhadas e faltavam 60 faturas (lição 5.6). Depois de reparar a integração, o administrador pôde voltar a executar as ações uma a uma com Executar (Run).

Staging para uma loja

O que é um staging, como se cria e como se protege (palavra-passe, noindex) está explicado no curso de WordPress, lição 8.3. Na WebOké, isso é possível clonando no Installatron (DA 13.7, KB 232) e com uma pasta protegida por palavra-passe (DA 15.9); outros fornecedores de alojamento têm ferramentas semelhantes. Para uma loja, há alguns pontos adicionais, porque uma cópia de uma loja contém dados reais de clientes e pode executar ações reais.

Imediatamente após a clonagem, antes de fazer qualquer outra coisa:

Fornecedor de pagamentos em modo de teste, com chaves de teste. Um staging com chaves live pode receber pagamentos reais ou efetuar reembolsos.
E-mail desligado ou redirecionado. Caso contrário, uma cópia envia confirmações, lembretes e e-mails de carrinho abandonado a clientes reais. Utilize um plugin que bloqueie todo o e-mail ou o envie para um único endereço de teste.
Integrações e webhooks desligados. Contabilidade, sincronização de stock, etiquetas de envio, e-mail marketing: caso contrário, o staging regista faturas ou envia encomendas. Verifique também WooCommerce > Configurações > Avançado > Webhooks e as chaves da API.
Rever as ações agendadas. A fila também foi copiada. Caso contrário, as ações pendentes (um e-mail de lembrete, um pagamento de subscrição) são executadas novamente no staging.
Limitar os dados pessoais. Se não precisar de dados reais de clientes para testar, elimine-os ou anonimize-os no staging. Um staging conta para o RGPD e é frequentemente menos bem protegido (lição 5.5).

E a regra mais importante ao repor: nunca reponha a base de dados do staging por cima de uma loja em funcionamento. Entre o momento da clonagem e a reposição entraram encomendas, clientes, movimentos de stock e pagamentos; perdê-los-ia. Volte a aplicar as alterações na produção (agora já sabe que funcionam), ou sincronize apenas os ficheiros. Se tiver mesmo de ser com a base de dados, faça-o apenas com a loja em modo de manutenção, logo após uma cópia de segurança recente, e com uma ferramenta que ignore encomendas e clientes.

Testar uma atualização no staging

Um percurso típico para uma atualização importante do WooCommerce ou de um plugin de pagamentos:

Crie um staging novo (clone da produção) e acerte os cinco pontos acima.
Atualize no staging e execute a atualização da base de dados se o WooCommerce a pedir.
Faça uma encomenda de teste em modo de teste: pagar, falhar, reembolsar (lição 4.5).
Verifique em Acções agendadas e no registo de erros se há erros novos.
Depois, atualize a produção num momento calmo, com uma cópia de segurança imediatamente antes (lição 6.2).

Resumo

O WooCommerce faz muito trabalho em segundo plano; isso é executado através do WP-Cron e do Action Scheduler.
Numa loja, utilize sempre um cron job real (a cada um a cinco minutos) em vez do WP-Cron acionado por visitas.
Verifique WooCommerce > Estado > Acções agendadas: muitas ações pendentes em atraso ou falhadas são sinal de que o cron ou uma integração não funciona.
No staging: fornecedor de pagamentos em modo de teste, e-mail e integrações desligados, rever as ações agendadas, limitar os dados pessoais.
Nunca reponha uma base de dados de staging por cima de uma loja em funcionamento; volte a aplicar as alterações na produção.

Questionário

Exercício

Exercício A7.3: O seu ambiente de staging está protegido? Esta é a mesma verificação do exercício A8.3 do curso de WordPress. Primeiro precisa de uma prova de propriedade do seu domínio (um registo TXT _weboke-cursus.<domein> ou um ficheiro /.well-known/weboke-cursus-<code>.txt com o código que recebe). Em seguida, introduza o endereço da sua loja e o endereço do seu staging (um host no mesmo domínio). O programa pede a página inicial do staging, sem credenciais, e a da produção. Verde se o staging pedir uma palavra-passe (401), ou se tiver noindex e usar o seu próprio endereço (a entrada REST aponta para o host de staging), enquanto a produção não tem noindex. Laranja se o staging tiver noindex mas não tiver palavra-passe, ou não tiver um certificado válido. Vermelho se o staging estiver aberto e indexável, se o staging ainda apontar para o endereço da produção, ou se a produção tiver noindex por engano.

Perguntas para si (não são verificadas): o fornecedor de pagamentos do seu staging está em modo de teste? O e-mail está desligado ou redirecionado? As integrações e os webhooks foram desligados? Quantas ações pendentes e falhadas existem neste momento em Acções agendadas na produção?

Para saber mais

Estes artigos descrevem os passos nos painéis da WebOké; noutros painéis funcionam de forma semelhante.

Cookies na WebOké

Definições de cookies

Necessários

Marketing