Joomla 5 is in the planning, meet the release leads
Harald: Like many other Joomla contributors I started Joomla with Mambo. But for a long time only as a user. A couple of years ago I went to a Joomladay and joined the community. After this event, I got involved in the core really quickly by joining the JSST and later becoming release lead for 3.9.3+ and Production Department Coordinator.
Niels: My entry into the Joomla world was with Mambo 4.6, the immediate predecessor of Joomla 1.0. At that point, I had already been developing software in a wide variety of environments for over 25 years. Mambo was a great tool for quickly and easily creating websites that could be expanded at will. However, some things seemed rather immature (some may remember the $mainframe monster).
I had just started writing my own CMS, which was supposed to be able to use Mambo extensions when the developers rebelled and launched Joomla. What I heard about the plans and ideas for Joomla coincided with my goals, so I decided to join Joomla rather than do my own thing.
Harald and Niels, can you remind me of your involvement with Joomla, have you worked on releases or planning the structure of Joomla before?
Harald: Besides maintaining the 3.9.3+ series for 2 years, I was involved in the Workflow as it is now and many other aspects of J4. But my main workfield is in maintaining the stability of the CMS and framework. Things like preventing backward compatibility breaks, looking at the performance and security, working on the testing infrastructure.
Niels: At the kick-off event for Joomla 4 in Athens I had the opportunity to present my ideas of Joomla as it should be. The core was the decoupling of input and output from processing, so that "content" would not be limited to the web, but all possible channels could be served. In addition, there was the so-called "orthogonal architecture", which was supposed to ensure that certain services such as access control, tags, workflow, etc. would be available to all components without additional code.
Some people were excited about the possibilities this opened up, others vehemently resisted such profound changes. In the end, the decision was it was decided to develop Joomla 4 in small steps and to consider the new concept as a guiding lighthouse project, "Joomla X".
Much of what we had designed for Joomla X has eventually found its way into Joomla 4. However, due to continued resistance to the new architecture, the Joomla X Team became the Software Architecture and Strategy Team (SA&S), shifting the focus from providing conceptual code to advising developers on architecture. Like Joomla X, SA&S is under my leadership.
I would really like to know your visions for J5, what it should contain, what it should not contain, what direction it's going in.
Harald: For the 5.0 version I would like to see a complete cleanup of all functions and behaviours already marked as deprecated. In the lifetime of a software project like Joomla! Features get added and the codebase gets more complex and unmaintainable. With Joomla! 4.0 we got a more future proof architecture update. Also introduced was a b/c layer for Joomla! 3 extensions which is planned to be removed with 5.0. Also, the new event system should completely replace the old one with well-defined events including validation.
For the improvement of the CMS I would like to say PHP 8.1 fiber support by the CMS, so support Revolt or deeper React PHP would be one of the features I like to see in Joomla! 5.0.
On the other hand, I would like to be pragmatic when it comes to backward compatibility and principles that sound good on paper but aren’t compatible with Joomla! For b/c it’s more important to keep it than removing it if no good reason or polyfill could be found.
Niels: At this point in time, I can only talk about my personal ideas, because no final decision has been made about the scope of Joomla 5.
There is no doubt that it is necessary to get rid of old burdens - that is the real purpose of a new major version. If there was full backward compatibility, there would be no need for 5.0, then 4.x would be enough. Therefore, we can also take full advantage of the fascinating possibilities that PHP 8.1 offers.
In software development, there are a number of generally accepted principles that aim to increase the maintainability, extensibility and robustness of the software, the so-called SOLID principles. These principles recommend the strictest possible separation of different concerns and the restriction of dependencies to interfaces. In non-technical terms, this means that any functionality can be added or replaced by a similar or different one without causing problems for the system as a whole. I consider adherence to these principles to be indispensable if Joomla is to be fit for the future.
Plugins are a simple and important way to add new functionality to Joomla. However, each event used to address the plugins uses its own methods to communicate with the rest of the system. I would like to standardise this so that developers know immediately what to do with new events and to enable automation in this area. With the standardisation, for example, an extension is conceivable with which end users can click together their own plugins in a low-code editor.
The installation process needs to be revised so that Joomla and extensions can be easily installed and updated via the command line. Ideally, we use Composer for this, a tool that can resolve dependencies and provide the right packages. This would give extension developers an easy way to include third-party libraries without triggering conflicts. It also allows hosting providers to install Joomla from their control panel. Site builders could describe a complete installation in a single JSON file and set it up with a single CLI command.
The development of Joomla towards a headless CMS should be advanced. By improving the web API and separating CMS and output channels, completely new possibilities open up for site builders. API endpoints and CLI commands should be generated automatically as far as possible. One of the great advantages of this is the possibility of building a page cache, i.e. storing pre-rendered pages that can be served directly by the webserver and load their dynamic content on-demand via API call.
As already mentioned at the beginning, Joomla 5 will naturally not be fully backwards compatible with Joomla 4. Whenever possible, we will offer changes to the architecture already in Joomla 4 as an alternative to the previous one in order to make it forward compatible. Necessary adjustments to Joomla 5 should thus be possible for developers of extensions at an early stage. I would also like to use Rector, a tool that can rebuild programme code in a rule-driven manner, to support developers in making their extensions Joomla 5-capable as early as possible.
These are the most important things I would like to see in Joomla 5. There are also heaps of little things that can be improved or places where only a little is missing to make it a really great feature. However, to list them all here would go beyond the scope of this article.
How are you planning to work together, will you both be working on the same areas or will you be splitting the tasks and if so who will be responsible for which tasks?
Harald: We didn’t talk about how this could work but I think we are completely different characters with different focuses. So I think Niels will try to bring structure into the development cycle and into the code and I will try to bring it to an end. Niels has deep knowledge on architecture and how things can be in a perfect world and that’s really great. I will try to support him with this as much as I can and will do the boring stuff like cleanups coordination.
One of the reasons we have 2 release leads for this version is because we don’t want to spend another 5 years for the next major version. I was already able to push people forward to release Joomla! 4.0 and I’m sure I will be able to catch the timeline of Joomla! 5.0.
On the other side, we are not the only ones alone responsible for the Joomla! 5.0 release, we have the CMS Release Team and the CMS Maintenance Team behind us, so we coordinate with all the other maintainers and keep talking to the Release Team.
Niels: That's a good question! We haven't really discussed talked about that yet.
I have come to know Harald as a pragmatic person who simply solves problems posed to him. In my estimation, his centre is the here and now with a focus on the current problems, but he does not lose sight of the horizon of possibilities. My nature is somewhat different (even if I have to and can force myself to be pragmatic in everyday life). I see the possibilities first and foremost and look for ways to realise them. The current problems would disappear if we already had that.
Therefore, I believe that Harald and I will make a good team. Of course, each of us has his own focus that he wants to or will give priority to. In the end, I think Harald will always bring me back down to earth when I take off again. On the other hand, I will encourage him to go one step further than necessary because it will be beneficial in the long run.
We also want to work more closely with the CMS Release Team than has been the case in the past.
I understand you are interested in hearing from all of us in the community, our ideas and thoughts for J5. What is the best way we can get in contact with you and what would be the time frame for any ideas to be considered?
Harald: The community is the most important source of information for us, so we would really appreciate any feedback, ideas and wishes. We have an RFC process explained by Niels later and of course, we can be contacted directly through the VP or on Glip or any other channel. Depending on the source of the idea it should include all needed information like benefits, reason, challenges, impact and so on. Your timeline is really short, so coming back to us as soon as possible would be appreciated.
Just to mention not only feedback is welcome, but also code contributions are needed. Having ideas is good but bringing someone who can implement it would be really helpful.
Niels: Oh yes, and that is also very important to us. We are so close to the product that we can't always see where there is actually something missing. Joomla is an all-purpose CMS that is designed to meet the needs of as many application scenarios as possible. That's why we place a lot of emphasis on modularity, flexibility and expandability. Special requirements that are only made by certain industries should be reserved for extensions. But everything that helps all CMS users belongs in the core, in my opinion. And that's where we need your input.
Let us know what you think belongs in the core, what you think is missing or what should be changed.
We have established an RFC process for such purposes. There are instructions on how to use the process at https://github.com/joomla/rfc. Don't worry, this looks more complicated than it is at first glance! To start the process, only two things are needed: A summary describing what it's about, and a rationale (Why Bother) for why this is so great and should absolutely be integrated. If you want to use the mailing list for your proposal instead of GitHub, please mark your proposals with [Joomla 5] in the subject line.
We can consider anything that reaches us before February 2023. However, since a certain amount of time is also required for implementation, the sooner the better.
There is a close synergy between the core and extension developers.
Are there any ideas and suggestions that are on the cards to help extension developers?
Harald: Extension developers are an important part of the CMS ecosystem. So we want to give them guidelines for the changes in J5 as soon as possible. Also, we want to make sure that the upgrade for an extension between 4 and 5 is as easy, for example, a j4 extension should be possible to run on j5 without many modifications.
Niels: Essentially, there are two things: First, with the alpha release, we make a version available early on that already contains all the breaking changes. If the developers use this version to point out problems to us, we then still have the possibility to counteract. If they only do this with the release candidate, the ship has already sailed. Second, we want to document the changes with a comparison of old and new, similar to what PHP does in its announcements.
Whether we'll be able to use Rector the way I'd like is unfortunately not yet certain.
Are there any things extension developers can do that will help core? Would more testing at the alpha and beta release help feedback issues and problems to the core?
Harald: Yes! Extension developers often know the CMS better than we do. So help in every way would be really appreciated. For example, start testing as soon as possible or contribute development time would be super nice.
Niels: Definitely! The earlier we get feedback from developers, the better we can take their needs into account. Of course, we would be over the moon if extension developers could provide manpower for development. There is always a lot to do and too few hands.
Joomla 4 was a while in its creation. What is your hope for Joomla 5 and what is the time scale that you feel is realistic and achievable? I see that J4.1 has been tightly controlled so far time-wise, planned to come out 6 months after J4.0, do you think such a rigid and reliable release plan is possible for a major release?
Harald: As already mentioned, that's one of my goals. The long development time of J4 was a big problem for the community and I’m happy that we finally released it on Joomla's birthday. For Joomla! 4 we switched to a 6-month release cycle which means we release a minor version every 6 months. Based on this we plan to release Joomla! 5.0 on 17. August 2023. We will create a release roadmap of all milestones as soon as we start with the development of Joomla! 5.
Niels: There are basically two types of release plans: feature-based or timeboxed. We have a policy decision that imposes timeboxed releases. Therefore, unless the rules of the game change before then, Joomla 5 will be released on 17 August 2023. For us as release leads, this means that we must have completed all architectural changes by the first alpha release. After that, no more changes can be made to the architecture. In parallel, features will be developed, which must be completed when the beta phase begins. From then on, only bugs will be ironed out. Anything not finished by then will have to wait for the next release. Times cannot be given here for the alpha and beta phases, they are not yet fixed. Watch out for the roadmap for details.
Apart from telling you guys what we would like to see in J5, how can we help?
Harald: We take any help we can get. Since Joomla! is a 100% community-driven CMS it needs the engagement of every single community member. So if you have fun in coding, writing documentation, supporting our infrastructure, testing the cms, provide feedback based on the “real world” or just simply want to say thank you everyone is welcome.
Niels: There are always three things missing: Input, feedback and hands. If you feel like helping Joomla and can program, help us with the implementation. If you feel like helping Joomla and can write, help us with the documentation. If you feel like helping Joomla and can communicate, help us get the message out. If you feel like helping Joomla and the above is not for you, contact the Volunteers Engagement Team - they will find a place for you!
Thank you, Harald and Niels.
Please do get in touch with them via their community emails or add your ideas and comments to the GitHub discussions. This is a community project made all the stronger by an active community.
After years of wait running Joomla 3, we are now trying to migrate all sites to Joomla 4; and the extension developers are still figuring out if it is better to migrate the extensions or forget the whole Joomla business.
Now, you start talking about Joomla 5 and a new round of deprecations and refactoring (because you keep moving classes around) for 2023.
Today, there are ONLY:
- 3% sites migrated to Joomla 4 (https://developer.joomla.org/about/stats.html)
- 30% extensions migrated to Joomla 4 (1,789 / 5,928 https://extensions.joomla.org/)
As a consultant and extension developer, I think your strategy is to build a product solely managed by a core team. You are making the CMS aligned with your ideas. You only care about internal architecture and a few more technical concepts. You don't have any interest in organizing an ecosystem of business consultants or extension developers.
I'm still waiting to see where the Joomla market is going. It would be best if you were caring about the same.
That 3% of sites is very bogus. It counts against all the old sites stuck in Joomla 2.5 through 3.8 which are never going to be updated to a new Joomla version (70% of the sites in that graph). It also never removes any sites, even if they haven't pinged the update server in forever. My stats collected against actually active sites each month show that nearly 20% of sites are already on Joomla 4 which is surprising since Joomla 3 is still supported and there were a lot of new sites launched last year developed on J3.
Similar for the extensions. 30% converted to Joomla 4 is a very good sign considering that nearly half of the listed extensions have not been updated in years, are made obsolete by new core features or have been superseded by newer extensions. This number means that virtually all actively maintained extensions are already Joomla 4 compatible. Compare that with Joomla 1.5, 1.6 and 3.0 when most extensions were incompatible with the new CMS version for a year or so.
The real picture of Joomla 4 adoption is actually very positive.
I do agree however that one release every 6 months no matter what is problematic as we have already seen in the 1.6 through 3.2 era. I guess there is some institutional knowledge lost there.
The most annoying problem for me is that this release policy means that ever single year we have a release on August 17th, smack middle the summer vacations for the northern hemisphere. As an extensions developer I need to be on high alert the month before the release (because until the stable is released stuff is changing all the time!) and one month after the release (because the stable does have changes to the last RC, always). This means that I can't go on vacation from mid July to mid September. For anyone with kids this is a no-go: this is the only time of the year our kids are out of school and we can go on vacation. So this year I am going on vacation and put a big fat warning on my site that our software may not work on Joomla 4.2, do not upgrade to 4.2 until October 1st if you value your sanity. Plain and simple.
The Joomla organization presents these numbers. If they care, they should work based on them.
Your numbers are acceptable, but they are based on your user base and experience. It is not the same as what the Joomla represents. You could say that your business is thriving, but Joomla is not reaching new users with Joomla 4. If we can't show a Joomla 4 market growth across the board, then we all lose at the end.
The point is that Joomla's usage stats count ALL Joomla sites which ever made contact with the update server, including sites which no longer exist or are no longer updated. Therefore, the market share of different Joomla versions will appear level given enough time.
As for my stats being biased, no, they are not. Every month I have a sample of half a million active sites. Joomla's stats server reports just under 2.9 million sites (https://developer.joomla.org/stats/cms_version). This is a far larger population coverage than what you get in statistically meaningful election predictions (16.67% vs ~2%). Anyone who understands statistics can tell you that my error representing reality if miniscule.
The fact that the activity you see in the Joomla forum and issue tracker is far closer to the figures I report should give you another anecdotal data point about whose stats are more representative of the objective reality.
The real problem, as I keep saying, is that Joomla's stats DO NOT exclude stale results. This makes no sense for decision making. The version of Joomla, PHP and MySQL someone used 10 years ago is useless for making a decision on the minimum requirement for Joomla 4.1 to be released next month, for example. Likewise, anyone not understanding how that godforesaken graph works would assume that they need to target PHP 5.3 to 5.6 and Joomla 3.6 when, in fact, PHP 5 is no longer supported and cannot even be compiled on any modern Linux distribution, whereas Joomla 3.6 represents less than 0.02% of active Joomla sites in December 2021.
Are you really arguing that Joomla 3.6 and PHP 5 is what real world sites are using TODAY? You can't possibly be so naive. I know you better than to believe that.
I fully agree with you. I've spent the last few years rewriting extensions so that they end up being exactly the same as before - with no new features and no new functions. In joomla 5, the legacy MVC is to be removed, which in turn means rewriting and rewriting. So for a few years I will just rewrite without adding modern or new features or new functions. The technical debt on extensions will be beyond the limit.
This is, of course, demotivating. The developers around me are already done before rewriting to version 4. I personally have no motivation to rewrite things on Joomla 5 (understand unnecessarily removing the legacy MVC and replacing it with a new one). Why? Simply because at the end it will climb the exact same extension as before. But I will only lose 2 years unnecessarily.
Recently, the Joomla project seems very hostile and non-functional to me:
- If you report a bug in the core, you are bullied and chased and you are blamed for not doing PR right away (if you do, it is ignored anyway)
- On the Joomla forum you will insert a link to the documentation so that you can best advise the user and you are marked as a spammer
- If you're trying to say that by removing the legacy MVC, Joomla will lose 90% of its extensions, people don't take it seriously.
- OSM? Is the non-functioning organization still existing?
I'm sorry, but just like the developers around me, I just won't have the motivation to rewrite the extensions for Joomla 5. Just to rewrite something for two years and then see the exact same result - I just lack the motivation for that.
A lot of people will say it's OK, so don't be a few extensions. But it's not OK. I see it around me. People don't find the extensions they need and are leaving Joomla in droves. Because Joomla is of the opinion that extensions are not needed because core is powerful.
Ok, if you think so, you have a right to it. But my statistics speak for themselves. From the popular CMS, we got to the point where people have no idea that Joomla exists.
I have many examples where one function has changed three times in a few years. Internal changes are very frequent and unnecessary. Thanks to the encapsulation, such changes would not be necessary even on the outside. But they are and it demotivates developers to continue creating extensions.
Please show me some brand new bigger extensions that were written specifically for Joomla 4? Maybe it doesn't even exist. The new system has become far too complex and abstract and no longer attracts developers.
Let's face it, we don't attract new developers, and if we go against the existing ones, then the system will simply be forgotten.
Please take my sentences as I write them - relating to technical matters. I personally know the core developers of Joomla, I understand their opinions and decisions, I appreciate their work - I just have a different opinion on the routing of Joomla. Which doesn't mean I don't respect their decision.
Migrating your extensions from legacy MVC (dating back to 2005, first released in 2007 with Joomla 1.5) to Joomla 4 MVC is not that hard. It's very easy. The fact that the MVC remained largely unchanged in 15 years was not a Joomla success, it was a failure of epic proportions: twice the project tried to come up with a better alternative and twice it failed. Remember the New MVC and the New New MVC in Joomla 1.6 and 3.0? No? Exactly. Massive failures. Third time was the charm and we've got the Joomla 4 MVC which is why Joomla 4 is so darned fast!
You still have the same Model-Table-View-Controller architecture using the same methods. If your extensions is legacy core MVC all you need to do is:
* Namespace your code (search and replace)
* Create a boilerplate services.php file
* Adjust your XML manifest
This is the bare minimum.
If you want, you can finally modernise your code base:
* Since classes are namespaced, frontend MVC classes can extend from the backend without having to write the same code twice.
* You can create your own HTMLHelper service and have it magically available whenever you boot your component, even from a plugin or module
* You can inject services instead of magically pulling them from God objects' static methods
Remember that I had to refactor my extensions written in FOF 4 which was even more problematic because on top of all the bare minimum and modernisation steps I also had to rewrite my Controllers, Models, Views and view templates nearly from scratch.
Between March 2021 and December 2021 I have rewritten 10 extensions on top of writing a brand new subscriptions management extension for our site, creating a new Joomla 4 native template for our site, writing all the code to make the migration take place automatically (still in testing, 99% complete), report and fix Joomla bugs (including a brand new backend for Joomla Update), all the regular extension maintenance and support and our toddler starting preschool in September with the all-too-frequent common cold viral infections this entails during a global pandemic. While having ADHD which make concentration a real struggle.
It's not hard. Moreover, you get much more modern code which is more conducive to supporting newer versions of PHP, runs faster and is easier to maintain. There's a net gain from all that.
Hablar de Joomla 5 cuando apenas estamos empezando a migrar desde Joomla 3 es muy apresurado.
Ahora bien, es necesario complementar asuntos importantes en Joomla 4 por ejemplo, terminar de crear documentacion y video tutoriales y que existan mas componentes, modulos y plugins compatibles con J4.
Una cosa que podrian hacer, es dejar la caja de metadescripcion en la misma pestaña donde editamos el articulo, es mejor tener esa caja a la mano y no andar buscando en otras areas.
La idea de Joomla 5 esta bien pero primero hagamos que la gente se entusiasme con Joomla 4 volviendo a ganar cuota de mercado, facilidad de uso y sobretodo, que la administracion del CMS no represente mayor problema a los usuarios, hacerlo facil es garantia de ganar personas para la comunidad.
Would be nice if menu extension works with Bootstrap x. Now Joomla 4 templating is heavily build around Bootstrap but the menu extension is not. It's a real pain in the a** for years now. Already using Joomla for 15+ years but this should be handled.
We already know that using composer for installing joomla is not practical and the fact that you are expecting everyone to rewrite all their code in just 18 months time is showing that you are not living in the real world. It was because of this (and other hard breaks) that your ideas in Athens were rejected and the development of j4 was delayed by 18 months.
Surely we should be learning from the lessons of the past and not repeating them. Other projects are able to do that!!
I was the one who said no to the Joomla X architecture in the J4WG Athens meeting as it was proposed.
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 first 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 end user 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 guarantee 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 in the form they were proposed 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 expand 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.
I have only one dream: I hope planning for J5 will be driven by the marketing people and community needs, not by the developers. Developers need to be the big muscle that create great code.
Joomla has to conquer new audiences (users and 3rd party) and this can only be done by shaping Joomla on what USERS and MARKET really needs.
*MARKET = customers, admin users, web agency (and freelancers), 3rd party developers, search engines, adv e social platforms, integrators.
A lot of good points are raised above. I'd like to echo the sentiment by Anibal (why the rush?) by saying that I have a somewhat long list of clients with sites on J3.9. It will take some effort to get them moved to J4, so the idea of getting left even further behind by a new version is somewhat scary. I see a lot of good thought and careful planning behind J4, which I appreciate. I feel less the need to conquer any particular market, and more the need to continue providing solid and reliable tools that have a long life span.
The above comments are exactly what we need to be able to hear from the community and extension developers, and to understand their needs and wants. This is the planning phase. and planning needs everyone's input.
As long as we focus on the ideas and principles and never the people then I could not be happier and please do add your comments and thoughts and share this article far adn wide.
This is exactly what the articles was for, to get this debate going and seek the views and ideas of a wider audience.
I do hope Nelson does not mind but I thought it might be useful to put a google translation of his comments so that a wider audience who are skimming through can follow what he is saying
Nelson Fernando Bautista Pinzon
Let's work on Joomla 4 first before thinking about Joomla 5
Talking about Joomla 5 when we are just beginning to migrate from Joomla 3 is too hasty.
Now, it is necessary to complement important issues in Joomla 4, for example, finish creating documentation and video tutorials and that there are more components, modules and plugins compatible with J4.
One thing they could do is leave the meta description box in the same tab where we edit the article, it is better to have that box at hand and not search in other areas.
The idea of Joomla 5 is fine but first let's get people excited about Joomla 4 by gaining market share, ease of use and above all, that the administration of the CMS does not represent a major problem for users, making it easy is a guarantee of winning people for the community.
One of the reasons to place a date and make it clear that there are people thinking about 5 is to assure people that the project is very much alive.
There are also teams of people thinking about 4.1, 4.2 4.3
If the release leads think that they need more time then 4.4 and 4.5... the important thing is to set out plans and try to meet them.
It helps the project to gain momentum and its only when you really sit down to do the work do you get a good idea of how long it takes and what will be involved.
I am excited that the thought is being put in this far out and that its being done openly with the intention to get the thought's and ideas of the community. Its only by putting these flags in the sand that the thoughts and opinions come forward. I personally dont think its too soon to think about it. It may be too ambitions for a final delivery date but the answer to that is only going to come out if we are working through the issues.
And a valid answer for the community can be that we add a few more releases before 5, but without making the suggestions its difficult to get peoples opinions.
Phil, I'm sorry but the organization does nothing based on user feedback.
It only matters what a few people commit on GitHub.
There is a total disconnection between the product and users. The proof is that in every product transition, you only lose users.
You don't only lose regular users; you also lose the faith of the volunteers that try to collaborate with the project. The fundamental problem is that nobody likes to be ignored.
I am also surprised that we are already talking about joomla 5 ... but finally it is only a number!! but duration between joomla 3 and joomla 4 has produced, in my opinion, more problems than anything else
The most important thing is to avoid the problem of technological disruption that happened at the beginning of Joomla. Apart from some cases of incompatible themes/extensions, I managed several migrations without loss joomal 3 -> joomla 4
Thanks to the developers
The migration help tool is fundamental and should certainly be improved!
Many distributions or software adopt versions with some "technological break" every 2 years and minor versions every 6 months.
In form, the regularity is reassuring for everyone.
Some devs are strict in supporting their extensions with versions of joomla. Others are very lax in still supporting joomla 1.5! Perhaps a happy medium by reassuring, but insisting on the need to migrate to joomla 4 if his site is more than 5 years old?
In my opinion, it is not for users or developers to have the leadership. A global cms without developers OR without users dies quickly. Respect and benevolence are an additional guarantee for the durability of a community project.
I dream of a big consultation of users for fundamental needs (distribute 20 points on all proposals, like uservoice)
Very nice but in the article we only read about the technical aspects. I can't see anything for end users here.
I see one more break compatibility between version 4 and 5
Deal developers and strategy / planning new Joomla 5 ... NO no more break compatibility! Next Joomla must be backward compatibility. End and period!
It is impossible to run a business where every two years I will not be sure that the developer will update his extension, the plug I rely on.
Sorry but nobody.. nobody asks users what they need in the new version. (for now )
- core joomla 4 not support open graph - really social media is everywhere... You have to rely on a plugin .. and if someone does not update it to version 5?
I have the impression that Technologically Joomla wants to be Top of Top (this good) but she has forgotten who uses this CMS and what it is used for.
I have been tracking the Joomla market since mambo times. Every new versions shrink market. No market -> no people. No people -> no developers. No developers -> No money. No money -> No cms.
Sometimes I see that there are people on Github who propose a good solution, but the developers kill these ideas because they don't like them.
Idea for improve.
- Download online extensions (Checking compliance with the version and subversion.)
- Better UX for SEO meta etc.
- Better UX for multilang translations.
- Login via social-media / mail
- Restore open graph and expand it to meet the requirements of other platforms.
- Maintenance backward compatibility at last 5-6y.
- Template should, will be run a cross several major version. (So that the created website could survive 10 years with core Joomla updates.)
- Ensuring that the big third companies like SAAS would like to write extensions/plugins/integrations for Joomla! (marketing team make a deal advert, sponsorship, article about company, advert on social media etc.).
I also think it's time to change your approach a bit and start rewarding ($$) people who develop joomla and they spend time creating documentation or marketing. You have to develop a system that will encourage people to contribute. Something like an annual award for category xyz and some money $$$ Voting people from staff and users. (MVP)
The same should be the remuneration system for people who find security issue. A little award for finders.
Here you have a revolutionary idea, fully support Joomla 4 and Joomla 3 until J3 reaches the end of life, and then you can move the development efforts to Joomla 5.
As an exercise, Production could help the organization to migrate the sites to Joomla 4 in the best possible way to showcase Joomla 4.
It's good that some folks start thinking about Joomla 5 right now, I don't see that as a problem in itself.
However I'm concerned that once again the focus seems to be on matters that I don't think are important to actual Joomla users.
So I'd love to see the focus move off the PHP internals, the framework - which I believe is vastly enough for anything anyone would want to do with Joomla and:
- stay 100% backward compatible PHP-wise for the foreseeable future, even across main versions release
- focus entirely on the admin, and user experience in general, bringing it more in line with modern user interface and experience that most people are used to in their daily life.
Joomla 4 interface was a nice visual refresh but it still is the same old full-page reload experience and as such is not exactly on par with what people use daily so there's a lot of room for improvements here, improvement that should bring value to the project's users.
As a side and more technical note, it'd be really interesting to allow the Joomla API application to share sessions with admin or frontend, so that the API can be used with regular user credentials, and therefore benefit from Joomla native ACL. Currently, this is a strong limitation of the API.