Tema Classic Moodle saiu do 5.3: como migrar para o Boost

O tema Classic Moodle saiu do núcleo da plataforma no Moodle LMS 5.3 LTS, lançado em 5 de outubro de 2026. Quem atualizar sem se preparar vai acordar com o AVA no Boost, blocos fora do lugar e, se o config.php forçar o Classic, um aviso em todas as páginas. Neste guia eu explico o que muda, o que fazer antes do upgrade e como levar a sua identidade visual para o Boost sem refazer tudo do zero.

TL;DR

• O Moodle 5.3 removeu o Classic do core (MDL-88351). Sites no Classic são trocados para o Boost durante o upgrade.
• Se o seu config.php tem $CFG->theme = 'classic';, o upgrade não mexe nessa linha: você precisa editar ou apagar à mão, senão o Moodle exibe um aviso em toda página.
• Cor da marca, SCSS bruto, imagens de fundo e de login migram para o Boost. Presets, a barra escura (navbardark) e a posição dos blocos não migram.
• Para manter o Classic, instale-o a partir do repositório oficial no GitHub antes do upgrade. Instalar depois começa do zero.
• Tema personalizado filho do Classic precisa de decisão: manter o Classic como dependência por um tempo ou reescrever sobre o Boost. Para quem tem marca forte, a segunda opção é a que se paga.

O que aconteceu com o tema Classic no Moodle 5.3

O tema Classic Moodle nasceu em 2018, assinado por Bas Brands, como um tema filho do Boost. A ideia era dar a quem tinha saudade do antigo Clean a navegação por blocos em duas colunas laterais, sem abrir mão do SCSS e das configurações modernas do Boost. Durante quase oito anos ele foi a porta de entrada de muita instituição que não queria a gaveta lateral do Boost.

No Moodle 5.3, o tema Classic Moodle deixou de vir na caixa. A nota oficial de atualização dos desenvolvedores (o arquivo UPGRADING.md do ramo 5.3) é direta: o Classic foi removido do core, e durante o upgrade, se os arquivos do tema não estiverem presentes, as configurações compatíveis são migradas para o Boost e o Classic é desinstalado. A documentação do Classic no 5.3 confirma: sites que usavam o Classic passam para o Boost quando atualizam. O código agora vive num repositório separado, o moodlehq/moodle-theme_classic, que se descreve como removido e descontinuado do core desde o 5.3.

Na prática, o Boost passou a ser o único tema que acompanha o Moodle. Isso tem consequência direta para três perfis de AVA:

1. Quem usa o tema Classic Moodle puro, só trocando cor e logo.
2. Quem tem um tema próprio construído como filho do Classic (o caso mais delicado).
3. Quem tem cursos, categorias ou usuários com tema forçado para o Classic, mesmo que o tema do site seja outro.

Eu cuido de AVAs desde antes do Boost existir, e a experiência diz que o perfil 2 é o que mais aparece em instituições de ensino com marca forte: alguém fez um tema bonito em 2019 herdando do Classic e ninguém mais mexeu. É esse cliente que vai sofrer no upgrade.

O que a migração automática leva e o que deixa para trás

A boa notícia é que o Moodle não joga tudo fora. A má é que a migração do tema Classic Moodle leva menos do que parece. Pela nota oficial, a migração copia para o Boost apenas o que foi explicitamente personalizado no Classic, preservando o que já estava customizado no Boost quando o Classic tinha o valor padrão.

Configuração do Classic	Migra para o Boost?	O que fazer
Cor da marca (brandcolor)	Sim	Conferir contraste com a nova barra de navegação
SCSS bruto (inicial e final)	Sim	Revisar: variáveis e partials do Classic podem não existir no Boost
Imagem de fundo e de fundo do login	Sim	Conferir recorte em telas pequenas
Blocos que não podem ser adicionados (unaddableblocks)	Sim	Lista do Classic é somada à do Boost
Preset de tema e arquivos de preset enviados	Não	Criar um preset equivalente no Boost
Barra de navegação escura (navbardark)	Não	Não existe no Boost; recriar via SCSS
Posição e ordem dos blocos	Não	Revisar o layout das páginas principais
Tema forçado em curso, categoria, coorte ou usuário	Não (é zerado)	Reaplicar o tema desejado

Por que o preset não migra

O preset é o ponto de entrada SCSS do tema. O Classic compilava o preset embrulhado no próprio SCSS de abertura e fechamento, então o mesmo arquivo compilaria diferente, ou simplesmente falharia, dentro do Boost. Por isso o Moodle preferiu não arriscar. Se a identidade visual do seu tema Classic Moodle mora num preset personalizado, ela não chega ao Boost sozinha.

O problema dos blocos em duas colunas

O Classic tinha duas regiões de blocos, side-pre e side-post. O Boost tem uma só, side-pre, dentro da gaveta lateral. Os blocos que estavam na coluna da direita não somem: aparecem no fim da região padrão de cada página. Mas a ordem e a coluna original se perdem. Em página inicial de curso montada com cuidado, com calendário à esquerda e avisos à direita, o resultado costuma ficar confuso para o aluno.

Configurações misturadas

Quando o site tinha personalizado os dois temas, o Boost resultante é uma mistura de valores vindos do Classic com valores que já estavam no Boost. Não é bug, é a regra documentada. Mas significa que, depois do upgrade, alguém precisa abrir as configurações do Boost e conferir campo por campo.

A linha do config.php no tema Classic Moodle: o aviso em toda página

Muita gente não sabe, mas o Moodle permite forçar o tema direto no config.php, fora do painel. É comum em ambientes com vários sites ou em instalações onde o fornecedor anterior quis "travar" o visual:

$CFG->theme = 'classic';

A nota oficial é explícita: o upgrade não consegue alterar valores forçados no config.php. Se essa linha existir, o site continua pedindo um tema que não está mais instalado, cai no tema padrão e mostra um aviso em todas as páginas. Para o aluno, a primeira impressão do AVA recém-atualizado vira uma faixa de erro.

Como resolver

1. Antes do upgrade, procure a linha: grep -n "theme" config.php.
2. Decida o destino. Se vai para o Boost, apague a linha (o tema passa a ser escolhido no painel) ou troque por $CFG->theme = 'boost';. Se vai manter o Classic como plugin adicional, a linha pode ficar, desde que o tema esteja instalado antes do upgrade.
3. Confira também variáveis parecidas que o fornecedor anterior possa ter deixado, como listas de temas permitidos ou temas por dispositivo.
4. Depois do upgrade, limpe os caches (Administração do site > Desenvolvimento > Limpar todos os caches) e abra o AVA numa janela anônima.

Quando não apagar a linha

Se o seu tema personalizado ainda depende do Classic e você decidiu ganhar tempo mantendo o tema Classic Moodle como plugin externo, não apague a configuração no impulso. Apague só depois de garantir que o tema de destino está instalado e funcionando. Trocar a linha antes da hora joga o site no Boost padrão, sem a sua marca, em pleno período letivo.

Manter o tema Classic Moodle como plugin: quando faz sentido e quando não

O Moodle deixou uma saída: instalar o tema Classic Moodle manualmente, a partir do repositório oficial no GitHub, antes de rodar o upgrade. Assim a migração e a desinstalação são puladas por completo, e configurações e seleções de tema ficam intactas. Instalar depois do upgrade dá um tema "zerado", sem as configurações antigas nem as escolhas por curso e usuário.

Um detalhe técnico que pega muita gente: desde o Moodle 5.1, o código da plataforma fica dentro da pasta public/, e os temas core do 5.3 estão em public/theme/. O Classic precisa ir para public/theme/classic, não para a antiga theme/classic. Na versão atual do repositório, o version.php declara dependência do theme_boost, como sempre foi.

Faz sentido manter o Classic quando

• O upgrade para o 5.3 é obrigatório agora (segurança, PHP 8.3) e não há tempo para redesenhar o tema antes do próximo semestre.
• O seu tema personalizado é filho do Classic e quebraria sem ele.
• Professores e coordenação dependem da navegação por blocos em duas colunas e a mudança precisa de treinamento.

Não faz sentido quando

• Você só usava o tema Classic Moodle para ter logo e cor. O Boost faz isso nativamente, com menos manutenção.
• O AVA tem muitos acessos pelo celular. A gaveta do Boost e o índice do curso funcionam melhor em tela pequena.
• Você quer usar recursos novos do Boost, como o modo escuro experimental do 5.3, que escrevi em detalhe no guia de modo escuro no Moodle 5.3.

O ponto que eu reforço com todo cliente: manter o tema Classic Moodle é adiar, não resolver. O repositório existe, mas o tema saiu do core, e você passa a depender de um plugin fora do ciclo principal de testes do Moodle. Toda atualização futura vira um item a mais na checagem.

Tema personalizado filho do Classic: o caso que mais exige cuidado

Um tema filho declara no próprio config.php de quem ele herda, com a linha $THEME->parents. O Classic, por exemplo, declara $THEME->parents = ['boost'];. Um tema institucional construído sobre o tema Classic Moodle costuma ter algo como ['classic', 'boost'], e muitas vezes a dependência também aparece no version.php.

Se o Classic não estiver instalado, esse tema perde a base de layouts, templates e renderizadores que herdava. Dependendo de como foi escrito, o resultado vai de páginas sem estilo a erro na verificação de plugins durante o upgrade, por dependência ausente.

O que costuma estar herdado do Classic

• Layouts columns.php com as duas colunas de blocos.
• Templates Mustache sobrescritos a partir dos do Classic, como cabeçalho e rodapé.
• Callbacks de SCSS (theme_classic_get_pre_scss, theme_classic_get_extra_scss) chamados diretamente pelo tema filho.
• Renderizadores que estendem classes do theme_classic.

Duas rotas

Rota A, ganhar tempo: instalar o tema Classic Moodle como plugin antes do upgrade, manter o tema filho funcionando e planejar a reescrita para os próximos meses. É a rota certa quando o calendário acadêmico aperta.

Rota B, migrar para o Boost: trocar o $THEME->parents para ['boost'], mover o SCSS para cima das variáveis do Boost, reescrever os templates que dependiam das duas colunas e repensar a página inicial do curso para a gaveta de blocos. Dá mais trabalho agora e muito menos depois.

Para a maioria das instituições que atendo, a resposta é A seguida de B: atualizar com segurança, e reescrever com calma num ambiente de homologação.

Como migrar o tema para o Boost sem perder a identidade visual

Identidade visual não é o tema. É cor, tipografia, logo, tom das imagens e a forma como o aluno encontra as coisas. Tudo isso dá para levar para o Boost. O roteiro que usamos na Agathas Web tem seis passos.

1. Inventário antes de tocar em qualquer coisa

Tire prints das telas que importam: login, painel, página inicial do curso, uma atividade, a página de notas. Exporte as configurações do tema e copie o SCSS bruto e o preset para um repositório. Liste os cursos e categorias com tema forçado. Esse inventário é o seu gabarito de "ficou igual".

2. Ambiente de homologação com o 5.3

Nunca no servidor de produção. Clone o banco e o moodledata, suba o 5.3 com PHP 8.3 ou 8.4 de 64 bits, extensão sodium e max_input_vars em pelo menos 5000, que são requisitos oficiais da versão. Se precisar de passo a passo para levar o AVA a outro servidor, o guia de migrar o Moodle de servidor sem perder dados cobre o processo.

3. Tema filho do Boost, não Boost cru

Em vez de personalizar o Boost direto pelo painel, crie um tema filho do Boost com o nome da instituição. Assim a marca fica versionada em código, sobrevive a atualizações e pode ganhar templates próprios sem gambiarra.

4. Traduzir o SCSS

As variáveis do Bootstrap que o Boost usa ($primary, $secondary, $font-family-base) cobrem a maior parte da identidade. Substitua as referências a variáveis e partials do Classic pelas equivalentes do Boost. A barra escura que o Classic tinha via navbardark vira poucas linhas de SCSS no tema filho.

5. Redesenhar a página do curso para uma coluna de blocos

Esse é o passo em que mais vejo resistência de coordenação pedagógica. Escolha os três ou quatro blocos que realmente importam, coloque-os na ordem certa e conte com o índice do curso para a navegação. Menos blocos, aluno menos perdido.

6. Teste com gente de verdade

Peça a dois professores e cinco alunos para cumprirem tarefas comuns: entregar uma atividade, achar a nota, mandar mensagem. Se ninguém se perde, a identidade sobreviveu.

Custos e prazos realistas da mudança

Não existe preço de tabela para isso, porque o esforço depende de quanto o tema foi personalizado. Mas dá para enquadrar em três cenários, pela nossa experiência em projetos de Moodle:

Cenário	O que envolve	Esforço típico
Tema Classic Moodle só com cor e logo	Conferir a migração automática, ajustar blocos, limpar o config.php	Algumas horas, dentro da janela do upgrade
Classic com preset ou SCSS pesado	Converter o preset para o Boost, revisar SCSS, recriar a barra escura	Poucos dias, com homologação
Tema próprio filho do Classic	Rota A no upgrade e reescrita sobre o Boost (templates, layouts, renderizadores)	Algumas semanas, em paralelo ao semestre

O custo que ninguém coloca na planilha é o do suporte: na semana seguinte a um upgrade mal planejado, a caixa de entrada da secretaria acadêmica enche de "não acho o meu curso". Esse custo some quando a mudança de navegação é comunicada antes.

Armadilhas que eu já vi

• Fazer o upgrade numa sexta à noite e descobrir na segunda que os blocos da página inicial mudaram de lugar.
• Instalar o Classic depois do upgrade achando que as configurações voltam. Não voltam.
• Esquecer os temas forçados por curso: um curso com tema próprio de parceiro volta para o tema do site sem aviso.
• Copiar o SCSS do Classic para o Boost sem compilar em homologação e derrubar o carregamento de CSS do site inteiro.

Como a Agathas Web resolve isso

Quando um cliente nos procura com um AVA no tema Classic Moodle e precisa ir para o 5.3, o trabalho entra no nosso serviço de desenvolvimento e suporte Moodle e segue um roteiro fechado:

• Diagnóstico do tema: identificamos se o site usa o tema Classic Moodle puro, um preset próprio ou um tema filho, e listamos tudo que depende dele, inclusive a linha do config.php e os temas forçados por curso.
• Upgrade em homologação: clonamos o ambiente, rodamos o 5.3 com o PHP certo e comparamos tela a tela com o inventário.
• Decisão de rota com o cliente: manter o Classic como ponte (rota A) ou já entregar o tema novo sobre o Boost (rota B), com prazo e escopo por escrito.
• Tema filho do Boost versionado: a identidade visual vira código no repositório do cliente, pronta para as próximas atualizações.
• Janela de produção combinada: o upgrade acontece fora do horário de pico, com backup testado e plano de retorno.
• Acompanhamento pós-upgrade: ajustes de blocos e de navegação na primeira semana, quando os chamados aparecem.

A contratação é simples: você descreve o AVA (versão atual, tema e número de usuários) pela página de Moodle da Agathas Web e devolvemos um diagnóstico com escopo e prazo. Para quem também precisa de servidor, cuidamos da hospedagem gerenciada e da infraestrutura no mesmo contrato, e para quem fala com alunos no WhatsApp, integramos a API oficial ao fluxo do AVA.

Conclusão: decida antes do upgrade, não depois

O fim do tema Classic Moodle no core é uma mudança pequena no código e grande na rotina de quem usa o AVA. O que separa uma atualização tranquila de uma semana de chamados é a ordem dos passos: inventário, config.php revisado, decisão entre manter o Classic como ponte ou migrar para o Boost, e só então o upgrade. O 5.3 tem suporte de segurança até 1º de outubro de 2029, então vale fazer essa transição uma vez e bem feita. Se você quer um panorama mais amplo do que mais mudou na versão, leia o guia do Moodle 5.3 LTS e quando migrar. E se o seu AVA ainda roda no tema Classic Moodle e o próximo semestre está chegando, fale com a gente pelo serviço Moodle da Agathas Web para planejar a migração com prazo e escopo definidos.