"Invalid parameter value detected": como diagnosticamos e resolvemos no Moodle

Este é um caso real de produção, contado sem identificar o cliente. Uma plataforma Moodle 4.x começou a exibir um modal de erro em toda página — logo ao carregar, antes de qualquer clique. A mensagem: "Invalid parameter value detected". Formulários paravam de abrir, a categoria de curso vinha vazia, o editor de texto ficava em branco. Na prática, a plataforma virou inutilizável para gestores e professores.

O reflexo comum nessa hora é entrar em pânico e cogitar reinstalar. Quase nunca é preciso. Abaixo está exatamente como tratamos esse tipo de chamado — o método, não o improviso.

O sintoma: por que o erro aparece em qualquer página

"Invalid parameter value detected" é a cara da invalid_parameter_exception. O Moodle valida cada chamada de web service (AJAX) contra o tipo esperado: se um serviço espera um número inteiro e recebe texto, um contexto que não existe mais, ou um array onde deveria vir uma string, ele recusa. Como o JavaScript de cada página dispara essas chamadas ao carregar, o erro salta como modal em toda tela — não é a página X que está quebrada, é uma chamada de fundo que roda em todas.

Passo 1 — Isolar a chamada AJAX culpada

Nada de adivinhar. Abrimos o F12 → aba Network, filtramos por service e recarregamos a página. Ali aparece qual methodname retorna erro e qual parâmetro é inválido. Em paralelo, ativamos o debug completo do Moodle (nível 32767) com log em arquivo e lemos o stack trace do PHP, que aponta a linha exata da validação que falhou.

Passo 2 — Reproduzir por CLI, fora do navegador

Com o serviço suspeito em mãos, reproduzimos a chamada por PHP CLI no servidor, com os mesmos parâmetros. Isso tira o navegador e o cache da equação e responde uma pergunta só: o serviço falha por causa do dado ou por causa do ambiente? A partir daí o diagnóstico deixa de ser palpite.

Passo 3 — As causas raiz que mais aparecem

Neste tipo de chamado, o erro quase sempre cai em um destes bolsos:

• Contexto inválido. Uma categoria ou curso apontando para um contexto que não existe mais (contextid quebrado). Reconstruir os caminhos de contexto resolve.
• Categoria com parent órfão. O seletor de categoria usa AJAX; se uma categoria referencia um pai que foi apagado, a validação estoura. Corrige-se restaurando a hierarquia (depth/path).
• Tema retornando nulo. Temas customizados que leem uma configuração inexistente e a repassam a uma chamada de idioma. No PHP 8.x isso vira erro em vez de aviso. A correção é tratar o valor nulo na origem.
• Autosave do editor com contexto zero. O editor envia o contexto da página; se ele não existe, a chamada de autosave falha em toda edição. Ajusta-se a configuração do editor.
• Sessão antiga (sesskey inválido). Páginas abertas há muito tempo carregam uma chave de sessão vencida. Limpar sessões e refazer login encerra o sintoma.

Passo 4 — Confirmar de onde vem: tema ou núcleo

Um teste rápido separa 90% dos casos: trocamos temporariamente para o tema Boost e recarregamos. Se o erro some, o problema está no tema customizado; se persiste, está no núcleo/dados do Moodle. Esse único passo economiza horas de investigação no lugar errado.

O resultado

Identificada a causa, o conserto é cirúrgico e preserva todos os dados — nada de reinstalar. Fechamos sempre desativando o debug, limpando caches e sessões, e deixando a plataforma como deveria estar: cada página carregando limpa, sem modal. O tempo de tela travada acaba no mesmo atendimento; a plataforma volta a ser usável para quem depende dela no dia a dia.

A moral do caso: um erro que parece catastrófico ("nada funciona, o Moodle quebrou") costuma ser uma causa pontual — desde que alguém saiba onde olhar e siga um método em vez de sair mexendo. É a diferença entre um fornecedor que sabe o que faz e um que só reinstala e reza. Sobre reincidências, veja também erros comuns do Moodle e por que o Moodle fica lento.