Resolvendo problemas
Um roteiro para diagnosticar problemas do plugin, do mais barato para o mais trabalhoso.
1. Descartar o óbvio
- Atualizações pendentes — WordPress, tema e plugins (o nosso incluído) na última versão.
- Conflito de plugin ou tema — desative os outros plugins e troque para um tema padrão do WordPress. Se o problema some, reative um a um até encontrar o culpado.
- Cache — LiteSpeed, WP Rocket, WP Super Cache, W3 Total Cache e afins guardam versões antigas das páginas. Limpe o cache sempre que mexer em layout ou configurações.
2. Olhar a fila e o histórico do plugin
Antes de partir para ferramentas externas, o plugin já responde duas perguntas:
- Joinotify → Histórico mostra o que foi enviado, para quem e com qual status.
- Joinotify → Fila de processamento mostra o que ficou pendente e o que falhou. Falhas temporárias são reenviadas; erros de configuração — token inválido, janela de 24 horas fechada, template inexistente — ficam parados aí, porque insistir não mudaria o resultado.
Mensagem que nunca sai e não aparece na fila costuma ser fluxo inativo ou gatilho que não disparou. Mensagem que aparece na fila e não sai é problema de credencial, de janela ou de WP-Cron — veja Requisitos mínimos.
3. Depurar com o Query Monitor
O Query Monitor é a forma mais rápida de ver o que acontece em uma tela específica. Use enquanto você ainda tem acesso ao painel.
Instale por Plugins → Adicionar novo, ative, e abra a barra que aparece no topo do painel:
- Erros PHP — avisos e erros fatais da página atual.
- Consultas de banco — consultas lentas ou com falha.
- Ganchos e ações — o que está sendo executado, útil para achar conflitos.
- Requisições HTTP — chamadas a serviços externos, incluindo as do Joinotify. É aqui que aparece uma falha de conexão com a API.
Erros que acontecem em chamadas AJAX ou REST não aparecem na tela. Abra o console do navegador, ou a aba Rede, clique na requisição marcada em vermelho e veja a resposta.
4. Ativar o modo de depuração do WordPress
Use quando não houver acesso ao painel. Edite o wp-config.php, na seção
For developers: WordPress debugging mode:
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
Os erros passam a ser gravados em wp-content/debug.log.
WP_DEBUG_DISPLAY em produçãoDeixar WP_DEBUG_DISPLAY como true mostra os erros para os visitantes, junto com caminhos de
arquivo do servidor. Em um site no ar, mantenha false e leia o arquivo de log.
Para problemas envolvendo WooCommerce, a página WooCommerce → Status → Logs também registra erros fatais e entradas do próprio plugin.
5. Problemas comuns
Erro 500 — erro interno do servidor
O servidor falhou mas não diz onde. As causas mais frequentes são erro de PHP, .htaccess
inválido, permissão de arquivo, limite de recursos do servidor ou conflito entre plugins.
Como investigar: ative o modo de depuração (passo 4) e leia o debug.log. Se o erro
aparecer só em uma tela, o Query Monitor aponta a linha.
Página em branco
Erro fatal de PHP com a exibição de erros desligada. Mesmo caminho: modo de depuração e leitura do log.
CSS ou JavaScript não carrega
Verifique o console do navegador e, no Query Monitor, se há requisições falhando para arquivos de asset. Plugins de otimização que combinam ou adiam scripts costumam ser a causa — teste desativando a otimização.
Mensagem não chega ao destinatário
Confira, nesta ordem: o número está correto e com código do país; o fluxo está ativo; o gatilho realmente disparou (veja o histórico); a chave da API do Joinotify está salva; e, no transporte Cloud, se a janela de 24 horas está aberta. Veja Transporte pelo Joinotify Cloud.
6. Falar com o suporte
Se nada acima resolveu, reporte o problema. Inclua:
- O que você estava fazendo quando o problema aconteceu.
- Capturas de tela do erro.
- Erros do Query Monitor ou trechos do
debug.log. - Versões do WordPress, do tema, do Joinotify e dos plugins envolvidos.
Quanto mais completo o relato, menos idas e vindas. Não prestamos suporte a plugins ou temas de terceiros.