Flarum 2.0.0-rc.8 released

IanM · 2026-08-27T20:35:59+00:00

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 174 KB, peaking past a 256 MB web memory_limit and taking 30 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 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. Upgrade a real forum - composer update -W, then php flarum migrate, php flarum cache:clear. Back up first; stage it if you can. 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. 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 → security@flarum.org (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:"*" if(window.hljsLoader && !document.currentScript.parentNode.hasAttribute('data-s9e-livepreview-onupdate')) { window.hljsLoader.highlightBlocks(document.currentScript.parentNode); } 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 ? : null, 10); if(window.hljsLoader && !document.currentScript.parentNode.hasAttribute('data-s9e-livepreview-onupdate')) { window.hljsLoader.highlightBlocks(document.currentScript.parentNode); } 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 security@flarum.org 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. 💙

hectorism

I'm technically challenged.... Someone tell me what's the difference between the Private Path and Public Path versions ?? mumbo jumbo to me!

CeeBee

Thank you! I can confirm the iOS/iPad "double tap" issue is still present here on discuss.flarum.org. I'd be happy to help with testing.

As a temporary fix, this CSS fixed it for me:

@media (any-hover: none) { .DiscussionListItem-controls { opacity: 1; } }

EvilSonic

Upgrade Advisor is showing me I've got a couple of extensions that won't work in Flarum 2, is this an appropriate topic to list which ones or is there a topic specifically for that? (Or am I supposed to ask in each topic? Seems like some of the authors are inactive)

Karl

EvilSonic best bet is to leave a message in the relevant discussion to at least give the devs a chance to reply. If it’s truly abandoned, you may open aProposals discussion for it.

werter

Flarum core: 2.0.0-rc.8
PHP version: CLI: 8.4.24, Web: 8.4.24
PHP memory limit: CLI: 512M, Web: unable to detect
MariaDB version: 11.8.9
😘 😍

ClaudiusH

Here's an odd bug: If on the discussion list you click "Load more" right at the moment a new discussion arrives then the last discussion gets listed twice (In my example "FoF Blog"):

huoxin

ClaudiusH quite a common issue in software that has pagination, basically the main reason is that between your first and second load, someone did a reply and that FoF Blog discussion got shifted from the 20th discussion to 21st discussion in the list, then when you load more, flarum will be retriving the 21st discussion to 40th discussion, so that FoF Blog disucssion appeared again (just an example didnt check how many discussion flarum actually loads at once)
Technically we can do a deduplication of discussion loaded but will definitely eat up some of your computation power at the client side (especially when user is keep scrolling down the list, but not sure how big the list would need to be for phones nowadays to start lagging 😂 )

werter

[rc.8] Clicking uploaded file link redirects to home instead of opening it

Found a core bug in rc.8: clicking a direct in-post link to an uploaded
image/file redirects to the forum home page instead of opening it.
Opening the same link via "Open in new tab" works fine.

Root cause: Formatter::isInternalUrl() marks any same-host URL as
"UrlLink--internal" without checking if it maps to an actual app route.
The client-side routeInternalLinks.ts trusts the class and calls
m.route.set(), which silently falls back to home when the path
(e.g. /assets/files/...) doesn't match any registered route.

Full details and reproduction steps here:
flarum/framework5012

Reproducible with fof/pwa both enabled and disabled, so it's not
extension-specific — pure core issue.

ram0ng1

I found a small bug related to unapproved/spam posts that get hidden but are never visible to regular users, which causes discussions to stay marked as unread forever.

In discussion #39415 the last two posts were spam that got hidden/unapproved, but the discussion's lastPostNumber still points to them (27, while only 25 posts are visible). Since a regular user never receives those posts, the client never sends the read update and the "2 unread" badge can't be cleared.

I opened an issue on GitHub with the full details from the HAR capture and a screen recording:

flarum/framework5013

I recorded a short video for demonstration purposes:

Wlork

@Karl

As promised, I created a GitHub issue for the minor bug I encountered : flarum/framework5014

😉

IanM

ram0ng1 this was caused by a bug in fof/anti-spam, which is now resolved. Unfortunately the fix will only work for discussions going forward.

The next post in that thread will however then reset the unread counts to how they should be

Lumeinshin

The recent wave of extension updates, as well as this being RC8 has increased my confidence and i've upgraded my site to flarum2.0 🙂
There was some docker shenanigans beforehand so i had to do a separate migration as well.
2.0 is looking great so far, only a couple extensions havent been updated yet and the rest all have been. performance has been surprisingly great which is good to know. Great job everyone working on it!

endlessedits

Switched to 2.0 rc8, happy as a clam. Great work, Flarum team.

« Previous Page