Plugins Essenciais Moodle em 2026: Como Avaliar e Atualizar

Os plugins essenciais Moodle de uma instituição não são os mais baixados do Marketplace: são os que sobrevivem à próxima atualização sem derrubar a plataforma. Hoje, 5 de outubro de 2026, sai o Moodle 5.3 LTS, e vários plugins populares ainda não declaram suporte a ele. Este guia mostra como escolher, auditar e manter plugins sem transformar cada upgrade em uma semana de incêndio.

TL;DR

• O Moodle 5.3 LTS saiu em 05/10/2026 e exige PHP 8.3, MariaDB 11.4 ou PostgreSQL 17. O tema Classic saiu do núcleo.
• Na data deste post, plugins com dezenas de milhares de instalações (Attendance, Questionnaire, Configurable Reports, Boost Union) ainda declaram suporte só até o 5.2.
• Avalie um plugin por quatro sinais: versões suportadas, data do último release, quem mantém e quantos sites usam.
• Cada plugin é uma dívida de manutenção. Poucos plugins essenciais Moodle, bem escolhidos, valem mais que um painel cheio.
• Nunca atualize o núcleo antes de ter a lista de plugins conferida contra a versão de destino, em homologação.

Por que plugin é o que quebra a atualização do Moodle

Em mais de 15 anos operando Moodle em produção, eu vi pouca atualização falhar por causa do núcleo. O núcleo do Moodle é testado por uma equipe grande, com ciclo previsível: versão principal em abril e outubro, versões de correção a cada dois meses. Quem quebra a atualização, quase sempre, é o plugin de terceiro instalado em 2021 por alguém que já saiu da instituição.

O motivo é estrutural. Um plugin de terceiro (componente instalado fora do pacote oficial, como um tipo de atividade, bloco, tema ou relatório) depende de APIs internas do Moodle. Quando o núcleo remove uma função antiga, o plugin que ainda a chama para de funcionar. Por isso, escolher plugins essenciais Moodle é decisão de infraestrutura, não de gosto. Às vezes o erro aparece na tela de upgrade. Às vezes só na segunda-feira, quando o professor tenta lançar frequência.

O ciclo de depreciação que você precisa conhecer

A política de depreciação do Moodle define três etapas: depreciação inicial, depreciação final e remoção. Funções depreciadas em versões comuns de uma série vão para depreciação final no primeiro release da série seguinte. Funções depreciadas numa LTS ganham mais fôlego: só chegam à depreciação final no [X+2].0. O exemplo oficial é direto: algo depreciado no 4.4 entra em depreciação final no 5.0 e pode ser removido no 6.0.

Na prática, isso significa que o Moodle avisa com antecedência. O problema é que muito plugin não acompanha o aviso. O mantenedor some, o código fica parado e a instituição só descobre quando o upgrade exige uma versão que o plugin nunca suportou.

O que mudou do 5.0 ao 5.3 e afeta seus plugins

Quem ainda está no 4.5 LTS vai atravessar três mudanças grandes de uma vez ao subir para o 5.3. Vale olhar uma por uma, porque cada uma derruba um tipo diferente de plugin.

Versão	Lançamento	Mudança que atinge plugins	Requisito mínimo
5.0	14/04/2025	Saem do núcleo o editor Atto, as atividades Chat e Survey, o auth_cas, os plugins MNet e o subplugins.php legado	PHP 8.2, MariaDB 10.11, PostgreSQL 14
5.1	06/10/2025	Nova pasta /public como raiz web; plugins antigos ficam fora dela e precisam ser movidos à mão	PHP 8.2, PostgreSQL 15
5.2	20/04/2026	Ciclo regular de depreciações	SQL Server 2019
5.3 LTS	05/10/2026	Tema Classic sai do núcleo; classes antigas \external_* depreciadas	PHP 8.3, MariaDB 11.4, PostgreSQL 17

Fonte: notas de versão do Moodle 5.0, 5.1 e 5.3.

A pasta /public do 5.1 é a armadilha mais comum

A documentação oficial de atualização é clara: plugins de terceiros instalados continuam nos locais antigos, acima da nova pasta /public, e precisam ser realocados para continuar funcionando. O upgrade move o núcleo, não os seus plugins. Já atendi instituição que subiu para o 5.1 e só percebeu dias depois que o bloco de certificados tinha sumido do curso.

O Classic no 5.3 pega temas antigos

Muito tema institucional antigo foi construído como "filho" do Classic. Com a remoção do Classic do núcleo no 5.3, esses temas perdem a base. Se o seu tema herda do Classic, a migração de tema precisa entrar no cronograma antes do upgrade, não depois.

Como avaliar manutenção e compatibilidade de um plugin

O antigo Plugins Directory foi substituído pelo Moodle Marketplace, com cerca de 1.745 plugins listados. Cada página de plugin mostra os dados que importam. Para separar plugins essenciais Moodle de plugins descartáveis, eu uso quatro sinais, nesta ordem.

1. Versões suportadas

É o campo "Supports Moodle X–Y". Ele precisa incluir a versão para a qual você vai atualizar, não só a que você usa hoje. Faixa ampla como "1.9–5.2" não é garantia de qualidade: só diz que existem releases para cada versão. Abra a aba de versões e confira se há um release específico para a sua.

2. Data do último release

Plugin sem release há mais de 12 meses, num Moodle que lança versão principal a cada seis, é sinal amarelo. Sem release há dois anos, sinal vermelho. A exceção são plugins muito simples, que realmente não precisam mudar, mas mesmo esses precisam declarar a versão nova.

3. Quem mantém

Um mantenedor individual ativo pode ser excelente. Uma associação ou empresa por trás reduz o risco de abandono. O Boost Union, por exemplo, é mantido pela associação Moodle an Hochschulen e por empresas parceiras. Desconfie de plugin cujo repositório tem issues abertas há anos sem resposta.

4. Base instalada

Instalações ativas indicam quantas instituições vão pressionar o mantenedor quando algo quebrar. Plugin com 30 mil sites tem mais chance de receber correção rápida do que um com 40. Não é critério isolado, mas desempata.

Checklist para plugins essenciais Moodle antes de instalar

• O plugin resolve um problema que o núcleo do Moodle 5.x ainda não resolve?
• Declara suporte à versão atual e à próxima LTS?
• Teve release nos últimos 12 meses?
• Tem repositório público com issues respondidas?
• Tem testes automatizados e suporte ao app móvel (o Marketplace mostra selos)?
• Alguém da sua equipe sabe o que fazer se ele parar amanhã?

Se alguma resposta for "não", o plugin entra em observação, não em produção.

Os plugins essenciais Moodle em 2026, categoria por categoria

Não existe lista universal. Existe a lista de plugins essenciais Moodle para o seu tipo de instituição. Abaixo estão os que mais aparecem nos ambientes que eu opero, com o estado de compatibilidade conferido no Marketplace em 05/10/2026, dia do lançamento do 5.3.

Plugin	Função	Instalações ativas	Suporte declarado	Último release
Custom certificate	Certificados PDF personalizados	32.169	5.0 a 5.3	05/10/2026
Attendance	Frequência	23.167	até 5.2	10/09/2026
Questionnaire	Pesquisas e avaliação institucional	16.739	até 5.2	22/05/2026
Configurable Reports	Relatórios SQL sob medida	16.118	até 5.2	04/05/2026
Level Up XP	Gamificação	11.343	até 5.3	03/10/2026
Boost Union	Tema filho do Boost	9.161	4.0 a 5.2	02/10/2026
Kopere Dashboard	Painel administrativo (mantenedor brasileiro)	5.860	até 5.3	05/10/2026

Como ler essa tabela

Ela não diz que Attendance ou Boost Union são ruins. Os dois são bem mantidos e tiveram release nas últimas semanas. Ela diz que, hoje, quem atualizar para o 5.3 levando esses plugins junto está assumindo um risco sem respaldo do mantenedor. Mesmo plugins essenciais Moodle bem mantidos costumam levar semanas para declarar suporte a uma LTS nova. A decisão certa é esperar, não forçar.

Certificado, frequência e relatório: o trio que mais dói

Se o certificado parar, o aluno reclama no mesmo dia. Se a frequência parar, a secretaria acadêmica para. Se o relatório parar, a coordenação perde o número que vai para a reunião. Esses três são, na prática, os plugins essenciais Moodle de quem tem obrigação regulatória ou contratual de comprovar participação. Teste os três primeiro em qualquer homologação.

O que já está no núcleo e dispensa plugin

Antes de instalar, confira se o núcleo já faz. Autenticação multifator, H5P, editor TinyMCE e o construtor de relatórios personalizados estão no Moodle padrão. Cada plugin a menos é um item a menos na planilha de upgrade.

Os plugins que quebram a próxima atualização

Alguns padrões se repetem em quase todo diagnóstico que eu faço.

Plugins abandonados com nome conhecido

São plugins que já foram populares e pararam no 3.x ou no 4.1. Continuam instalados porque "sempre estiveram lá". No upgrade, travam a tela de verificação de plugins ou, pior, passam na instalação e quebram em execução.

Plugins que dependiam do que saiu do núcleo

Plugins atto_* dependem do Atto, que saiu do núcleo no 5.0. Relatórios que liam tabelas de Chat ou Survey perderam a fonte. Integrações via MNet acabaram. Se você não migrou isso no 5.0, vai migrar no susto ao pular para o 5.3.

Plugins modificados direto no código

Este é o pior caso. Alguém editou o código de um plugin de terceiro para "ajustar uma coisinha". A atualização do plugin sobrescreve o ajuste, ou o ajuste impede a atualização. Customização se faz com plugin próprio, hook ou tema filho, nunca editando código alheio.

Temas comprados sem contrato de atualização

Tema premium vendido uma vez, sem plano de manutenção, é uma das causas mais frequentes de Moodle preso em versão antiga. A instituição não atualiza porque o tema quebra, e o tema não atualiza porque o vendedor sumiu.

Como fazer o inventário e a atualização sem susto

Esta é a rotina que eu aplico antes de qualquer upgrade de versão principal.

1. Exporte a lista de plugins adicionais. Em Administração do site > Plugins > Visão geral dos plugins, filtre por "Plugins adicionais". Essa é a sua lista de risco.
2. Cruze cada plugin com o Marketplace. Anote versão suportada, último release e se existe release para a versão de destino.
3. Separe os plugins essenciais Moodle dos dispensáveis e classifique em três grupos: pronto, aguardando mantenedor, abandonado.
4. Decida o destino dos abandonados: substituir, reescrever como plugin próprio ou remover. Se o plugin não é usado há um semestre, a remoção é a resposta.
5. Confira o ambiente. Em Administração do site > Servidor > Ambiente, valide PHP, banco e extensões contra a versão de destino. Para o 5.3, a origem precisa ser Moodle 4.4 ou superior.
6. Faça backup completo e testável. Banco, moodledata e código. Detalhei essa rotina no guia de backup do Moodle.
7. Atualize primeiro em homologação, com cópia real da produção, e teste os fluxos críticos: matrícula, entrega de tarefa, nota, certificado, frequência.
8. Só então agende a produção, fora do período de provas.

Uma dica que poupa dados

A própria documentação do Moodle orienta: se um plugin desatualizado impedir o upgrade, apague o código do plugin em vez de desinstalá-lo pela interface. Assim os dados dele continuam no banco e voltam quando a versão compatível sair. Desinstalar pela interface apaga as tabelas.

Quando NÃO atualizar (e quando NÃO instalar)

Nem toda atualização deve acontecer no dia do lançamento. Eu recomendo esperar quando:

• algum dos seus plugins essenciais Moodle (certificado, frequência, pagamento, integração acadêmica) ainda não declara suporte à versão de destino;
• a instituição está a menos de quatro semanas de um período de provas ou de matrícula;
• o servidor ainda não tem a versão de PHP ou de banco exigida, e a troca de infraestrutura não foi testada;
• não existe ambiente de homologação.

Ficar parado também tem prazo. O Moodle 5.0 perde suporte de segurança hoje, 05/10/2026. O 4.5 LTS recebe correções de segurança até 04/10/2027. Quem está no 4.5 tem um ano para planejar o salto para o 5.3 com calma.

E não instale plugin novo quando:

• ele resolve um caso de um único curso;
• o mantenedor é desconhecido e não há repositório público;
• a função já existe no núcleo;
• ninguém na equipe vai acompanhar as atualizações dele.

Custo real de cada plugin a mais

Plugin gratuito não é plugin barato. Até os plugins essenciais Moodle cobram em quatro frentes:

• Teste a cada upgrade: alguém precisa validar o plugin a cada versão principal, duas vezes por ano.
• Segurança: o Moodle publica avisos de segurança do núcleo. A segurança do plugin depende do mantenedor dele.
• Desempenho: plugins mal escritos fazem consultas pesadas a cada página. Quando o ambiente fica lento, plugin é um dos primeiros suspeitos, como mostro no diagnóstico de Moodle lento.
• Dependência de pessoa: se só o estagiário sabe configurar o plugin, a instituição depende do estagiário.

A conta que faço com cada coordenação é simples: se o plugin não justifica duas horas de teste por semestre, ele não deveria estar instalado. E se a infraestrutura não acompanha os requisitos novos, o problema começa antes do plugin. Os requisitos de servidor estão no guia de hospedagem Moodle.

Como a Agathas Web resolve isso

A Agathas Web trabalha com Moodle como atividade principal há mais de 15 anos. Nosso time tem a Moodle Developer Certification, da Moodle Academy. Somos uma empresa independente de serviços, não um Moodle Partner. No serviço de Moodle da Agathas Web, a gestão dos plugins essenciais Moodle da instituição entra assim:

• Diagnóstico gratuito de 1 hora. Levantamos a versão atual, a infraestrutura, as integrações e a lista de plugins adicionais.
• Proposta técnica por escrito, com arquitetura, versão de destino, lista de plugins, cronograma e investimento.
• Migração entre versões (3.x → 4.x → 5.x), incluindo a realocação de plugins para a estrutura /public e a troca de temas que dependiam do Classic.
• Plugins sob medida quando o plugin de terceiro foi abandonado ou quando a regra é específica da instituição: integração com SGA, boleto e Pix, certificado, gamificação. Trabalhamos direto em PHP, Mustache, JavaScript e SQL do Moodle. O código fica com você.
• Hospedagem otimizada com PHP-FPM, Redis, OPcache e MariaDB ajustados, backup diário e monitoramento.
• Sustentação com SLA mensal: atualizações de segurança, novas versões, correções, backup verificado e suporte em português por WhatsApp, e-mail e Zoom em horário comercial.

Também integramos o Moodle à comunicação com o aluno pela API oficial do WhatsApp, quando a instituição precisa avisar sobre prazo, nota ou matrícula.

Na prática, você não fica refém de freelancer nem de plugin abandonado. E não há lock-in: o tema, os plugins customizados e os dados são seus. Para contratar, basta pedir o diagnóstico pela página de Moodle com sustentação e plugins sob medida.

Conclusão: menos plugins, mais previsibilidade

Os plugins essenciais Moodle de 2026 são poucos, bem mantidos e conferidos contra a próxima versão antes de cada upgrade. O Moodle 5.3 LTS acabou de sair e vai ser a base das instituições até 2029. É a hora certa de fazer o inventário, cortar o que não se paga e substituir o que foi abandonado.

Se a sua lista de plugins adicionais passou de 20 itens e ninguém sabe dizer quem mantém metade deles, comece separando os plugins essenciais Moodle do resto. E se preferir que alguém faça esse levantamento com você, o diagnóstico da Agathas Web para Moodle é o primeiro passo.