Wlork

luceos Upgrading stale dependencies, like Laravel and Mithril;
Moving from Less to Sass in compiling stylesheets;
Support for search drivers in the backend;
Improvements to search in the frontend (ux/ui);
GDPR compliance;
Code splitting of auto-generated javascript files;
Tests for the frontend;
Theme design improvements;
Database drivers, like Postgres;
Plugin manager;
Improvements to the JSONAPI;
Security audit;
Accessibility audit;
Federation;
Automating community extension upgrades;
Email unsubscribing.

We just sent an email to all users using Twitter Oauth here on discuss. We have disabled this integration because it hasn't been working properly. Due to some changes in the Twitter organization things haven't been very reliable for a while related to this integration. If you are affected, you will have received this email. Access to your account can be regained by resetting your password through "password forgotten".

We just released v1.8.1 which patches a few light issues reported.

composer update flarum/core
php flarum migrate

We just had our first meeting in the Flarum virtual office!

We are kicking off development for 2.0 by upgrading PHP to a minimum of 8.1, we will update the codebase as such, with phpstan as well.

Next, we will move to upgrade dependencies such as Laravel and mithril.

image

We will try to post updates here as much as we can as development proceeds.

8 days later

For some reason the queue here on discuss misbehaved. This caused notifications to pause since the 27th. The queue has been restarted and is processing open tasks, this can cause the index to pop up changes that are no longer new and send you emails about older discussions.
My apologies for this.

Will Flarum 2.0 support Laravel Octane? The speed of the Laravel App seems to be optimized under Octane.

    Burial0268 it's not part of the roadmap, so whether it can run on octane needs to be tested by then. If someone from the community would like to run point on octane compatibility by running tests with nightlies and release candidates, we can look at compatibility only if this doesn't take a lot of time.

      luceos Understand how difficult it is for the Flarum team to develop, and I thank you for your patience, and I hope Flarum 2.0 will get better and better!

      Hello 👋,

      This is Week 2 of 2.0 development. We have successfully upgraded the codebase to a minimum of PHP 8.1. This upgrade includes the implementation of stronger typing throughout the codebase. (flarum/framework3827)

      Right now @IanM is currently finalizing the upgrade of Laravel, Symfony, and other crucial backend dependencies.(flarum/framework3830)

      There is also a PR that upgrades the frontend library we use, mithril from 2.0 to 2.2 (flarum/framework3831)

      Our focus for the upcoming week will be on increasing the static code analysis level (phpstan). This will further enhance our bug prevention efforts and ensure a more robust development process.

      By implementing these updates and housekeeping changes, we are establishing a solid foundation for tackling the upcoming tasks for 2.0. These improvements will greatly contribute to a smoother development experience.

      Until next week!

        8 days later

        For 2.0 are there plans to build some of the extensions into the core install? Though extensions are one of the biggest benefits to Flarum, it does feel like some should be part of the core experience. I get paranoid that we will rely heavily on an extension and the author of it stops supporting it, especially as Flarum pushes out big updates that may break them more often. It's a problem we have had with Invision Community in the past.

        Just curious. Looking forward to it nonetheless!

          Week 3 🚀,

          Spent this week's time looking into the first step toward having code splitting in the frontend JS, which is what we are calling the Export Registry. It will serve as an internal API that will give us control over how to load the JS components, and therefore allow us to lazy load some of them as part of code splitting while still allowing extending these lazy-loaded components.

          Code splitting will decrease the initially loaded bundle size and lazy load additional modules as the user browses the forum.

          Reference: flarum/framework3833

            Circa do you mean adopting third-party extensions as first-party extensions? not at this time, however, FoF extensions are already (and have always been) maintained by core developers.

              SychO This is one of the things I'm most excited about, I remember there was talk of this a long time ago, I think the final betas... so it's great to know it's going to be included in 2.0, I'm very curious to see how this may impact flarum js size/general performance, it will certainly give new life to +70 extension setups by having less of a penalty for excessive js size.

              Out of curiosity is this something that will magically work 🪄 or will it require explicit usage in the extensions?

                SychO I meant more like FoF extensions built into core Flarum, so they are just built-in features rather than traditional extensions. Could still be enabled/disabled but they ship with the Flarum install.

                Alternatively, an extension library in the admin panel to see the most popular extensions would be great. I'm now in feature request territory so I'll post a more in-depth thread there instead.

                9 days later

                Do you guys have a rough estimate for when this will go live ? ( not taking into account possible delays ofc )

                7 days later
                4 days later
                4 days later

                Howdy!

                Apologies for the delay in posting an update for weeks 4 and 5 (week 6 coincided with a holiday).

                Here's a quick summary of our progress so far:

                We've successfully tackled the first task, which involved several important updates:

                • We've updated various dependencies, including Laravel Components, Symfony Components, and Flysystem, among others.
                • We've embraced the latest features of PHP 8.1+.
                • We've also revamped our static code analysis infrastructure.

                Completing these tasks required countless hours of work.

                Furthermore, we've taken the first step towards achieving code splitting, which is the implementation of an export registry, a significant milestone.

                To ensure smooth transitions and facilitate future development, we've documented all the notable changes and breaking points. You can find the details here: flarum/docs460. We'll continue to document any further changes, both breaking and noteworthy, as we progress. Our aim is to provide extension developers with an easier experience in the near future.

                Stay tuned for the next update!