Flarum 2.0 is almost here — here's how to help ship it

The forum you're reading this on runs Flarum 2.0.0-rc.5 — in production, today. "Stable" is one or two releases away now, and the last mile of any release is exactly where an extra forum, an extra bug report, an extra pair of eyes counts for the most. Here's how to be one of those hands.

In this issue:

• Where Flarum 2.0 actually stands right now
• The most valuable thing you can do (it's boring, and it's just running it)
• How to test 2.0 without gambling your real community
• How to write a bug report a maintainer can actually act on
• Five ways to help that don't involve touching core code

Where 2.0 actually stands

Flarum 2.0 is not a rumor anymore. The beta line ran for months. The release candidates started in April, and rc.5 shipped on July 8 — three days before this issue went out.

"Release candidate" is a specific promise: the features are frozen. Nobody's adding a shiny new thing to 2.0 at this point. Every release now is polish — bugs, edge cases, the last rough corners. And you can watch the release close in just by reading the changelogs: each RC lands fewer changes than the one before, and the changes get smaller. That's what the end of a release looks like.

Here's the honest part, though. "Right around the corner" does not mean "done." Release candidates exist for one reason: to get real installs to surface the last bugs before they're frozen into a stable release that thousands of forums will run for years. The bugs left in 2.0 today are, almost by definition, the ones a test suite can't find. They only show up on a real forum, with real data, real extensions, and real people using real browsers.

Which is where you come in.

The most valuable thing you can do is boring

It's not writing code. It's running it.

Maintainers can't reproduce what nobody runs. Consider a fix that landed in rc.5: on iPads, tapping a discussion in the list required a second tap to actually open it. No unit test on earth catches that — someone had to be sitting there with an iPad in their hands, going "why do I have to tap twice?" and then saying so. That's the whole game right now.

I'll put my money where my mouth is. I run this forum on 2.0 in production — not a demo, the actual thing you're reading. And three of the fixes in rc.5 have my name on them, because I hit all three by just using my own forum:

• A page 500'd instead of returning an empty result when a certain request asked for zero items.
• Tag counts didn't update when a pending discussion got approved.
• Lists stopped continuing when you pressed Enter in the Markdown editor.

None of those were theoretical. None of them would've shown up in a spec file. I found them because I was living in the software, and then I spent an afternoon each turning "huh, that's broken" into a pull request. That path — notice → report → (maybe) fix — is open to every single person reading this.

You don't have to close the loop with a PR. Noticing and reporting is already the contribution. The maintainers can take it from there.

Test 2.0 without gambling your community

You do not have to upgrade your live forum on day one. Please don't, actually, unless you like adventure. There are two safe ways to get your hands on 2.0:

1. Clone your forum to a staging copy and upgrade the copy. Same data, same extensions, zero risk to the real thing. Poke it. Try the workflows your members actually use.
2. Spin up a throwaway. If cloning your whole stack sounds like a weekend, don't — stand up a fresh, disposable 2.0 forum in about a minute, run the exact scenarios you care about, and delete it when you're done.

Either way, here's the checklist that actually finds problems:

• Your extensions. Do the ones you depend on have a 2.x release yet? Enable them one at a time on 2.0 and watch what breaks. Half of what looks like a "core bug" is really an extension that hasn't caught up.
• Your theme. Custom LESS and overrides are where 2.0's frontend changes bite. Load your real theme, not the default.
• The upgrade itself. Run the actual migration on a copy of your real database. A clean install passing is nice; your five-year-old forum with 200k posts migrating cleanly is the thing people actually need to know.
• Mobile, login, and email. The unglamorous paths. Sign in on a phone. Trigger a notification email. Reset a password. These are exactly where the last bugs hide.

How to report a bug they can actually act on

A good bug report is worth more than a bad pull request. Here's how to write one that gets fixed instead of sitting in a triage queue:

• Search first. There are dozens of issues already open — yours might be known, or already fixed on the development branch. Thirty seconds of searching saves everyone an afternoon.
• One bug per report. Bundling three problems into one issue means none of them get closed cleanly.
• Steps to reproduce, expected vs. actual. "It's broken" is a mood. "Do X, I expected Y, I got Z" is a bug report.
• Include your version and setup. Run php flarum info and paste the output. For frontend bugs, name your browser and OS, and include any console errors.
• List your enabled extensions. Seriously. It's the single most useful line, because it turns "unreproducible core bug" into "ah, extension conflict" in minutes.

Framework bugs go to the flarum/framework issue tracker on GitHub. If you're not sure it's a bug — if it might just be you — the community over on discuss.flarum.org will help you figure that out before you file. Both are contributions. Neither requires you to write a line of PHP.

Five ways to help that aren't core code

Not a developer? The release still needs you. In rough order of impact:

1. Update your own extension to 2.x. If you maintain anything on the marketplace, this is the highest-leverage thing you can do — every forum waiting on your extension is a forum that can't move to 2.0 yet.
2. Test other people's beta extensions and tell them what broke. Extension authors are flying just as blind as core maintainers.
3. Triage an existing issue. Pick an open bug, try to reproduce it, and comment with what you found. A confirmed "yes, I see this too, here's my setup" is genuinely gold — it moves an issue from maybe to actionable.
4. Fix a doc. The documentation gets better the same way the code does: someone hits a wall, then writes down what they wish had been there. Doc fixes ship in these releases too.
5. Say it works. Maintainers need the positive signal as much as the bug reports — "rc.5 has run my 30k-member forum for a week with zero issues" is exactly what gives them the confidence to cut a stable release. Silence reads as "nobody's testing."

Why now, specifically

Because the window is closing, and it doesn't reopen.

Right now, a bug you find is cheap to fix — it's caught before stable, patched, gone. The same bug found after 2.0 goes stable becomes a workaround that thousands of forums quietly live with until 2.1, because the API is locked and the fix can't break anyone. The maintainers have already opened the 3.0 milestone; they are looking ahead. The kindest thing the rest of us can do is help them close the door on 2.0 cleanly.

The beta line ran for months. Five release candidates since April. rc.5 landed three days before this issue with more than two dozen changes — most of them things real forums hit, not things a test suite caught. Dozens of issues still open. Stable is close. Close is exactly when hands matter.

Flarum is a small project carrying a lot of forums. It gets to "stable" on the backs of people who ran the not-quite-finished version and said something. Be one of them. Run it, break it, and report what broke — that's the whole ask, and it counts more this month than it will all year.

Want to try 2.0 without touching your real forum? Spin up a disposable Flarum in about a minute — upgrade it, load your extensions, break it, report what broke, and delete it when you're done. No install, no risk to production.

Are you running an RC yet? What broke — or what worked? Reply below — this newsletter is a forum thread, and I read everything.

— Karl