为什么 Joomla 管理员对 Joomla 6 UX 变更感到愤怒
如果你管理 Joomla 网站已有一段时间，当主要版本发布时，你可能会感到熟悉的不安。Joomla 4 很艰难。Joomla 5 平复了一些问题。但 Joomla 6？它正在成为这个 CMS 历史上最具分裂性的版本。管理面板 UX 被彻底改造，扩展管理器从根本上改变，模板渲染有破坏性变更影响了几乎所有自定义模板，社区对此的反应...不太好。
自 Mambo 时代起，我就一直在构建和维护 Joomla 网站。我已经为客户经历过每一次痛苦的主要版本升级。所以当我说 Joomla 6 感觉不同——而且并非好的方式——我不是在夸大其辞。让我为你详细介绍到底改变了什么，为什么长期使用者感到沮丧，如果你正在考虑跳槽，有哪些现实替代方案存在。
目录
- Joomla 6 管理面板 UX 大修
- 扩展管理器：你所知的一切都错了
- 模板渲染破坏性变更
- 社区反应：论坛、GitHub 和社交媒体
- Joomla 领导层怎么说
- 你应该迁移还是离开？
- 2026 年 Joomla 的现实替代方案
- 实际有效的迁移策略
- 常见问题
Joomla 6 管理面板 UX 大修
让我们从最明显的变更开始：管理面板。Joomla 6 引入了开发团队所称的"现代管理体验"。实际上，这意味着他们移除了自 Joomla 4 以来 Joomla 管理员一直在使用的熟悉的左侧边栏导航，并用顶部导航加上下文感知边栏的方式替代。
实际改变了什么
旧的管理面板有一个可折叠的左侧边栏，带有嵌套菜单项。你最多可以两次点击进入 CMS 的任何部分。它不是很漂亮，但很实用——最关键的是，它是一致的。
Joomla 6 改为水平顶部导航栏，带有下拉超级菜单。左侧边栏现在只在上下文显示，显示与你当前所在部分相关的选项。文章管理、用户管理、扩展配置——它们现在都有不同的边栏布局。
以下是导航模式的比较：
| 操作 | Joomla 5（点击次数） | Joomla 6（点击次数） | 备注 |
|---|---|---|---|
| 创建新文章 | 2 | 2-3 | 取决于当前上下文 |
| 访问全局配置 | 2 | 3 | 隐藏在系统菜单下 |
| 管理扩展 | 2 | 2-4 | 新的分类视图增加步骤 |
| 编辑模板文件 | 3 | 4-5 | 模板编辑器已重新定位 |
| 检查系统信息 | 2 | 3 | 移到子菜单 |
| 管理媒体文件 | 2 | 2 | 大致相同 |
管理员为什么厌恶它
核心抱怨不是说它看起来不同。管理员可以适应视觉变化。问题在于肌肉记忆——让日常 CMS 管理可以容忍的东西——完全被破坏了。
当你管理 15 多个 Joomla 网站，并且全天在它们之间切换时，你依赖于准确知道东西在哪里而无需思考。Joomla 6 强制你重新学习一切。而且上下文感知边栏意味着导航在新系统中甚至不一致。边栏根据你的位置显示不同的项目，这使构建新的肌肉记忆更加困难。
还有可访问性角度。多个社区成员报告了超级菜单下拉菜单在屏幕阅读器上效果不佳，键盘导航不一致。对于以可访问性为傲的开源 CMS 来说，这是一个重大回归。
仪表板小部件问题
Joomla 6 还引入了一个新的仪表板小部件系统，取代了之前的仪表板模块。旧系统让你可以相当灵活地添加和排列仪表板模块。新的小部件系统在视觉上更具吸引力，但配置性明显降低。
你不能再为每个用户组创建自定义仪表板布局——这是许多 Joomla 代理用来为客户创建简化管理体验的功能。相反，有一个单一的仪表板布局，具有对单个小部件的基于角色的可见性切换。这是功能上的倒退，被装扮成设计上的进步。
扩展管理器：你所知的一切都错了
这是事情变得真正痛苦的地方。Joomla 6 引入了完全重写的扩展管理系统，它破坏了扩展打包和安装方式超过十年的兼容性。
新的扩展架构
Joomla 6 改用基于 Composer 的扩展管理系统。从纸面上看，这是个好主意。Composer 是 PHP 依赖管理的标准，使 Joomla 与现代 PHP 实践保持一致是有意义的。
实际上，这意味着：
- 扩展包现在必须包含
composer.json带有适当的命名空间声明 - 旧的 XML 清单格式已弃用（在 6.0 中仍然有效但会抛出警告，计划在 6.2 中移除）
- 扩展发现和安装路径已改变——引用旧路径的自定义安装脚本将损坏
- 更新服务器协议已修订——使用旧更新 XML 格式的扩展需要迁移到新的基于 JSON 的更新清单
// 新的 Joomla 6 扩展清单（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"
}
}
}
扩展兼容性危机
以下是现实世界的影响：Joomla 扩展生态系统的很大一部分还没有准备好。根据截至 2026 年初的 Joomla 扩展目录（JED）数据，大约 40% 列出的扩展还没有更新以支持 Joomla 5 兼容性，更不用说 Joomla 6。
在那些 Joomla 5 兼容的扩展中，早期测试表明约 60-70% 将需要非平凡的修改才能与 Joomla 6 的新扩展架构兼容。我们不是在谈论小的调整。我们是在谈论重组扩展的打包和分发方式。
对于像 Akeeba Backup、RSForm 和 JCE Editor 这样的流行扩展，开发人员已经宣布 Joomla 6 兼容版本正在开发中。但对于由个人开发人员或小团队维护的数千个较小的扩展？其中许多将直接被放弃。
这对网站所有者意味着什么
如果你的 Joomla 网站依赖五个或更多第三方扩展（大多数都有），你需要在考虑升级之前审核每一个。创建一个电子表格。检查每个扩展开发者网站是否有 Joomla 6 公告。如果没有提到 Joomla 6 支持，假设它将无法工作。
我已经对三个客户网站进行了这种审核。其中两个至少有一个关键扩展没有 Joomla 6 路线图。那是一个迁移阻止因素。
模板渲染破坏性变更
Joomla 6 中的模板系统变更是让经验丰富的开发人员退缩的那种事情。Joomla 已从其传统的基于 PHP 的模板覆盖系统转移到引入新模板层的混合方法。
新的模板引擎
Joomla 6 在传统 PHP 覆盖的基础上，引入了 Twig 作为可选（但显然是首选）的模板引擎。核心管理模板现在用 Twig 编写。前端模板可以使用 PHP 或 Twig，但模板覆盖发现系统已更改。
{# Joomla 6 Twig 模板示例 #}
{% 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 %}
什么会损坏
覆盖发现顺序已改变。在 Joomla 5 中，模板覆盖位于 templates/your-template/html/com_content/article/default.php。这在 Joomla 6 中仍然有效，但如果 Twig 版本存在于 templates/your-template/html/com_content/article/default.html.twig，则 Twig 版本优先。
这意味着如果模板开发人员同时提供 PHP 和 Twig 覆盖（许多人会这样做以支持过渡），你的自定义 PHP 覆盖可能会被默默忽略。我已经在 beta 测试中看到这伤害了人们。
此外，模板参数系统已被重新制作。在 templateDetails.xml 中定义的模板参数现在需要在新的 template.config.php 文件中有相应的条目。旧参数仍然加载，但实时预览和可视模板配置器等新功能仅适用于新格式。
对商业模板的影响
JoomlArt、GavickPro 和 Youjoomla 等商业模板提供商处于困难的位置。他们的商业模式依赖于维护跨 Joomla 版本工作的模板框架。Twig 的引入和覆盖优先级的改变意味着他们基本上需要重建他们的模板框架。
有些已宣布他们将完全跳过 Joomla 6 支持，并专注于自己的页面构建器工具或过渡到其他平台。这是一个能说明问题的信号，表明模板社区如何看待这些变更。
社区反应：论坛、GitHub 和社交媒体
社区反应一直很...激烈。而且大多是负面的。
GitHub 问题和拉取请求
Joomla GitHub 仓库看到了标记有 J6 里程碑的问题报告激增。几个高知名度的社区成员已开启详细的问题，记录 UX 回归。一个特别值得注意的主题有超过 200 条评论，辩称新的管理面板更改是在没有充分社区磋商的情况下推进的。
引入新扩展管理器架构的拉取请求在审查期间受到了重大反对，几个长期贡献者投票反对合并。尽管如此它仍被合并，生产领导团队引用了现代化代码库的必要性。
论坛情绪
Joomla 社区论坛和非官方 Joomla subreddit 已被来自沮丧的管理员的帖子淹没。常见的主题包括：
- "为什么要修复未坏的东西？"——管理面板 UX 虽然不完美，但是功能性和熟悉的
- "扩展启示录"——担心基于 Composer 的系统会杀死扩展生态系统
- "谁要求 Twig？"——模板开发人员感到措手不及的感到模板引擎变更
- "迁移路径在哪里？"——缺乏清晰、自动化的现有网站迁移工具
更广泛的背景
这不是在真空中发生的。Joomla 的市场份额一直在稳步下降。根据 2026 年 W3Techs 数据，Joomla 为约 1.5% 具有已知 CMS 的所有网站提供支持，低于 2022 年的 2.6%。WordPress 超过 62%。每个有争议的决定都会加速网站离开该平台的迁移。
社区的挫折感不仅仅关于 Joomla 6。这是多年来感到项目领导层不听实际使用该软件的人们日常需求的积累。Joomla 6 是催化剂，但怨恨一直在酝酿。
Joomla 领导层怎么说
开源事务（OSM）委员会和 Joomla 生产领导层已对批评做出回应，尽管许多人觉得这些回应很不讨人喜欢。
官方立场是这些变更对 Joomla 的长期生存至关重要。基于 Composer 的扩展系统使 Joomla 与现代 PHP 开发实践保持一致。Twig 模板层使该平台对来自其他框架的开发人员更易访问。管理 UX 变更是基于用户研究（尽管研究方法论和样本量受到质疑）。
2026 年初 Joomla 生产部门发布的一篇博客文章承认了过渡痛苦，但辩称短期中断对长期可行性是必要的。该文章将 Joomla 1.5 到 2.5 的过渡进行了比较，这也很痛苦，但最终使该平台向前发展。
这个比较是恰当的，但不是以他们的意图。1.5 到 2.5 的过渡赶走了社区的很大一部分。许多这些用户从未回来。
你应该迁移还是离开？
这是每个人都在问的问题，诚实的答案取决于你的具体情况。
留下来如果...
- 你的网站主要使用核心 Joomla 功能，没有沉重的扩展依赖
- 你的模板基于 Cassiopeia 或致力于 Joomla 6 支持的框架
- 你有内部 PHP 开发人员可以处理迁移工作
- 你的组织出于政治/机构原因致力于 Joomla
离开如果...
- 你的网站依赖于没有 Joomla 6 路线图的扩展
- 你已经对 Joomla 感到沮丧，这是最后一根稻草
- 你需要一个拥有不断增长（而非萎缩）生态系统的平台
- 迁移到另一个 CMS 的成本与升级到 Joomla 6 的成本相当
成本现实
这是人们不经常谈论的事情：从 Joomla 5 迁移到 Joomla 6 的费用可能几乎与迁移到完全不同的 CMS 相同。如果你需要重建模板、更新扩展、重新培训员工并测试所有内容，无论目标平台是什么，你都在看重大的开发小时数。
对于中等复杂度的 Joomla 网站（50-200 篇文章、5-10 个扩展、自定义模板），你可能在迁移工作上花费 40-80 小时才能升级到 Joomla 6。迁移到无头 CMS 设置与现代前端？60-120 小时。间隙不如你认为的那么大，无头方法给你一个具有不断增长的生态系统而不是萎缩的平台。
2026 年 Joomla 的现实替代方案
如果你认真考虑替代方案，这是对选项的诚实评估。
| 平台 | 最适合 | 学习曲线 | 生态系统大小 | 长期轨迹 |
|---|---|---|---|---|
| WordPress | 内容丰富的网站、博客 | 低 | 庞大 | 稳定但 Gutenberg 有争议 |
| 无头 CMS + Next.js | 性能关键的网站、应用 | 中-高 | 快速增长 | 强劲向上 |
| 无头 CMS + Astro | 内容网站、营销网站 | 中 | 增长中 | 强劲向上 |
| Drupal | 企业、政府、复杂数据 | 高 | 大 | 稳定 |
| Craft CMS | 中型内容网站 | 中 | 温和 | 稳定 |
| Statamic | Laravel 商店、内容网站 | 中 | 增长中 | 积极 |
无头 CMS 方法
我在这里有偏见，因为这是我们在 Social Animal 所做的，但无头 CMS 方法解决了重复出现在像 Joomla 这样的传统 CMS 中的根本问题：内容管理与前端渲染的耦合。
当你的 CMS 是无头的时，CMS 中的管理 UX 变更不会破坏你的前端。模板渲染由你的前端框架（Next.js、Astro，等等）处理，而不是 CMS。你的内容通过 API 访问，意味着你永远不会被锁定到单个渲染技术中。
如果你对这种方法感兴趣，我们已经完成了相当多的 Joomla 到无头的迁移。我们的无头 CMS 开发工作与Next.js或Astro前端配对很好，取决于你的需求。
WordPress：明显的选择？
每当有人询问 Joomla 替代方案时，WordPress 是默认建议，这不是错的。生态系统是巨大的，托管选项很丰富，大多数网络开发人员都知道它。
但 WordPress 有自己的 UX 争议（区块编辑器/Gutenberg 传奇镜像了 Joomla 6 发生的一些事情）。而且 WordPress 的市场主导地位使其成为最大的攻击目标。如果你因为治理问题而离开 Joomla，WordPress 的当前 Matt Mullenweg 情况可能也会让你犹豫。
Drupal：高级用户的选择
如果你的 Joomla 网站具有复杂的内容关系、自定义内容类型或企业需求，Drupal 值得考虑。Drupal 11 是稳定的，Drupal 社区比 Joomla 更稳定（如果更小的话）。
缺点：Drupal 的学习曲线陡峭，开发成本通常高于 Joomla 或 WordPress。
实际有效的迁移策略
如果你已决定离开 Joomla，以下是如何不失去理智或 SEO 排名地进行迁移。
第 1 步：内容审计
导出所有内容。Joomla 的数据库结构有充分的文档记录，你可以直接从 #__content、#__categories、#__menu 和 #__users 表中提取内容。不要依赖 Joomla 的内置导出工具——它们是有限的。编写自定义 SQL 查询或使用 Akeeba 的数据导出功能等工具。
第 2 步：URL 映射
这是每个人都跳过的步骤，也是摧毁你 SEO 的一步。为你的 Joomla 网站上的每个 URL 和新平台上的相应 URL 创建完整映射。为每一个设置 301 重定向。
# 示例：从 Joomla 数据库生成 URL 列表
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
第 3 步：选择你的目标架构
决定你是否想要另一个传统 CMS 或无头设置。如果你的网站主要是内容驱动的（文章、博客、文档），一个带有像 Astro 这样的静态优先前端框架的无头 CMS 将为你提供戏剧性更好的性能。
第 4 步：并行迁移
不要尝试做大爆炸迁移。在旧网站旁边设置新网站。分批迁移内容。充分测试。仅当你对一切都有效时才切换 DNS。
如果你需要帮助规划，请联系我们。我们为 CMS 迁移开发了一个可重复的流程，可以保留 SEO 权益并最大限度地减少停机时间。你也可以查看我们的定价页面，了解迁移项目的大概数字。
常见问题
Joomla 6 官方何时发布？ Joomla 6 目标于 2026 年末稳定发布，遵循项目新的基于时间的发布周期。Alpha 和 beta 版本已可供测试。发布时间线已滑动几次，所以确切日期仍然流动。
我的 Joomla 5 扩展会在 Joomla 6 中工作吗？ 大多数不会在没有修改的情况下工作。Joomla 6 基于 Composer 的扩展系统需要新的清单格式和更新的命名空间声明。依赖弃用 API 或旧安装路径的扩展将损坏。在尝试升级之前，检查每个扩展开发者的 Joomla 6 兼容性路线图。
我可以留在 Joomla 5 而不是升级吗？ 是的，现在可以。Joomla 5 将收到安全更新，直到 Joomla 6 稳定版本发布后约 2 年，这意味着大约在 2028 年末。之后，你就靠自己了。使用不受支持的 CMS 版本是一个重大的安全风险，所以这最多是一个暂时的解决方案。
Joomla 社区是否真的因此分裂了？ 有真正的紧张，但还没有导致正式分叉（目前）。几个著名的社区成员已公开退出贡献。Joomla 社区以前经历过内部冲突，但市场份额下降和有争议的技术决定的组合使这个时期感到比过去的争议更危险。
迁移离开 Joomla 的最便宜方式是什么？ 最具成本效益的迁移路径取决于你网站的复杂性。对于少于 100 页的简单内容网站，手动迁移到 WordPress 或无头 CMS 可以在 20-30 小时内完成。对于具有自定义扩展的复杂网站，预计 80-150+ 小时。使用 CMS2CMS 等自动迁移工具可以降低直接内容移动的成本，但不会处理自定义功能。
在判断 Joomla 6 之前我应该等待它稳定下来吗？ 这是关于 UX 变更的公平建议——新接口的第一印象往往比既定的观点更严厉。但架构变更（Composer 扩展、Twig 模板）不会改变。那些是根本的设计决定。如果那些是你的关注，等待不会有帮助。
Joomla 6 与 Drupal 11 在企业网站中的比较如何？ Drupal 11 通常对具有复杂内容模型、粒度权限和 API 优先需求的企业级网站是更强的选择。Drupal 生态系统对企业用例（内容工作流、多语言支持、无头交付）的支持比 Joomla 6 的现代化努力更成熟。如果你已在考虑迁移工作，Drupal 值得评估。
最好的无头 CMS 以替代 Joomla 是什么？ 这取决于你的团队和需求。对于内容丰富的营销网站，Sanity 或 Contentful 与 Next.js 或 Astro 配对是优秀的选择。对于需要更多结构的网站，Strapi 或 Payload CMS 给你对你的内容模型的更多控制。任何无头方法的关键优势是你与 CMS 前端渲染的解耦——意味着你永远不会再面对这种类型的模板破坏性升级。