在运行了多年的Joomla 3之后，我们现在正试图将所有网站迁移到Joomla 4；而扩展开发者仍在考虑是迁移扩展还是放弃整个Joomla业务。现在，你开始谈论Joomla 5和2023年的一轮新的弃用和重构（因为你总是移动类）。今天，只有：- 3%的网站迁移到Joomla 4 (https://developer.joomla.net.cn/about/stats.html)- 30%的扩展迁移到Joomla 4 (1,789 / 5,928 https://extensions.joomla.net.cn/) 作为一名顾问和扩展开发者，我认为您的策略是构建一个完全由核心团队管理的产品。您正在使CMS与您的想法保持一致。您只关心内部架构和少数更多的技术概念。您对组织商业顾问或扩展开发者生态系统没有兴趣。我还在等待看到Joomla市场将走向何方。如果您也在乎这一点，那就最好了。

亲切问候。当我们刚开始从Joomla 3迁移时，谈论Joomla 5显然是过于仓促的。现在，我们需要补充Joomla 4中的重要事项，例如，完成文档和视频教程的创建，并确保有更多与J4兼容的组件、模块和插件。你们可以做的事情之一，是将元描述框留在编辑文章的同一选项卡中，这样更方便，不必在其他区域中寻找。Joomla 5的想法不错，但首先让我们让人们对Joomla 4感到兴奋，重新赢得市场份额，使用简便，尤其是，确保CMS的管理不会给用户带来太大问题，使其变得简单是吸引社区成员的保证。

如果菜单扩展能与Bootstrap x协同工作那将很棒。现在Joomla 4的模板设计大量基于Bootstrap，但菜单扩展不是。这已经困扰了我们多年。已经使用Joomla 15+年，但这个问题应该得到解决。

我们已经知道使用composer安装Joomla不切实际，而且你们期望大家只在18个月内重写所有代码，这表明你们没有生活在现实世界中。正是因为这个（以及其他硬性中断），你们在雅典的想法被拒绝，j4的开发被推迟了18个月。我们当然应该从过去的教训中学习，而不是重蹈覆辙。其他项目能够做到这一点！！

I was the one who said no to the Joomla X architecture in the J4WG Athens meeting [i]as it was proposed[/i]. I had argued that the proposed architecture would make it impossible for any 3PD extension to be reasonably converted, essentially creating a new CMS with zero extensions which would force site integrators and extension developers to leave for other, established CMS. Moreover, it would make it unmanageable for end users. I'll come back to that later. We debated that for half of Saturday, then we did a SWOT analysis that all of us participated in. The SWOT analysis concluded that the proposed architecture, as it was proposed, would indeed be disastrous to the Joomla CMS. Come Sunday morning imagine my surprise to hear that the results of the SWOT analysis would be discarded and what was then to be Joomla 4 would continue regardless with the new proposed architecture. That's the exact moment where I quit the J4WG and that is the reason why I quit. That architecture eventually went nowhere, it was relegated to Joomla X — meant to create a second CMS under the OSM umbrella — and the salvageable parts were the basis for developing Joomla 4 as we know it. This little kerfuffle cost us 2 years we didn't really have and we're still reeling from the effects of that delay. Regarding the orthogonal architecture, you might remember from the [b]first[/b] J4WG meeting in Denmark — one I attended burning off my last cash in my wallet since my credit card was unusable due to capital controls in Greece at the time — I was all for the orthogonal architecture, once you and Herman explained it. I was and still am sceptical on the assertion that an [i]end user[/i] can compose behaviors in a low code environment. As a testament to the fact that you had and still have my buy-in to the orthogonal architecture you may look at the first commits towards Joomla 4 made by yours truly, working on Events integration in Joomla 4 and converting the tags and history management into orthogonal plugins, stuff that's in the currently released Joomla 4. As to why I was against yours and Herman's proposed architecture, I had said it because of the way three points were proposed. Using an ORM for managing schema installation and updates. Updates would only work if you can [i]guarantee[/i] that the actual schema precisely matches the previous version. This is perfectly feasible in a lab environment but absolutely impossible on a real world site which may have been transferred between servers, may have failed updates applied to it etc. That's the reason of existence for the Database Fix feature! Using an ORM to handle updates would make it impossible to handle these inconsistencies in any manner that an actual end user could possibly manage. We could use an ORM to handle queries but as I had said, this comes with a major performance cost. Middleware — what you said here as separating content creation and presentation. As I had told you and Herman back in 2015, in theory that's great BUT in practice that won't work with mass distributed extensions getting into each other's way. Middleware as proposed in a pure form works when you have absolute control of the application and can guarantee the order of execution. When you have end users mix and match code there's no good way to guarantee that. Composer for extensions. Back in 2015 I had predicted that this would lead to dependency hell. If extension A requires Library X version 1 and extension B requires Library X version 2 they are mutually incompatible — even if both extensions are components, guaranteed to never run in the same execution context at the same time! Since Joomla's 3PD ecosystem is a mass distributed code environment managed by end users, not developers, there would be no way to address that. The way this is being addressed by 3PDs right now is private vendor folders and / or changing the namespaces of the dependencies they pull in. I had also proposed practical solutions for these problems over the following years: Database Schema: use a solution which applies SQL queries conditionally, the conditions essentially querying the current state of the schema. I was using that in FOF 3 and 4 between 2015 and 2021 with great success. It's been hell trying to use Joomla's dumb extensions updater because real world sites don't tend to have a schema conforming to the stated version. Anyway, this is probably a moot point since I saw no mention of an ORM anywhere. As for using an Active Record ORM, George has forked my FOF 3 & 4 code and worked on it but it's kinda left stagnant and not part of Joomla 4. It can be shaped up and used in Joomla 5. Middleware: Moving to Events and adding plenty of Events throughout the application's request lifetime would allow us to use Joomla plugins to implement middleware, the order of which can be managed with the GUI. I believe that this is the same conclusion Harald came to since he's a pragmatist. Dependencies: I had proposed that the extension manifest itself has a section defining its requirements (and possibly where to download them from), as in: which other Joomla extensions it requires to operate. This would solve the major problem of a 3PD having to ship a common library package with all their extensions and trying to make sure that a. it won't overwrite a newer version and b. can't be uninstalled before the last extension using it is uninstalled. You were thinking about it at a low level (Composer), I was thinking about it at a practical level (extensions). As for Events, you must have already seen my PR https://github.com/joomla/joomla-cms/pull/36578 where I not only agree that each type of Event should have its own self documenting class but I started working on converting Joomla 4's core events to that format, including code for a helper to automate the migration process for developers. I fully intend on helping working on that. I believe in Events replacing legacy plugin handling. Reading between the lines in this article, you see to think that I say no just for no's sake or because I don't ‘get’ the features you propose. This is not true. I am saying no [i]in the form they were proposed[/i] because they are incompatible with 3PD extensions continuity and unmanageable by end users. They can be tweaked and made into something pragmatic. I fully believe that Joomla's future is not trying to supplant Laravel, Symfony or even framework–disguised–as–CMS solutions like Drupal. Neither is trying to supplant WordPress, Wix and SquareSpace. Joomla has a unique identity and target audience, distinct from these products. It is possible to [i]expand[/i] Joomla towards both directions without losing its identity and target audience. In most likelihood, we are both wrong in the direction we should head. The truth is probably somewhere in the middle. For this reason I am happy that Harald is co-lead for Joomla 5. He's both a visionary and a pragmatist.

我只有一个梦想：我希望 J5 的规划将由市场营销人员和社区需求驱动，而不是开发者。开发者需要成为创造优秀代码的强大力量。Joomla 必须征服新的受众（用户和第三方），这只能通过根据用户和市场的真正需求塑造 Joomla 来实现。*MARKET = 客户、管理员用户、网络机构（和自由职业者）、第三方开发者、搜索引擎、广告和社交平台、集成商。

上面提出了很多很好的观点。我想和Anibal（为什么这么急？）的观点产生共鸣，我有一份相当长的客户名单，他们的网站都在J3.9上。将他们迁移到J4需要一些努力，因此，被新版本进一步抛在后面的想法有些令人害怕。我看到了J4背后的很多良好思考和周密规划，我对此表示赞赏。我感到不需要征服任何特定的市场，更需要继续提供具有长寿命的稳定和可靠的工具。

上述评论正是我们需要从社区和扩展开发者那里听到的内容，以及了解他们的需求和期望。这是规划阶段。规划需要每个人的参与。只要我们专注于理念和原则，而不是人，我就非常高兴，请务必添加您的评论和想法，并将这篇文章广泛传播。这正是文章的目的，就是引发辩论，并寻求更广泛受众的观点和想法。

我真心希望Nelson不会介意，但我认为将他的评论翻译成谷歌翻译可能会很有用，以便更多浏览的人能够理解他在说什么。Nelson Fernando Bautista Pinzon [b]先专注于Joomla 4，然后再考虑Joomla 5[/b] 真诚的问候。当我们刚开始从Joomla 3迁移时，就谈论Joomla 5太仓促了。现在，有必要补充Joomla 4中的重要问题，例如，完成文档和视频教程的创建，以及有更多与J4兼容的组件、模块和插件。他们可以做的事情之一是将元描述框留在我们编辑文章的同一选项卡中，这样更方便，不必在其他区域搜索。Joomla 5的想法很好，但首先让我们通过扩大市场份额、易用性以及最重要的是，让CMS的管理不会成为用户的主要问题，使其变得容易，这是赢得社区支持的关键。

将日期放在这里并明确表示有人在考虑5，其中一个原因是为了让人们对项目充满信心。还有团队正在考虑4.1、4.2和4.3。如果发布负责人认为需要更多时间，那么就是4.4和4.5...重要的是要制定计划并尽力实现。这有助于项目获得动力，只有真正坐下来工作，你才能对所需时间以及涉及的方面有一个很好的了解。我很高兴看到人们已经考虑到这一点，并且是公开进行的，目的是获取社区的想法和意见。只有将这些旗帜插在沙子上，才能让人们提出想法和意见。我个人认为，现在考虑还为时尚早。这可能是最终交付日期过于雄心勃勃，但只有我们在处理问题时，答案才会出现。对社区的一个有效回答可能是，在5之前增加几版，但没有提出建议，很难得到人们的意见。

嗨，我也很惊讶，我们已经在谈论 Joomla 5 了... [b]但最终它只是一个数字[/b]！！ :) 但在我看来，Joomla 3 和 Joomla 4 之间的时间跨度产生了比其他任何东西都多的问题 :( 最重要的是要避免 Joomla 开发初期的技术断裂问题。除了某些不兼容的主题/扩展的情况外，我成功进行了多次迁移，没有在 Joomla 3 -> Joomla 4 中丢失数据 :) 感谢开发者们 :) 迁移帮助工具是基础性的，肯定应该得到改进！ [b]许多发行版或软件每两年采用一些“技术断裂”的版本，每六个月采用小版本。[/b] 形式上，这种规律对每个人都很有保障。一些开发者在支持他们的扩展时对 Joomla 版本的要求很严格。而另一些人对仍然支持 Joomla 1.5 的态度非常宽松！也许找到一个令人欣慰的折中方案，但坚持如果网站超过 5 年就需要迁移到 Joomla 4？ 在我看来，[b]用户或开发者都不应该成为领导者。没有开发者或没有用户的全球 CMS 会迅速消亡。[/b] 尊重和仁慈是社区项目持久性的额外保证。我梦想一个 [b]为基本需求进行的用户咨询（对所有提案分配 20 分[/b]，就像 uservoice 一样） 致敬

你好。非常好，但在这篇文章中，我们只看到了[粗体]技术方面[/粗体]。这里没有为最终用户提供任何内容。我看到4.0版本和5.0版本之间有一个不兼容的问题:( 商业开发者以及规划新的Joomla 5...[粗体]不，不再有不兼容问题![/粗体]下一个Joomla版本必须是向后兼容的。结束！不可能在每两年我都不能确定开发者会更新他的扩展，我依赖的插件。抱歉，没有人...没有人询问用户在新版本中需要什么。（现在：D）- 核心Joomla 4不支持Open Graph - 真正的社交媒体无处不在...你必须依赖于一个插件...如果有人不更新到5.0版本呢？我觉得技术上Joomla想要成为[粗体]最顶尖的[/粗体]（这很好），但她忘记了谁在使用这个CMS以及它是用来做什么的。我从mambo时代开始跟踪Joomla市场。每个新版本都缩小了市场。没有市场 -> 没有人。没有人 -> 没有开发者。没有开发者 -> 没有钱。没有钱 -> 没有CMS。有时我看到GitHub上有的人提出了一个好的解决方案，但开发者因为不喜欢它们而否决了这些想法。改进的想法。- 在线下载扩展（检查与版本和子版本的兼容性。）- 更好的UX用于SEO元数据等。- 更好的UX用于多语言翻译。- 通过社交媒体/邮件登录 - 恢复Open Graph并扩展以满足其他平台的需求。- 至少5-6年的向后兼容性维护。- 模板应在几个主要版本中运行。（这样创建的网站才能在核心Joomla更新中存活10年。）- 确保大型第三方公司（如SAAS）愿意为Joomla编写扩展/插件/集成！（营销团队进行广告、赞助、关于公司的文章、社交媒体广告等。）我也认为现在是时候改变一下你的方法，并开始奖励那些开发Joomla的人，他们花费时间创建文档或进行营销。你必须开发一个将鼓励人们做出贡献的系统。比如为xyz类别的年度奖项和一些金钱$$$ 由工作人员和用户投票。（MVP）同样，对于发现安全问题的人也应该有奖励制度。找出来的人应该得到小小的奖励。祝好。

这里有一个革命性的想法，[粗体]完全支持Joomla 4和Joomla 3[/粗体]，直到J3达到生命周期的终点，然后你可以将开发精力转移到Joomla 5。作为一个练习，[粗体]生产部门[/粗体]可以帮助组织以最佳方式将站点迁移到Joomla 4，以展示Joomla 4的优势。

大家好，很高兴有些人现在就开始考虑Joomla 5了，我认为这本身并不是问题。然而，我担心的是，这次的重点似乎又一次集中在我认为对实际Joomla用户不那么重要的事情上。所以我希望看到重点从PHP内部，框架（我认为这对于任何人想要在Joomla上做的事情都足够了）转移到：- 在可预见的未来，即使在主要版本发布时，也能保持100%与PHP的向后兼容性- 完全专注于后台，以及整体用户体验，使其更符合大多数人日常生活中的现代用户界面和体验。虽然Joomla 4的界面进行了视觉上的刷新，但它仍然采用相同的旧式完整页面刷新体验，因此与人们日常使用的内容不完全一致，因此这里有很大的改进空间，这些改进应该会给项目的用户带来价值。作为一个额外的且更技术性的注意点，允许Joomla API应用与后台或前端共享会话将非常有趣，这样API就可以使用常规用户凭据，因此可以受益于Joomla本地的ACL。目前，这是API的一个严重限制。最好的问候 Yannick