Como um módulo PHP faltante travou o WP-cron e gerou erro crítico no WooCommerce

Quem mantém sites em WordPress ou lojas virtuais com WooCommerce sabe que mensagens de erro nem sempre apontam para onde o problema realmente começou. É muito comum uma falha silenciosa em uma camada básica disparar sintomas em cascata que parecem indicar banco de dados corrompido, disco cheio ou incompatibilidade de temas.

Recentemente acompanhei um caso clássico em produção: ao tentar exportar produtos no WooCommerce, o painel administrativo era interrompido por uma tela de "Erro Crítico". Ao mesmo tempo, o agendamento de tarefas em segundo plano (WP-Cron) travava e inundava os logs com avisos repetitivos.

Abaixo está o processo de investigação para rastrear a causa raiz, descartar as pistas falsas no banco de dados e normalizar o ambiente ativando as extensões corretas do PHP.

Os sintomas iniciais no error_log#

Ao abrir o arquivo error_log da aplicação no terminal para acompanhar o que acontecia durante a navegação:

tail -f error_log

O log registrava uma sequência contínua de alertas do sistema de agendamento:

[06-May-2026 12:43:55 UTC] Erro de evento de reagendamento do cron para o gancho: wp_delete_temp_updater_backups, código de erro: could_not_set, mensagem de erro: Não foi possível salvar a lista de evento do cron, dados: {"schedule":"weekly","args":[],"interval":604800}
[06-May-2026 12:43:55 UTC] Erro de desativação de evento de cron para o gancho: wp_delete_temp_updater_backups, código de erro: could_not_set, mensagem de erro: Não foi possível salvar a lista de evento do cron, dados: {"schedule":"weekly","args":[],"interval":604800}
[06-May-2026 12:44:03 UTC] PHP Warning:  Declaration of Jetpack_IXR_Client::query() should be compatible with IXR_Client::query(...$args) in .../plugins/jetpack/class.jetpack-ixr-client.php on line 30
[06-May-2026 12:45:28 UTC] Erro de evento de reagendamento do cron para o gancho: wp_delete_temp_updater_backups, código de erro: could_not_set, mensagem de erro: Não foi possível salvar a lista de evento do cron...

O comportamento chamava atenção por três detalhes:

1. O código could_not_set: No código-fonte do WordPress, esse erro é disparado estritamente quando a função update_option('cron', $data) retorna falso, significando que o WordPress tentou salvar o array de eventos agendados na tabela wp_options e a operação não foi concluída.
2. O ruído de plugins legados: O aviso de compatibilidade no Jetpack poluía o log, mas era apenas um alerta de nível warning.
3. A tela de Erro Crítico no painel: Sempre que alguém tentava rodar a ferramenta de exportação de produtos do WooCommerce, a requisição quebrava com erro 500.

Eliminando as pistas falsas de banco de dados e disco#

Quando nos deparamos com erros de gravação em opções (could_not_set), o primeiro pensamento costuma ser:

• O payload do cron ficou gigante por conta de transientes acumulados?
• A tabela wp_options corrompeu o auto-incremento?
• O disco ou a cota da conta de hospedagem estourou?

1. Verificando o tamanho da opção cron#

Conectando ao MariaDB/MySQL para auditar o tamanho da string armazenada:

SELECT LENGTH(option_value) FROM wp_options WHERE option_name = 'cron';

Resultado: 4830 bytes (cerca de 4.7 KB). Esse é um tamanho perfeitamente saudável para um site ativo, descartando problemas de estouro de memória ou limites de coluna.

2. Checando o esquema da tabela wp_options#

Para descartar problemas onde migrações malfeitas removem a chave primária ou travam o AUTO_INCREMENT:

SHOW CREATE TABLE wp_options;

A estrutura retornada estava perfeita:

CREATE TABLE `wp_options` (
  `option_id` bigint(20) unsigned NOT NULL AUTO_INCREMENT,
  `option_name` varchar(191) NOT NULL DEFAULT '',
  `option_value` longtext NOT NULL,
  `autoload` varchar(20) NOT NULL DEFAULT 'yes',
  PRIMARY KEY (`option_id`),
  UNIQUE KEY `option_name` (`option_name`),
  KEY `autoload` (`autoload`)
) ENGINE=InnoDB AUTO_INCREMENT=3449613 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_520_ci

A chave primária e o índice único existiam, e o contador em 3.4 milhões de registros opera muito abaixo do teto de um bigint no InnoDB.

3. Permissões de arquivos e cota de armazenamento#

Verificando a pasta wp-content/uploads:

ls -la wp-content/uploads

O dono dos arquivos era o usuário correto da conta com permissões 0755. A cota de disco marcava 1.11 GB utilizados de um plano de 10 GB. O sistema de arquivos e o banco de dados estavam 100% saudáveis.

Interceptando o erro fatal oculto com WP_DEBUG_LOG#

Como a infraestrutura básica não apresentava falhas, era hora de forçar o WordPress a registrar a stack trace completa do que ocorria nos bastidores.

No arquivo wp-config.php, inserimos as diretivas recomendadas para depuração em produção (registrando em log sem expor erros na tela dos visitantes):

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

Ao recarregar a tela de exportação de produtos no painel administrativo do WooCommerce, o arquivo wp-content/debug.log registrou imediatamente o motivo da parada:

[06-May-2026 12:55:03 UTC] PHP Fatal error:  Uncaught Error: Class 'DOMDocument' not found in /home/usuario/public_html/wp-content/plugins/product-import-export-for-woo/admin/wt-ds/classes/class-wt-ds-template-engine.php:145
Stack trace:
#0 .../admin/wt-ds/class-wbte-ds.php(261): Wbte\Pimpexp\Ds\Classes\Wt_Ds_Template_Engine->render(Array)
...
[06-May-2026 12:55:04 UTC] jp-sitemap: -- WARNING: Jetpack can not load necessary XML manipulation libraries. This can happen if XML support in PHP is not enabled on your server. XML support is highly recommended for WordPress and Jetpack...

A causa raiz: por que a falta do DOMDocument quebrava o WP-cron?#

A classe DOMDocument faz parte da extensão padrão de manipulação de XML do PHP (php-xml / php-dom).

A correlação entre o erro do WooCommerce e o travamento do Cron era direta:

1. No WooCommerce: O plugin de importação e exportação de produtos precisa processar templates e cabeçalhos em XML. Ao chamar new DOMDocument(), o PHP encontrou uma classe inexistente e interrompeu o script imediatamente com um Fatal Error, gerando a tela de Erro Crítico.
2. No WP-Cron: Rotinas de fundo (como a geração periódica de sitemaps do Jetpack e checagens automáticas de updates) rodam atreladas ao loop do cron. Quando o cron disparava essas tarefas, o PHP sofria o mesmo encerramento abrupto por falta de suporte a XML. Como a execução era cortada no meio, o WordPress nunca conseguia concluir a atualização da lista de tarefas agendadas no banco de dados, gerando a mensagem recorrente could_not_set.

Como resolver e quais módulos garantir no PHP#

Para servidores dedicados ou instâncias VPS rodando distribuições baseadas em RHEL/AlmaLinux/CentOS via terminal:

# Instalando o módulo XML no PHP 7.4 (ou substitua pela sua versão, ex: php81, php82)
yum install php74-php-xml php74-php-dom
# Em Ubuntu/Debian:
# apt install php-xml

# Reiniciando os serviços para carregar o módulo
systemctl restart php-fpm
systemctl restart httpd   # ou nginx

Se o servidor for gerenciado por painel como cPanel usando o PHP Selector (CloudLinux) ou MultiPHP:

1. Acesse o painel de controle e vá em Select PHP Version (ou Configuração do PHP).
2. Na aba de Extensões (Extensions), certifique-se de que os seguintes módulos estão marcados:

• dom e xml: Requisitos obrigatórios para manipulação de dados estruturados, feeds RSS e sitemaps.
• simplexml, xmlreader e xmlwriter: Usados por ferramentas de importação/exportação e APIs REST.
• bcmath: Essencial para cálculos matemáticos de alta precisão em carrinhos, taxas e fretes do WooCommerce.
• zip: Necessário para extração e empacotamento nativo de mídias e atualizações de plugins sem estourar tempo de CPU.
• imagick: Processamento otimizado de imagens de produtos e miniaturas no WordPress.
• opcache: Armazena o bytecode pré-compilado na memória, o que acelera a resposta.

Assim que a extensão dom foi habilitada, a tela de exportação de produtos voltou a carregar em menos de dois segundos e os registros de erro could_not_set sumiram por completo do log do cron.

Boas práticas para diagnosticar falhas no WordPress#

Erros no sistema de agendamento de tarefas (WP-Cron) e telas críticas no WooCommerce nem sempre têm relação direta com banco de dados ou problemas de rede.

Quando se deparar com comportamentos semelhantes:

1. Não deduza a causa apenas pela primeira linha do log: Um erro de gravação de opção frequentemente é consequência de um processo anterior que caiu de forma abrupta.
2. Use o WP_DEBUG_LOG sem medo: Ele registra a stack trace exata da quebra sem exibir erros visíveis para os clientes da loja.
3. Audite os módulos mínimos do PHP: E-commerces e plugins modernos exigem bibliotecas completas de parsing (XML/DOM), criptografia e precisão numérica (bcmath).
4. Verifique se tarefas do cron estão atrasadas: Plugins de checagem do cron (ou via WP-CLI com wp cron event list) mostram se as rotinas estão fluindo no horário correto.

Resolver uma falha investigando a correlação real entre os componentes economiza horas de manutenção e evita alterações desnecessárias em partes saudáveis da aplicação.

Veja também

WordPress WordPress: entendendo o functions.php e como adicionar recursos sem plugins

WordPress WordPress Admin Bloqueado: Diagnóstico Forense, Desbloqueio e Recuperação de Acesso via WP-CLI e MySQL

WordPress Como alterar a URL do WordPress com segurança operacional (WP-CLI, SQL e wp-config)

Este post está licenciado sob CC BY-NC.