Staff Diary: v2.0 Cycle

luceos

Yes, here it goes. The staff diary for the v2.0 cycle. You can read up on what's in store in this post: https://discuss.flarum.org/d/32812

MikeJones

Super pumped!

Wlork

I'm very curious to know what new features the update will include 🙂

CyberGene

Wlork click on the link and you’ll see 😉

luceos

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.

luceos

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".

SychO

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

composer update flarum/core
php flarum migrate

SychO

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.

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

luceos

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.

Burial0268

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

luceos

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.

Burial0268

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!

mella

luceos Is there any plans on Octane yet or did someone test the compatibility?

SychO

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!

Zeokat

SychO Require a minimun of PHP 8.2 will break default Ubuntu Server Installations, because latest LTS 22.04 includes PHP 8.1 🤔

Circa

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!

SychO

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

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

Darkle

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?

Circa

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.

SychO

Darkle the decision to lazy load anything will have to be explicit.