Por Que Administradores do Joomla Estão Furiosos com as Mudanças de UX do Joomla 6

Se você está gerenciando sites Joomla há algum tempo, provavelmente sentiu aquele nó familiar no estômago quando uma versão principal sai. Joomla 4 foi áspero. Joomla 5 suavizou algumas arestas. Mas Joomla 6? Está se moldando como o lançamento mais divisivo da história do CMS. O painel administrativo teve uma reformulação completa de UX, o gerenciador de extensões é fundamentalmente diferente, a renderização de modelos tem mudanças incompatíveis que afetam quase todos os modelos personalizados, e a comunidade está... não lidando bem com isso.

Estou construindo e mantendo sites Joomla desde os dias do Mambo. Migrei clientes através de cada atualização dolorosa de versão principal. Então, quando digo que Joomla 6 parece diferente — não de forma boa — não estou sendo dramático. Deixe-me orientá-lo através exatamente do que mudou, por que administradores de longa data estão chateados, e quais alternativas realistas existem se você está considerando abandonar o navio.

Índice

Por Que Administradores do Joomla Estão Furiosos com as Mudanças de UX do Joomla 6

A Reformulação de UX do Painel Administrativo do Joomla 6

Vamos começar com a mudança mais visível: o painel administrativo. Joomla 6 introduz o que o time de desenvolvimento chama de "experiência administrativa moderna". Na prática, isso significa que eles removeram a navegação familiar da barra lateral esquerda que administradores do Joomla usam desde Joomla 4 e a substituíram por uma abordagem de nav superior mais barra lateral contextual.

O Que Realmente Mudou

O painel administrativo antigo tinha uma barra lateral esquerda dobrável com itens de menu aninhados. Você podia chegar a qualquer seção do CMS em no máximo dois cliques. Não era bonito, mas era funcional e — crucialmente — era consistente.

Joomla 6 se move para uma barra de navegação superior horizontal com menus mega dropdown. A barra lateral esquerda agora apenas aparece contextualmente, mostrando opções relevantes para a seção em que você está atualmente. Gerenciamento de artigos, gerenciamento de usuários, configuração de extensões — todos têm layouts de barra lateral diferentes agora.

Aqui está uma comparação dos padrões de navegação:

Ação Joomla 5 (cliques) Joomla 6 (cliques) Notas
Criar novo artigo 2 2-3 Depende do contexto atual
Acessar Configuração Global 2 3 Enterrado no menu Sistema
Gerenciar extensões 2 2-4 A nova visualização categorizada adiciona etapas
Editar arquivos de modelo 3 4-5 Editor de modelo realocado
Verificar informações do sistema 2 3 Movido para sub-menu
Gerenciar arquivos de mídia 2 2 Aproximadamente equivalente

Por Que Administradores Odeiam

A reclamação central não é que parece diferente. Administradores podem se adaptar a mudanças visuais. O problema é que a memória muscular — a coisa que torna o gerenciamento diário do CMS suportável — está completamente quebrada.

Quando você gerencia 15+ sites Joomla e está alternando entre eles durante o dia, você conta com saber exatamente onde as coisas estão sem pensar. Joomla 6 o força a re-aprender tudo. E a barra lateral contextual significa que a navegação não é nem mesmo consistente dentro do novo sistema. A barra lateral mostra itens diferentes dependendo de onde você está, o que torna mais difícil construir nova memória muscular.

Há também o ângulo de acessibilidade. Vários membros da comunidade relataram que os menus mega dropdown não funcionam bem com leitores de tela, e a navegação por teclado é inconsistente. Para um CMS de código aberto que se orgulha de acessibilidade, isso é uma regressão significativa.

O Problema dos Widgets do Painel

Joomla 6 também introduz um novo sistema de widget de painel que substitui os módulos de painel anteriores. O sistema antigo permitiu adicionar e organizar módulos de painel com flexibilidade razoável. O novo sistema de widget é visualmente mais atraente, mas significativamente menos configurável.

Você não pode mais criar layouts de painel personalizados por grupo de usuário — um recurso que muitas agências Joomla usavam para criar experiências de administrador simplificadas para clientes. Em vez disso, há um único layout de painel com alternâncias de visibilidade baseadas em função em widgets individuais. É um passo atrás em funcionalidade disfarçado como um passo adiante em design.

Gerenciador de Extensões: Tudo Que Você Sabia Está Errado

É aqui que as coisas ficam verdadeiramente dolorosas. Joomla 6 introduz um sistema de gerenciamento de extensões completamente reescrito, e quebra compatibilidade com a forma como extensões foram empacotadas e instaladas por mais de uma década.

A Nova Arquitetura de Extensões

Joomla 6 se move para um sistema de gerenciamento de extensões baseado em Composer. No papel, essa é uma ideia boa. Composer é o padrão para gerenciamento de dependências PHP, e trazer Joomla em linha com práticas PHP modernas faz sentido.

Na prática, significa:

  • Pacotes de extensão devem agora incluir um composer.json com declarações de namespace apropriadas
  • O antigo formato de manifesto XML está depreciado (ainda funciona em 6.0, mas lança avisos, agendado para remoção em 6.2)
  • Os caminhos de descoberta e instalação de extensões mudaram — scripts de instalação personalizados que referem-se a caminhos antigos vão quebrar
  • O protocolo do servidor de atualização foi revisado — extensões usando o antigo formato XML de atualização precisam migrar para o novo manifesto de atualização baseado em JSON
// Novo manifesto de extensão Joomla 6 (excerto do composer.json)
{
  "name": "vendor/my-joomla-extension",
  "type": "joomla-plugin",
  "require": {
    "joomla/cms": "^6.0"
  },
  "extra": {
    "joomla": {
      "element": "myextension",
      "group": "content",
      "namespace": "Vendor\\Plugin\\Content\\MyExtension"
    }
  }
}

A Crise de Compatibilidade de Extensões

Aqui está o impacto do mundo real: uma porção significativa do ecossistema de extensões Joomla não está pronto. De acordo com dados do Diretório de Extensões Joomla (JED) no início de 2025, aproximadamente 40% das extensões listadas não foram atualizadas para compatibilidade Joomla 5, muito menos Joomla 6.

Das extensões que são compatíveis com Joomla 5, testes iniciais sugerem que cerca de 60-70% vão precisar de modificações não triviais para funcionar com a nova arquitetura de extensões do Joomla 6. Não estamos falando sobre ajustes menores. Estamos falando sobre reestruturar a forma como extensões são empacotadas e distribuídas.

Para extensões populares como Akeeba Backup, RSForm, e JCE Editor, os desenvolvedores já anunciaram que versões compatíveis com Joomla 6 estão em desenvolvimento. Mas para os milhares de extensões menores mantidas por desenvolvedores solo ou pequenos times? Muitas delas simplesmente serão abandonadas.

O Que Isso Significa para Proprietários de Sites

Se seu site Joomla depende de cinco ou mais extensões de terceiros (e a maioria depende), você precisa fazer uma auditoria de cada uma antes de nem mesmo pensar em fazer upgrade. Crie uma planilha. Verifique o site de cada desenvolvedor de extensão para anúncios de Joomla 6. Se não há menção de suporte Joomla 6, assuma que não funcionará.

Fiz essa auditoria para três sites de clientes até agora. Dois deles têm pelo menos uma extensão crítica sem um roadmap de Joomla 6. Isso é um bloqueador de migração.

Mudanças de Incompatibilidade na Renderização de Modelos

As mudanças do sistema de modelos no Joomla 6 são o tipo de coisa que faz desenvolvedores experientes fazer careta. Joomla passou de seu tradicional sistema de sobrescrita de modelo baseado em PHP para uma abordagem híbrida que introduz uma nova camada de modelagem.

O Novo Mecanismo de Modelo

Joomla 6 introduz Twig como um mecanismo de modelo opcional (mas claramente preferido) junto com as sobrescritas tradicionais de PHP. Os modelos administrativos principais agora são escritos em Twig. Modelos de frontend podem usar PHP ou Twig, mas o sistema de descoberta de sobrescrita de modelo mudou.

{# Exemplo de modelo Twig Joomla 6 #}
{% extends "@joomla/base.html.twig" %}

{% block content %}
  <div class="com-content-article">
    <h1>{{ article.title | escape }}</h1>
    <div class="article-body">
      {{ article.introtext | raw }}
      {{ article.fulltext | raw }}
    </div>
  </div>
{% endblock %}

O Que Quebra

A ordem de descoberta de sobrescrita mudou. No Joomla 5, sobrescritas de modelo viviam em templates/your-template/html/com_content/article/default.php. Isso ainda funciona no Joomla 6, mas se uma versão Twig existe em templates/your-template/html/com_content/article/default.html.twig, a versão Twig tem prioridade.

Isso significa que se um desenvolvedor de modelo envia tanto sobrescritas PHP quanto Twig (o que muitos farão para suportar a transição), suas sobrescritas PHP personalizadas podem ser silenciosamente ignoradas. Já vi isso morder pessoas em testes beta.

Além disso, o sistema de parâmetros de modelo foi retrabalhado. Os parâmetros de modelo definidos em templateDetails.xml agora precisam de entradas correspondentes em um novo arquivo template.config.php. Os parâmetros antigos ainda carregam, mas novos recursos como preview ao vivo e o configurador visual de modelo apenas funcionam com o novo formato.

Impacto em Modelos Comerciais

Provedores de modelos comerciais como JoomlArt, GavickPro, e Youjoomla estão em uma posição difícil. Seu modelo de negócios depende de manutenção de frameworks de modelo que funcionam entre versões do Joomla. A introdução do Twig e as mudanças de prioridade de sobrescrita significam que eles essencialmente precisam reconstruir seus frameworks de modelo.

Alguns anunciaram que vão pular o suporte a Joomla 6 inteiramente e focar em suas próprias ferramentas de construtor de páginas ou transição para outras plataformas. Esse é um sinal revelador sobre como a comunidade de modelos vê essas mudanças.

Por Que Administradores do Joomla Estão Furiosos com as Mudanças de UX do Joomla 6 - arquitetura

Reação da Comunidade: Fóruns, GitHub e Mídias Sociais

A resposta da comunidade foi... intensa. E principalmente negativa.

Problemas e Pull Requests do GitHub

O repositório GitHub do Joomla viu um pico em relatórios de problemas marcados com o marco J6. Vários membros proeminentes da comunidade abriram problemas detalhados documentando regressões de UX. Um thread particularmente notável, com mais de 200 comentários, argumenta que as mudanças do painel administrativo foram empurradas através sem consulta adequada da comunidade.

A solicitação de pull que introduziu a arquitetura do novo gerenciador de extensões recebeu resistência significativa durante a revisão, com vários colaboradores de longa data votando contra o merge. Mesmo assim foi feito merge, com o time de liderança de produção citando a necessidade de modernizar a base de código.

Sentimento do Fórum

O Fórum da Comunidade Joomla e o subreddit informal do Joomla foram inundados com posts de administradores frustrados. Os temas comuns incluem:

  • "Por que consertar algo que não estava quebrado?" — O painel administrativo UX, embora não perfeito, era funcional e familiar
  • "Apocalipse de extensões" — Medos de que o sistema baseado em Composer vai matar o ecossistema de extensões
  • "Quem pediu por Twig?" — Desenvolvedores de modelos se sentindo surpreendidos pela mudança de mecanismo de modelagem
  • "Onde está o caminho de migração?" — Falta de ferramentas claras e automatizadas de migração para sites existentes

O Contexto Mais Amplo

Isso não está acontecendo no vácuo. A participação de mercado do Joomla tem estado em declínio constante. De acordo com dados de W3Techs de 2025, Joomla alimenta aproximadamente 1,5% de todos os sites com um CMS conhecido, abaixo de 2,6% em 2022. WordPress fica em mais de 62%. Toda decisão controversa acelera a migração de sites para longe da plataforma.

A frustração da comunidade não é apenas sobre Joomla 6 especificamente. É o acúmulo de anos de se sentir como a liderança do projeto não ouve as pessoas que realmente usam o software diariamente. Joomla 6 é o catalisador, mas o ressentimento tem estado construindo.

O Que a Liderança do Joomla Está Dizendo

O conselho Open Source Matters (OSM) e a liderança de produção do Joomla responderam à crítica, embora muitos sintam que as respostas foram insensíveis.

A posição oficial é que essas mudanças são necessárias para a sobrevivência de longo prazo do Joomla. O sistema de extensões baseado em Composer traz Joomla em linha com práticas modernas de desenvolvimento PHP. A camada de modelagem Twig torna a plataforma mais acessível a desenvolvedores vindos de outros frameworks. As mudanças de UX administrativa são baseadas em pesquisa de usuário (embora a metodologia de pesquisa e o tamanho da amostra tenham sido questionados).

Um post de blog do departamento de produção do Joomla no início de 2025 reconheceu a dor da transição, mas argumentou que a disrupção de curto prazo é necessária para viabilidade de longo prazo. O post fez comparações com a transição de Joomla 1.5 para 2.5, que também foi dolorosa, mas em última análise moveu a plataforma para frente.

A comparação é apropriada, mas não da forma como eles pretendem. A transição de 1.5 para 2.5 afastou uma porção massiva da comunidade. Muitos desses usuários nunca voltaram.

Você Deve Migrar ou Você Deve Sair?

Essa é a pergunta que todos estão fazendo, e a resposta honesta depende de sua situação específica.

Fique Se...

  • Seu site usa principalmente funcionalidade Joomla principal sem pesadas dependências de extensões
  • Seu modelo é baseado em Cassiopeia ou um framework que está comprometido com suporte a Joomla 6
  • Você tem desenvolvedores PHP internos que podem lidar com o trabalho de migração
  • Sua organização está comprometida com Joomla por razões políticas/institucionais

Saia Se...

  • Seu site depende de extensões que não têm um roadmap de Joomla 6
  • Você já está frustrado com Joomla e isso é a gota d'água
  • Você precisa de uma plataforma com um ecossistema crescente (não encolhente)
  • O custo de migração para outro CMS é comparável ao custo de upgrade para Joomla 6

A Realidade de Custo

Aqui está algo que as pessoas não falam o suficiente: migrar de Joomla 5 para Joomla 6 pode custar quase o mesmo quanto migrar para um CMS completamente diferente. Se você precisa reconstruir modelos, atualizar extensões, retreinar equipe, e testar tudo, você está olhando para horas significativas de desenvolvimento independentemente da plataforma de destino.

Para um site Joomla de complexidade média (50-200 artigos, 5-10 extensões, modelo personalizado), você provavelmente está olhando para 40-80 horas de trabalho de migração para Joomla 6. Uma migração para um setup de CMS headless com um frontend moderno? 60-120 horas. A lacuna não é tão grande quanto você pensaria, e a abordagem headless dá você uma plataforma com um ecossistema crescente em vez de um encolhente.

Alternativas Realistas ao Joomla em 2025

Se você está seriamente considerando alternativas, aqui está uma avaliação honesta das opções.

Plataforma Melhor Para Curva de Aprendizado Tamanho do Ecossistema Trajetória de Longo Prazo
WordPress Sites ricos em conteúdo, blogs Baixa Massiva Estável, mas Gutenberg divisivo
CMS Headless + Next.js Sites críticos em performance, apps Médio-Alto Crescendo rápido Forte para cima
CMS Headless + Astro Sites de conteúdo, sites de marketing Médio Crescendo Forte para cima
Drupal Empresa, governo, dados complexos Alto Grande Estável
Craft CMS Sites de conteúdo de tamanho médio Médio Moderado Estável
Statamic Lojas Laravel, sites de conteúdo Médio Crescendo Positivo

A Abordagem CMS Headless

Tenho viés aqui porque isso é o que fazemos na Social Animal, mas a abordagem CMS headless resolve o problema fundamental que continua reaparecendo com CMSs tradicionais como Joomla: o acoplamento de gerenciamento de conteúdo com renderização de frontend.

Quando seu CMS é headless, mudanças de UX do admin no CMS não quebram seu frontend. A renderização de modelos é manipulada pelo seu framework de frontend (Next.js, Astro, o que for), não pelo CMS. E seu conteúdo é acessível via APIs, significando que você nunca está trancafiado em uma única tecnologia de renderização.

Se você está interessado nessa abordagem, fizemos bastantes migrações de Joomla-para-headless. Nosso trabalho de desenvolvimento de CMS headless combina bem com Next.js ou Astro no frontend, dependendo de suas necessidades.

WordPress: A Escolha Óbvia?

WordPress é a sugestão padrão sempre que alguém pergunta sobre alternativas ao Joomla, e não está errado. O ecossistema é enorme, opções de hospedagem são abundantes, e a maioria dos desenvolvedores web conhecem.

Mas WordPress tem suas próprias controvérsias de UX (a saga do editor de blocos/Gutenberg espelha alguns do que está acontecendo com Joomla 6). E a dominância de mercado do WordPress o torna o maior alvo para ataques. Se você está deixando Joomla por causa de preocupações de governança, a situação atual de Matt Mullenweg do WordPress pode fazer você pausar também.

Drupal: A Escolha do Usuário Avançado

Drupal vale a pena considerar se seu site Joomla tem relações de conteúdo complexas, tipos de conteúdo personalizados, ou requisitos de empresa. Drupal 11 é sólido, e a comunidade Drupal é mais estável (se menor) do que a do Joomla.

A desvantagem: a curva de aprendizado do Drupal é acentuada, e custos de desenvolvimento são tipicamente mais altos do que Joomla ou WordPress.

Estratégias de Migração Que Realmente Funcionam

Se você decidiu deixar Joomla, aqui está como abordar a migração sem perder sua mente ou suas classificações de SEO.

Passo 1: Auditoria de Conteúdo

Exporte tudo. A estrutura de banco de dados do Joomla é bem documentada, e você pode puxar conteúdo diretamente das tabelas #__content, #__categories, #__menu, e #__users. Não confie nas ferramentas de exportação embutidas do Joomla — elas são limitadas. Escreva queries SQL personalizadas ou use uma ferramenta como a funcionalidade de exportação de dados do Akeeba.

Passo 2: Mapeamento de URL

Este é o passo que todos pulam, e é o que destrói seu SEO. Crie um mapa completo de cada URL em seu site Joomla e sua URL correspondente na nova plataforma. Configure redirecionamentos 301 para cada uma.

# Exemplo: gerando uma lista de URL do banco de dados do Joomla
mysql -u root -p joomla_db -e "
  SELECT CONCAT('/', alias) as url, title
  FROM j_content
  WHERE state = 1
  ORDER BY id;
" > joomla_urls.csv

Passo 3: Escolha Sua Arquitetura Alvo

Decida se você quer outro CMS tradicional ou um setup headless. Se seu site é principalmente orientado por conteúdo (artigos, posts de blog, documentação), um CMS headless com um framework frontend estático-primeiro como Astro vai dar você performance dramaticamente melhor.

Passo 4: Migre em Paralelo

Não tente fazer uma migração big-bang. Configure o novo site ao lado do antigo. Migre conteúdo em lotes. Teste minuciosamente. Apenas mude DNS quando você está confiante de que tudo funciona.

Se você precisa de ajuda no planejamento disso, entre em contato conosco. Desenvolvemos um processo repetível para migrações de CMS que preserva capital de SEO e minimiza downtime. Você também pode verificar nossa página de preços para valores aproximados em projetos de migração.

FAQ

Quando o Joomla 6 vai liberar oficialmente? Joomla 6 está buscando um lançamento estável no final de 2025, seguindo o novo ciclo de lançamento baseado em tempo do projeto. Versões alfa e beta já estão disponíveis para teste. A linha do tempo de lançamento escorregou um par de vezes já, então a data exata permanece fluida.

Minhas extensões Joomla 5 vão funcionar no Joomla 6? A maioria não vai funcionar sem modificações. O sistema de extensões baseado em Composer do Joomla 6 requer novos formatos de manifesto e declarações de namespace atualizadas. Extensões que dependem de APIs depreciadas ou caminhos de instalação antigos vão quebrar. Verifique com cada desenvolvedor de extensão para seu roadmap de compatibilidade Joomla 6 antes de tentar um upgrade.

Posso ficar no Joomla 5 em vez de fazer upgrade? Sim, por enquanto. Joomla 5 receberá atualizações de segurança até aproximadamente 2 anos depois do lançamento estável de Joomla 6, o que significa aproximadamente final de 2027. Depois disso, você está por conta própria. Ficar em uma versão de CMS sem suporte é um risco de segurança significativo, então isso é uma solução temporária no melhor dos casos.

A comunidade Joomla está realmente se dividindo sobre isso? Há tensão real, mas isso não resultou em um fork formal (ainda). Vários membros proeminentes da comunidade publicamente se afastaram de contribuições. A comunidade Joomla suportou conflitos internos antes, mas a combinação de participação de mercado em declínio e decisões técnicas controversas faz este período parecer mais precário do que disputas passadas.

Qual é a forma mais barata de migrar para longe do Joomla? O caminho de migração mais econômico depende da complexidade de seu site. Para sites de conteúdo simples com menos de 100 páginas, uma migração manual para WordPress ou um CMS headless pode ser feita em 20-30 horas. Para sites complexos com extensões personalizadas, espere 80-150+ horas. Usar ferramentas de migração automatizadas como CMS2CMS pode reduzir custos para movimentações de conteúdo diretas, mas não vai manipular funcionalidade personalizada.

Devo esperar o Joomla 6 estabilizar antes de julgá-lo? Isso é um conselho justo para as mudanças de UX — primeiras impressões de novas interfaces são frequentemente mais duras do que a opinião assentada. Mas as mudanças arquiteturais (extensões Composer, modelos Twig) não vão mudar. Essas são decisões de design fundamental. Se essas são suas preocupações, esperar não vai ajudar.

Como Joomla 6 se compara a Drupal 11 para sites empresariais? Drupal 11 é geralmente uma escolha mais forte para sites de nível empresarial com modelos de conteúdo complexos, permissões granulares, e requisitos API-first. Os esforços de modernização do Joomla 6 fecham algumas lacunas, mas o ecossistema do Drupal para casos de uso empresarial (fluxos de trabalho de conteúdo, suporte multilíngue, entrega headless) é mais maduro. Se você já está considerando o esforço de migração, Drupal vale a pena avaliar.

Qual é o melhor CMS headless para substituir Joomla? Depende de sua equipe e requisitos. Para sites de marketing ricos em conteúdo, Sanity ou Contentful emparelhado com Next.js ou Astro são excelentes escolhas. Para sites que precisam de mais estrutura, Strapi ou Payload CMS dão você mais controle sobre seus modelos de conteúdo. A vantagem chave de qualquer abordagem headless é que você está desacoplado da renderização de frontend do CMS — significando que você nunca enfrentará esse tipo de upgrade que quebra modelo novamente.