The progress on 2.0 is very consistent, thanks to the NLnet and ngi zero entrust fund, which is guaranteeing the time invested by both @IanM and @SychO is paid for.

2.0 will bring many improvements to Flarum, the code splitting feature for instance will guarantee a reduced hit to performance the more extensions you install. I am more than excited that this feature has finally made it into Flarum.

Another thing we're trying to tackle is to have Flarum adopt more of the internals of Laravel. Reducing our distance from this amazing framework is not easy, as Flarum was initially designed to be lean and simple, using the smallest libraries and packages possible. But closing this gap will definitely boost adoption, as Laravel developers will find it easier to start developing for Flarum.

All these improvements are massive changes to how Flarum behaved in 1.x. And as a consequence it is more than likely that a majority - if not all - extensions compatible with 1.x are going to break for 2.0. I am sure you understand we aren't too happy about this either, but to innovate and to improve, we have to make sacrifices. In the past, during the 1.0 release, we raised a fund to pay developers who assisted in upgrading the most used extensions under the Friends of Flarum (see https://opencollective.com/flarum/projects/fof-v1). Rest assured that a similar fundraiser will be held for the 2.0 release.

    when will v2.0 be ready? I look forward to update it soon

      luceos And as a consequence it is more than likely that a majority - if not all - extensions compatible with 1.x are going to break for 2.0.

      Thank you for alerting us. I'll probably wait until all the extensions are compatible before migrating to 2.0.

        A security issue was reported a few months back, the issue had been fixed in version 1.8.0, and an advisory was meant to be published to the dependency where the issue lies, but as the package seems to not be maintained anymore, we have now published an advisory on our end: https://github.com/flarum/framework/security/advisories/GHSA-67c6-q4j4-hccg.

        So if you are still on Flarum 1.7 and less, please update to 1.8 where the vulnerability was patched.

        12 days later

        Any thoughts on the possibility of running Flarum 1x and upcoming 2x from the same data store/API/backend please?

          Prcek what's your use case? Flarum 1.x will go out of support once 2.x releases so you will need to update. You'll have plenty of time to plan the update once the release date and upgrade guides are anounced

          EDIT: just to be clear, the exact support policy has not been confirmed yet by the Flarum team. I expect there will be a short overlap period where we continue supporting 1.x with security updates while developers get their extensions working with 2.x

              Lumeinshin i totally agree with you that the best thing about using flarum software is the extensions that take off the heavy load and add power to the forum , i suggest at least a tool to use the extensions without breaking the code on flarum upgrades in the future.

                clarkwinkelmann … while developers get their extensions working with 2.x

                That's exactly the case. Don't freeze on the previous version because some developers won't rush to upgrade the extension. No one wants to experience phpBB-upgrading hell again 😄

                  4 days later

                  Have we all forgotten about Vbulletin, XenForo, etc? 🙂

                  It is completely natural for forum software, and software in general, to undergo evolutionary changes. Things break because the framework needs to evolve, just like nature and the animal kingdom adapt over time. The beauty of open source lies in the fact that any aspiring or skilled developer can step in when needed, as long as the original author included a license that allows for such freedom.

                  Recently, there was a discussion in the XenForo community forum about users still running on older and severely deprecated PHP versions. What did XenForo do in response? They simply added a warning message to their application, encouraging users to upgrade to the latest stable version of PHP when possible, without forcing them to make hasty changes. It's the responsibility of extension developers to update their extensions in a reasonable timeframe, granted of course, that the developers are still maintaining their code. It's perfectly normal to stick with a specific version of Flarum until your favorite extensions catch up. There's no need to rush when a new breaking version is released; it's wise to allow time for major bugs to be addressed and fixed. The key here is to be patient and offer help in any way you can, whether through a simple pull request to update an extension's breaking changes or by providing guidance on how to fix these issues as quickly as possible.

                  I've learned from my own experience that patience is indeed a virtue. While it might be daunting to face another phase of breaking changes, remember that the team behind Flarum aren't intentionally introducing these changes to annoy or cause anxiety. They are striving to improve the software for everyone's benefit. We're all in this together, and showing understanding and empathy can go a long way in making this process smoother and more enjoyable for all of us. 😊

                  It's been a month since our last update on the 2.0 development progress, with a slight hiatus during the holiday season.

                  Over the past few weeks (from weeks 11 to 14), we've been exploring the possibility of making our codebase more reliant on Laravel to improve developer adoption, that is still under discussion.

                  We've also been hard at work enhancing the customization and extensibility of the frontend, which is an ongoing effort. To put these changes to the test and identify any necessary improvements, I'm planning to create a proof of concept theme to try the flexibility of these updates.

                  On another front, @IanM has been working on email unsubscribe links and revamping the outgoing email format. This enhancement will give users the option to choose between plain text emails, HTML emails, or multipart emails.

                  All in all, we're making excellent progress, and we look forward to sharing more updates soon!

                  12 days later

                  Please seriously consider, even if just as an academic exercise, how to issue a crypto token to fund and sustain Flarum. The world needs an alternative to Discourse and acceleration of Flarum is a potential solution.
                  Take the risk and explore how it would work.

                    the flarum biggest challenges are the full SSH control requests to run the software my community leadership is been called by server supervisors that flarum is a high security risk and they will void any guarantee services if we still insist on running flarum even in a subdomain configuration this issue must be addressed.

                      maged_qwani can you share an article that would describe those security risks in more details ?

                      Composer, client-line commands, CRON tasks and queues are all industry standard. Flarum does not do anything more dangerous than a framework like Laravel.

                      Flarum does not SSH into the server itself, the sysadmin does. Security of the SSH access lies solely with the sysadmin. If you SSH as the webserver user this makes no difference compared to not having SSH since this is the same shell user Flarum would already be running as under the webserver. Some hosts offer jailed/restricted SSH access if they don't want shell users to do anything unrelated to the webserver, and Flarum should be compatible with many of these as well.

                      If you discovered a vulnerability, please see our website for the way to responsibly disclose the details to us so we can address it.

                          maged_qwani A deployment of Flarum can be done in a complete containerized environment. While not cloud native / declarative, Flarum configuration and maintenance can be handled without SSH if you use something like:

                          kubectl exec -it php-cli-flarum -- /bin/sh