XF 2.4 XenForo 2.4 status and what's new under the hood?

Where are we?​

XenForo Community PSD Edit (1).webp
TL;DR: We're working hard to release XenForo 2.4 ASAP, but it's taking longer than expected due to scope changes and strategic decisions to wait for certain upstream developments that will benefit the long-term roadmap. Here's an analogy to explain why:

Software development is like planning a cross-country expedition with multiple destinations.

When you set out for version 2.4, you're not just driving to the next town over. You're charting a course through unknown territory with several strategic stops planned along the way - each representing a major milestone or feature release.

But the challenge is the landscape keeps changing along the journey.
  • New roads open up (better technologies emerge)
  • Bridges get washed out (dependencies break or become obsolete)
  • You discover scenic routes that would benefit all future travellers (opportunities for architectural improvements)
  • Weather conditions shift (market demands or user needs evolve)
  • Your vehicle needs unexpected maintenance (technical debt must be addressed)
You can't just focus on reaching the immediate next stop. You must consider how each decision affects the entire journey ahead. Taking a shortcut to reach 2.4 faster might leave you stranded when trying to reach 3.0, 4.0 or even 5.0.

This is why scope changes occur: experienced developers are constantly recalibrating the route based on new information, ensuring the expedition can successfully reach not just the next destination, but all the strategic waypoints that follow.

The delays aren't detours, rather they're course corrections that keep the long-term journey viable.

To be slightly less cryptic, these are some of the specific challenges we have faced along the way:

A new Tiptap version is coming​

When we announced that Tiptap is coming to XenForo 2.4 it was 95% complete, and we then took a bit of a pause to work on other projects, which we have talked about since and will be discussing in this thread. Since then, Tiptap have announced Tiptap V3 which is currently in beta. Given how core the editor is to the forum experience, it makes a lot of sense to ship XenForo 2.4 with Tiptap V3 rather than Tiptap V2 as originally planned. While the changes involved are not too extensive, we also don't want to ship 2.4 with a dependency that is still in beta and subject to change. While we are not planning to wait for Tiptap V3 to be stable, necessarily, we do at least want to give it a little bit more time so we have a higher degree of confidence that we're shipping a stable editing experience.

We started talking about a rewrite (again)​

While this is not currently the direction we've decided to go in, it's responsible for us to at least consider all routes available to us to help us reach our destination.

1749736697928.webp


After nearly 8 years since the release of XenForo 2.0, many of the technologies we use are showing their age, many of the decisions we made have started to slow us down more than we would like, and as a framework, XenForo becomes a less productive framework to work with. The solution to this problem can be to start from scratch, but we have ultimately decided that this is not something we need to do at this stage.

Instead, over the next few versions, including 2.4, we will be attempting to make iterative architectural changes to the framework so that we all have greater tools at our disposal to improve both the developer and user experience, particularly focusing on the implementation of developer tools and features that have become commonplace in other frameworks, such as Laravel.

Some of our best features are simply not finished​

There are one or two features that we see requested consistently from customers in our community forums and feedback channels, and we're excited to confirm they are coming in 2.4! However, it serves no one well if we release such highly-anticipated features before they are ready and before they have the usual level of quality, polish, and extensibility you would expect from a XenForo release. We'd rather take the extra time to get them right than rush them out and disappoint users with a subpar implementation that requires immediate patches or lacks the flexibility for customisation. We'll be sharing exciting details about what these features are and how they work in the coming weeks, so stay tuned!

We can't keep up!​

I just counted and there are about 15 features that have been merged or are pending to be merged into XF 2.4 that we haven't announced yet. Some of these are smaller and aren't worthy of a dedicated HYS of their own (so they'll probably be rolled into a "miscellaneous" HYS or two), and some of these are going to be mentioned below, but while we have been "cooking" (as the kids say these days) it has meant that things like code reviews, and writing HYS posts hasn't been easy to balance. There is also potentially more stuff coming from generous contributions from esteemed developers such as @Xon and @digitalpoint, assuming we have time to implement (otherwise they will wait for... a future version).


With all of that now being said, while 2.4 is taking longer than we wanted, we have been busy and we are very much nearing the end of development.

And, while disappointing (to all of us) it is important to maintain perspective. XenForo 2.2 was released in September 2020. XenForo 2.3 was released nearly four years later. XenForo 2.4 is not 3 more years away.

But, you clicked this to find out what's new, right? So let's go.
 
Last edited:
Once you get through a minor update, ie - v2.3, all the patch updates, ie - v2.3.7, should take minutes. Unless you are modifying core framework files, which is a no no.
 
There is no “lack of updates.” We’ve skipped v2.3 altogether because it would have been too much too soon for us. We will surely be updating to v3.x when it comes out. Yes, we like being entertained, but frequent updates aren’t it!
Exactly why smaller updates are more suitable.

I have been running discourse for quite some time now. Its had multiple framework updates and nothing has broken. Quite literally nothing.

You get deprecation warnings. The addon developers fix it , the warning goes , and the site updates.

Its nothing to do with entertainment, its more to do with a faster cadence of releases
 
Exactly why smaller updates are more suitable.
Updates—smaller or larger—present technical risks that something may stop working as it used to. You’re suggesting making and coping with those risks more frequent. Suitable it is not for us. (The remark about entertainment was a sarcastic response to the sense of impatience in this discussion.)
I have been running discourse for quite some time now. Its had multiple framework updates and nothing has broken. Quite literally nothing.
I am sincerely happy for you; however statistically it is a very small unit of experience. Our XF configurations are rather complex both in terms of add-ons and custom themes, and breakage after updates is common.
 
Updates—smaller or larger—present technical risks that something may stop working as it used to. You’re suggesting making and coping with those risks more frequent. Suitable it is not for us. (The remark about entertainment was a sarcastic response to the sense of impatience in this discussion.)

I am sincerely happy for you; however statistically it is a very small unit of experience. Our XF configurations are rather complex both in terms of add-ons and custom themes, and breakage after updates is common.
I'd rather what they do now, but in each email they send us they tell us their predicted due date when the next one is about to drop.

It should be part of the communication process they have.

It's something that vBulletin do really well when they tell us on their cloud platform that it's about to be upgraded. They also give a predicted time frame for the next one to drop.
 
You’re suggesting making and coping with those risks more frequent. Suitable it is not for us.

You're not required to update immediately when an update is released. Assuming the eventually do go to more frequent, smaller releases, as they've said they will, you can still wait until there are 2-3, or more, features that you like then upgrade them all at once. Then those of us who don't mind doing the testing and upgrades more frequently can, and those of you who prefer not to do it that way can simply wait.

I'd rather what they do now, but in each email they send us they tell us their predicted due date when the next one is about to drop.

It should be part of the communication process they have.

This is a bad idea, as we've seen with the XF devs giving us an estimated time frame for the release of 2.4. How'd that work out?

I'd prefer they just keep hammering away as long as it takes to get it done right, with as few bugs and stability issues as possible. My only recommendation for change would be to communicate the process more, as they've been doing a better job of lately. Let us know how it's going, when there are snags and delays, etc. It would be nice to have some sort of regular communication. For example, we could get a HYS, or a simple post if only just to tell us 1) there isn't much to report but things are still progressing on schedule or 2) we've hit a bit of a snag on one of the new features so we're getting a little behind schedule. Something like this once a week, or once every few weeks, would go a long ways IMO.

But, yeah, giving us an estimated release date when you're not 100% certain you can meet it? No thanks...
 
Updates—smaller or larger—present technical risks that something may stop working as it used to. You’re suggesting making and coping with those risks more frequent. Suitable it is not for us. (The remark about entertainment was a sarcastic response to the sense of impatience in this discussion.)

I am sincerely happy for you; however statistically it is a very small unit of experience. Our XF configurations are rather complex both in terms of add-ons and custom themes, and breakage after updates is common.
I think you are missing the point here.

The updates are minimal. If something major changes in behaviour then a deprecation notice is issues several builds before that element is changed.

Therefore the upgrades are smaller in stature of the upgrade. This is one of my discourse forums. I havent updated it for a few weeks :

1753020151388.webp


I can go into each element and check the change log :

1753020190019.webp


I must stress though that the developers of discourse put warnings out to the addon devs if something major will change and break things but I dont have a screenshot to display that. Its normally just a notice in the admin panel. The devs then fix it and offer an update as well.


Our XF configurations are rather complex both in terms of add-ons and custom themes, and breakage after updates is common.
Well , yes. But that's not standard use case for a majority of people. You can as well in discourse just upgrade the elements you are interested in

Of course, you are not duty bound to upgrade but my experience tells me that if you do smaller segmented updates then things don't break and there are few , if any major gamechangers like in a 1.x --> 2.x or a 2.3 --> 2.4 change. Its gradual evolution rather than a full product lifecycle.

Think evergreem software like O365/Teams/Adobe continuous stream rather than a traditional Office 2016 / 2019 / 2022 model.
 
I think you are missing the point here.
I may, but you also may.
The updates are minimal.
It is not about the updates in and of themselves but how they interact with specific systems. The developers cannot predict the results of this interaction in every single detail. That is why in the world of software we have a zoo of bugs and code adaptations based on user feedback.
You're not required to update immediately when an update is released.
I never do; however the requirement comes when support is dropped for a version that is replaced with a newer one. Smaller yet more frequent updates may lead to shorter cycles of support for major and minor versions. More frequent updates may also require developers to spend additional time preparing and packaging the releases, which does not constitute software development itself. It would in fact slow down the development while creating the illusion of more action, like more bites but less food.

I’d rather rely on the competence of the XF developers to determine the methodology, including release scheduling, that allows them to pursue their job in the best way possible. They are professionals.
 
I’d rather rely on the competence of the XF developers to determine the methodology, including release scheduling, that allows them to pursue their job in the best way possible. They are professionals.

Then you should be happy to know that their stated goal, starting with XF 3.0, is smaller, and more frequent, releases.

After 2.3, we will introduce our new release model, where we will target a single major new feature with each release. That's not to say that other features definitely won't make it because of course they will, but instead of having a big slate of functionality to introduce with each x.y release, we'll get that one major feature done and hit the release button. The intention is that we'll have much more regular feature releases.

The first of those releases will be XenForo 3.0. Right now, the only feature we are definitely pursuing for that release will be the new style and as such, we hope that 3.0 will follow 2.3 in a relatively short time, as it should be effectively 2.3+style. Once 2.3 is out, we'll be getting in touch with major XenForo style producers to help them get ready for the 3.0 style, so that by the time it's ready for release there should be good third party support ready to go.
 
You're not required to update immediately when an update is released. Assuming the eventually do go to more frequent, smaller releases, as they've said they will, you can still wait until there are 2-3, or more, features that you like then upgrade them all at once. Then those of us who don't mind doing the testing and upgrades more frequently can, and those of you who prefer not to do it that way can simply wait.



This is a bad idea, as we've seen with the XF devs giving us an estimated time frame for the release of 2.4. How'd that work out?

I'd prefer they just keep hammering away as long as it takes to get it done right, with as few bugs and stability issues as possible. My only recommendation for change would be to communicate the process more, as they've been doing a better job of lately. Let us know how it's going, when there are snags and delays, etc. It would be nice to have some sort of regular communication. For example, we could get a HYS, or a simple post if only just to tell us 1) there isn't much to report but things are still progressing on schedule or 2) we've hit a bit of a snag on one of the new features so we're getting a little behind schedule. Something like this once a week, or once every few weeks, would go a long ways IMO.

But, yeah, giving us an estimated release date when you're not 100% certain you can meet it? No thanks...
I'd rather upgrade as soon as i possibly can rather than wait a bit.
The only time i won't upgrade is when there are beta versions.
When the upgrade system was changed in version 2, i got some help with it by the OP of this thread.
@Chris D told me that it's better to upgrade your forum than leaving it.
 
I may, but you also may.
Its kinda hard to miss my own point here I made the point that I feel a faster , smaller update will be a better way of doing things.

It is not about the updates in and of themselves but how they interact with specific systems. The developers cannot predict the results of this interaction in every single detail. That is why in the world of software we have a zoo of bugs and code adaptations based on user feedback.
The developers of the addons absolutely CAN predict the results of the interactions. This is why in the case of discourse you can run a beta build and see the effect in action. I am not naive enough to think every single permutation is deliverable on a development test bed, yet if the devs say Y is changing and you recode the element that uses Y and it no longer flags as an issue then thats good enough for me.

As an actual user of discourse I can validate I have found 1 bug, that was fixed within a few hours , released by the team and updated to cure. Not bad going really.

I’d rather rely on the competence of the XF developers to determine the methodology, including release scheduling, that allows them to pursue their job in the best way possible. They are professionals.
No question that they are the professionals in XenForo. However the team are open to suggestions and often adopt them. That makes them professionals who value user input , even if they don't take it on.

I am not criticising the XF team, just giving a perspective of something I would prefer to see.
 
Then you should be happy to know that their stated goal, starting with XF 3.0, is smaller, and more frequent, releases.
I am curious here. The post that you quoted was from Kier ( https://xenforo.com/community/threads/any-sort-of-roadmap-for-xenforo-2-3.201027/post-1637763 ) on July 17, 2023.

Was 2.4 being considered at the point, or was a wholesale jump to 3 going to be the future?

The point I am trying to make is was the statement made by Kier intended for 3 as 2.4 hadnt be realised yet? Are we going to see the smaller more frequent updates sooner now?
 
I am curious here. The post that you quoted was from Kier ( https://xenforo.com/community/threads/any-sort-of-roadmap-for-xenforo-2-3.201027/post-1637763 ) on July 17, 2023.

Was 2.4 being considered at the point, or was a wholesale jump to 3 going to be the future?

The point I am trying to make is was the statement made by Kier intended for 3 as 2.4 hadnt be realised yet? Are we going to see the smaller more frequent updates sooner now?

My understanding, right now, is that XF 3.0 will release shortly after 2.4 but will be, primarily, just a new style. That release should be the first of the new release models that include only a single major feature.
 
The developers of the addons absolutely CAN predict the results of the interactions.
They can predict how their add-ons will interact with the framework, XenForo in this case, but interaction goes far and beyond that. They cannot anticipate how their add-ons will interact with other—possibly custom—add-ons in a specific system. Add to this server configuration, and it takes a lot of ora et labora for it to come together and run. That is why we test things, no matter what benevolent developers may believe and hope to deliver.
 
They can predict how their add-ons will interact with the framework, XenForo in this case, but interaction goes far and beyond that. They cannot anticipate how their add-ons will interact with other—possibly custom—add-ons in a specific system. Add to this server configuration, and it takes a lot of ora et labora for it to come together and run. That is why we test things, no matter what benevolent developers may believe and hope to deliver.
But either methodology - either Xen big released or Discourse more rapid smaller releases will offer any more protection. Both need to be tested, however the rapid nature of the discourse means that if something is missed its patched within hours.
 
[…] if something is missed its patched within hours.
And something else possibly broken! Oops, oversight, regression! If there is a need for a hotfix, the XenForo team issues it within hours, too. Different companies work out different methodologies for releasing updates. The quote from Kier indicates XenForo are rethinking their release model. There is a good chance it will be closer to what you prefer.
 
And something else possibly broken! Oops, oversight, regression! If there is a need for a hotfix, the XenForo team issues it within hours, too.
I don't know about that.
 
Back
Top Bottom