Flarum 2.0.0-rc.8 Released - you tested rc.7, and you found things

Three days ago I called 2.0.0-rc.7 "the release candidate", said there was no more feature work planned before stable, and asked the community one question: is this ready to be 2.0.0? I also said the only thing standing between rc.7 and a stable 2.0 was a few more forums running it and reporting back.
That's exactly what happened - and you found things. Ten fixes' worth. Not one of them is a disaster, none involve data loss, and nothing shook the foundations. But several were the kind of paper cut that would have been genuinely irritating to discover in 2.0.0 proper: an email arriving with flarumsafevalue… where a link should be, a cache clear leaving the next visitor with a blank 500, a discussion showing up twice after you left a tab open.
So this is 2.0.0-rc.8: ten fixes, no new features, no behaviour changes. Every single one came from someone running rc.6 or rc.7 on a real forum and saying something.
Here's what that means for the question we put to you. The vote is still on - it just moves to this build. rc.8 is the candidate we now expect to become 2.0.0 stable, unchanged. If you were about to weigh in on rc.7, upgrade to rc.8 first and weigh in on that instead.
And to be clear about the shape of this: rc.7 wasn't a bad release candidate. It held up. What it also did was get onto enough real forums that ten genuine issues surfaced in three days - which is the entire purpose of a release candidate, and a far better outcome than finding them the week after tagging stable.

🚀 Upgrading is composer update -W, then php flarum migrate and php flarum cache:clear. Nothing about the dependency picture changed this cycle, but keep the -W — take a backup, stage it if you can, keep a way back. Same as always.
👀 discuss.flarum.org is running it. As with every release this cycle, this forum is on the final 2.0.0-rc.8 — the exact build you'll download. The nightly demo tracks 2.x too.

---

🔧 What's fixed

Ten fixes. Grouped by what they'll mean to you.

📧 Email

• Emails no longer leak raw substitution markers. The mail translator swaps values like a discussion title or a display name for opaque markers before rendering, then puts them back - but the restore only ran inside the mail formatter. Any template printing a translated value directly sent the marker straight to the reader; flarum/gdpr's erasure emails did exactly that, and arrived with the account name and confirmation link as flarumsafevalue…endflarumsafevalue. The restore now happens on the finished message, so it applies to every email regardless of which template or extension produced it - including extensions that will never be updated. It also closes a real gap: core's own mail:: views were never being marked, so the markup-injection protection wasn't applying to core mail at all. (#4988)
• A legitimate second notification email is no longer silently dropped. The dedup lock that stops duplicate notification emails was keyed on the notification's type and recipient, so a genuinely different notification of the same type to the same user within 600 seconds got swallowed. Clearest case: request account erasure, cancel, request again - the second confirmation email vanished, leaving the user waiting for a link that never arrived. The lock is now keyed on the notification's full identity, matching how the notification row itself dedupes. (#4989)

🔍 Cache, upgrades and diagnostics

• cache:clear no longer risks a blank 500 for the next visitor. Clearing the cache deletes the compiled text formatter, and the next request that renders a post rebuilt it. On a forum with many extensions that build is big - one real report had it at ₁₇₄ KB, peaking past a 256 MB web memory_limit and taking ₃₀ seconds. A PHP memory fatal isn't an exception and isn't a kernel OOM, so nothing was logged: the visitor just got a blank 500, and it landed on whoever arrived next rather than the admin who cleared the cache. The formatter is now built during cache:clear itself, where memory is usually generous. Best-effort, so a failed warm can never fail the clear. (#4990)
• flarum info reports the right web memory limit on Debian and Ubuntu. The scan covered the Docker conf.d layout but not /etc/php/{version}/fpm/conf.d/, where Debian and Ubuntu actually set it - so it fell through to the base php.ini and under-reported (one report showed "Web: 128M" against a real 512M). That output is what people paste into support threads, so a wrong figure actively misleads diagnosis. Display-only; nothing about how Flarum runs changes. (#4991)

📱 Frontend

• The discussion ⋮ menu opens in one tap on iPad. At tablet-up widths the per-discussion controls are revealed on :hover. A touch screen has no hover, so iOS Safari fakes one with a priming tap - the first tap revealed the control and was swallowed, and only the second opened the menu. Logged-in users on iPad were tapping twice for every menu, reproducibly on discuss.flarum.org. Pointer devices keep hover-to-reveal exactly as before. (#4992)
• A realtime update no longer duplicates a discussion in the list. Reported straight off rc.7: "left the tab idle, came back to a duplicate discussion; refreshing fixes it." The list matched discussions by object reference, and the store hands back a fresh instance for a discussion that's scrolled out of the loaded pages - so the match failed and the discussion was added a second time. Now matched by id. This also fixed a splice(index) missing its length argument, which was removing the matched item and everything after it. (#4993)
• Image uploads without a file give a validation error, not a crash. The avatar and admin image upload endpoints hit an unhandled TypeError when a request arrived with no file part. You now get "The field is required.", and the avatar picker won't post a non-file in the first place. (#4995)
• Post search results get their own tooltip. They were reusing the discussion author tooltip; they now use the replied_text translation with the post's own timestamp. Spotted by @clarkwinkelmann. (#4996)
• The admin "Users" heading is no longer centred on mobile. It was inheriting the flex layout from the toolbar row below it, which centred the heading on narrow viewports while every other admin page stayed left-aligned. Spotted by @claudiush. (#4997)

🧩 Extensions

• <PageStructure /> no longer crashes when sidebar is omitted. Reported by @rafaucau: a custom page built with the documented, optional sidebar attribute left out rendered nothing and threw in the console. The root cause turned out to be a level down, in ItemList.toArray() - it boxed non-object item content so it could attach itemName, and Object(null) is {}, which Mithril treats as a vnode with no tag. So any extension adding a conditional item as null was one render away from taking a page down. Null and undefined now pass through untouched. (#5000)

That's the whole release. The full changelog has the details.

---

🗳️ The question, now on rc.8

Nothing about the question has changed - only the build it applies to. A release candidate that holds up in the real world becomes 2.0.0 stable, unchanged. rc.8 is that candidate. There's no feature work or behaviour change planned before stable, and from here the line moves on one thing only: whether the forums running it say it holds.
So, again, to everyone - not just the people who file issues: is 2.0.0-rc.8 ready to be 2.0.0?
The poll is still coming, and it'll ask exactly that. If anything, the last three days made the case for it: ten issues surfaced because people upgraded real forums and spoke up, and none of them would have been caught by our own testing alone.

1. Upgrade a real forum - composer update -W, then php flarum migrate, php flarum cache:clear. Back up first; stage it if you can.
2. Form your view before the poll. "Upgraded, holds up, ship it" is exactly as valuable as a bug report right now, maybe more. Get a real read on it, so that when the poll opens, your vote is grounded in your own forum.
3. If something breaks, tell us how much it hurts. Data loss, a security issue, a broken upgrade, a regression, or something with no workaround is a must-fix-now and holds the stable tag. A rough edge, a cosmetic thing, or something a bit of CSS works around can land in 2.0.1 or 2.1 without holding 2.0 back. Tell us what and how badly, and we'll draw the line together.

Share your first impressions in this thread, and send the specifics where they belong:

• Core bugs → flarum/frameworkissues
• Questions, feedback, extension quirks →Support
• Security → [email protected] (privately, please)

---

🧭 On the fence? Ask the Upgrade Advisor

If "should I upgrade?" really means "will my extensions come with me?", the FoF Upgrade Advisor answers it before you touch a thing — it checks every installed extension for a 2.0-compatible release, and your PHP and database versions against what 2.0 needs.

composer require fof/upgrade-advisor:"*"

Read the verdict, clear what it flags, then uninstall once you're green.

---

🧑‍💻 One for the extension developers

Two things in this release are aimed squarely at you.
The PageStructure fix above (#5000) means a custom page without a sidebar now works as documented - if you'd hit that and worked around it by passing an empty sidebar vnode, you can drop the workaround.
The wider half matters more: because the bug was really in ItemList.toArray(), any ItemList item added as null was a live crash, not just the sidebar. If you've ever written:

items.add('thing', condition ? <Thing /> : null, 10);

that's safe now. It wasn't before - it rendered an empty object that Mithril tried to treat as a component.
A correction to the PageStructure docs is coming separately: className is documented as optional but is currently typed as required, and the pane attribute isn't documented at all. Both turned up while chasing this bug.

---

Please keep testing and keep reporting - nothing will be missed. It's not a bad thing for the "is this 2.0?" question to sit with the community for a few days: this call was never meant to be mine alone, and a quieter week is a fair chance for the consensus to form on its own terms. If you hit a genuine security issue, use [email protected] so it's handled privately regardless of timing.
If rc.8 holds up and the verdict comes back "ship it," then the next step is the one we've all been working toward: tagging it 2.0.0. 💙

Is Flarum 2.0.0-rc.8 ready to become 2.0 GA? Vote now!

Following on from the release of 2.0.0-rc.8, we'd love to get your opinion on whether this release should be tagged as 2.0.0 — officially bringing Flarum 2.x into stable.
This is the vote we've been building toward all along. The plan has always been that a release candidate which holds up in the real world becomes 2.0.0 stable, unchanged — and rc.8 is that candidate. Whether it crosses the line isn't a call we make alone; it's yours as much as ours. So here it is.

What you're voting on

A simple yes or no: should 2.0.0-rc.8 be tagged as 2.0.0 stable, as-is?

• A yes means: I've run it (or followed closely enough to have a view), and I think it's ready.
• A no means: not yet — and ideally, here's why. A "no" with a reason is the most useful thing you can leave in this thread. It isn't a vote against the release; it's a vote for getting it right.

There's no wrong answer, and no pressure to land on "yes." An honest "not yet, because X" is worth far more than a reflexive "ship it" - we'd really rather hear the problem now than the morning after tagging stable.

Before you vote

The vote only means something if it's grounded in reality, so if you can:

• Run rc.8 on a real forum — composer update -W, then php flarum migrate and php flarum cache:clear. Back up first; a staging copy is ideal.
• Use it like your members would for a bit - post, search, moderate, upload, whatever your forum actually does.
• Then vote, with your own forum as the evidence.

Can't run it yourself but you've followed the RC cycle closely? Your read still counts - just weight it accordingly.

Help us triage: must-fix-now vs. later

Just as important as reporting problems is helping us weigh them, because not everything found has to be fixed before 2.0 ships. When something comes up, the question we'll be asking is:

• Does it block 2.0? Data loss, a security issue, a broken upgrade path, a regression from the previous release, or something with no workaround - these are must-fix-now. They hold the stable tag, and they're a reason to vote no.
• Or can it wait? A rough edge, a nice-to-have, a cosmetic issue, or something an extension or a bit of CSS can work around - these can land in a 2.0.1 or 2.1 without holding 2.0 back. Vote yes and note them separately; they won't be forgotten.

Holding 2.0 indefinitely for every last polish item helps no one; shipping 2.0 with a genuine blocker helps no one either. Tell us what you hit and how much it actually hurts, and we'll draw that line together.

What happens next

• If the vote lands clearly yes and nothing blocking surfaces, the next step is tagging 2.0.0 - the release this has all been building toward.
• If it's no, we fix what's holding it and go again. That's exactly what the RC process is for; it's not a failure, it's the system working.

Either way, the decision gets made in the open, by the people it affects.

---

Found a bug while testing? Reports still go where they always do - core bugs to the issue tracker, security privately to [email protected]. This thread is for the verdict; those are for the details.
Cast your vote below. 🗳️

Flarum 1.8.19 — Security Release

We strongly recommend all forums running Flarum 1.x upgrade to 1.8.19 immediately.
This is a security release that fixes a critical vulnerability allowing account takeover via the password-reset flow. If you run a public Flarum forum, please treat this as urgent.

---

Who is affected

• Flarum 1.x: all versions up to and including 1.8.18 are affected.
• Flarum 2.x: the 2.0.0-beta.1 through 2.0.0-beta.6 pre-releases were affected. This was resolved in 2.0.0-rc.1, so current 2.x is not affected.

If you are on 1.x, you are affected and should upgrade.

Impact

An unauthenticated attacker could take over any account on an affected forum — including administrator accounts — without needing the victim's password-reset token or any prior access. The only prerequisite is knowing (or guessing) a registered email address.
Because administrator accounts can be targeted, we consider this critical severity (CVSS 9.8).
Tracked as GHSA-55f2-h36g-96c3.

How to upgrade

composer update flarum/core --with-all-dependencies
php flarum migrate
php flarum cache:clear

Then confirm your version:

php flarum info

You should see Flarum core 1.8.19.

If you cannot upgrade right now

Upgrading is the only real fix, but if you genuinely cannot patch immediately, you can mitigate at your web server, reverse proxy, or WAF by rejecting password-reset requests whose token field is not a normal string value. Legitimate clients always send the reset token as a quoted string; the attack relies on sending a non-string value instead.
Block POST /reset requests whose JSON body matches:

"passwordToken"\s*:\s*(?!")

This blocks the malicious shape (a bare number, null, or boolean) while leaving genuine password resets untouched. Remove the rule and upgrade as soon as you are able — this is a stopgap, not a fix.

Details

Out of consideration for forums that have not yet upgraded, we are keeping the full technical write-up and proof-of-concept embargoed for now. Complete details will be published in the security advisory once forums have had a reasonable window to update.

Thanks

Thanks to the reporter for the responsible disclosure that led to this fix.

---

Questions about upgrading? Ask in theSupport tag. Please do not post exploit details publicly.