This email address is being protected from spambots. You need JavaScript enabled to view it. and This email address is being protected from spambots. You need JavaScript enabled to view it. are the joint release leads for Joomla 5, now in the planning stage. I managed to ask them both for their ideas and views on the project at the end of a Production meeting. This joint venture is being undertaken by two very experienced developers. 

Niels Braczek

Harald Leithner

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.