2. Bug: Long titles overlap with tags. http://imgur.com/jFGRHtC This is on Chrome 44.0, Windows 10.
3. Feedback: The Title/Tag banner at the top of every post seems too large. 141px tall and no way to dismiss/shrink. This is especially noticeable given the bold banner colors. It's very attractive, but I keep looking for the dismiss button.
6. Feedback: Why no infinite scroll on the main page? "Load More" works fine, but seems inconsistent with the in-thread scrolling.
7. Feedback: The "move" icon on the infinite scroll scrubber seems a touch odd, because it indicates 2-dimensional motion. Maybe "ns-resize"?
With all that said, this seems very nice. It's simple from a user perspective, and it's attractively designed. It's responsive, and from a quick glance the docs look nice. I love the infinite scroll scrubber. Nice work.
I work for Pusher and I have upgrade your account to a business plan for now.
We always love to help up and coming product, especially open source ones so drop me an email at sylvain@pusher.com to discuss this further. Happy to help.
This is very kind of you and Pusher, but I have to be honest, if I'm to ever consider hosting something like this I'd like the option to be entirely self hosted and not reliant on external services.
You can also get something up an running in Go very quickly that should scale pretty well and might make deploys easy since you can just compile to binaries.
We had looked at a bunch of forums from the traditional forums like MyBB, PhpBB, Flux BB to newer takes on forums like Vanilla, Discourse, Nodebb and Esotalk an year ago.
I liked the minimalism of Esotalk but it was being phased out in favour of developing Flarum. I found Vanilla was somehow missing the typical community feel of forums though lowendtalk is using it and is one of the busier communities.
Discourse was Ruby and extremely difficult to install and we did manage eventually but I always felt you need to be comfortable with Ruby or have managed hosting with Discourse. It's a handful.
Flux BB was one of the fastest of the traditional forums then. Arch Linux uses Flux BB and its a busy forum. It will be interesting to see which way they go now that it is going to be Flarum. I remember seeing some heated discussions in the Fluxbb forums about the shift.
We just added a flarum container in the Flockport app store [1] for those who want to give it a quick spin. It will work with LXC and most likely Nspawn too for those who have a recent versions of Systemd.
Phorum powered MySQL:s own (very large-scale) forum (does it still?) among other things, and in a way it seems to share a lot of the light-weightedness with some of the more modern ones in this thread.
Sad to see this eating up and killing off FluxBB. Seems like we're slowly but surely running out of basic, universal, no-nonsense forum software in favour of a move to Twitter/Facebook-timelines or Stack Overflow-style layouts, none of which are great mediums for organised discussion.
I would argue however that both Xenforo and phpBB are ridiculously bloated and should hardly be called basic. phpBB more so than Xenforo obviously. None of them offer the far more robust approach of FluxBB.
Thankfully, as FluxBB is opensource, it can be forked and saved from this development direction.
That was danneu's point - that any forum that actually implements most of what people will want out of it (just to start with - separate subforums/categories, user permissions, tags, thread and user following, local and email alerts, broad formatting options, media embeds, per-user display settings, etc etc...) is going to be well beyond "basic" just to get a userbase in the first place.
Hey Toby, I'm really glad to see the beta drop! I've been looking at setting up a forum for https://cachethq.io and have been holding off doing so, so that we can use Flarum!
How did you find your JS framework change in the end? Did it all go well?
What plans do you have for the future of Flarum? A marketplace perhaps?
The JS framework change (Ember to Mithril) was a great decision for us, especially given our focus on being fast and lightweight. The codebase ended up being far simpler too. I've been meaning to write a blog post about all the details!
Beyond stability and more features, I hope to set up some services around Flarum later this year – an extension marketplace being the first. In order for Flarum to succeed, building a great ecosystem is a must.
This looks great! I've been looking for a good alternative to replace Vanilla Forums for a while. I think I'll hold off until Flarum stabilizes, since it seems like a natural replacement as well as a substantial upgrade!
One question:
I've had quite an ongoing fight with spammers, and none of the Vanilla Forums plugins solve it adequately (including using all of the available plugins together). How does Flarum help keep spammers at bay?
It doesn't at the moment! D: That's something we plan to address very soon though. Not sure what specific strategies we'll implement – will sit down and nut it out in the next week or two. https://github.com/flarum/core/issues/271
What is your forum software bringing compared to Discourse ?
I actually hate Discourse, for me, this is not the way a forum should be, and from my quick glance at your website, it seems that you go in a very similar direction (which makes me sad :( )
Can I ask specifically what you don't like about the direction Discourse/Flarum are taking?
I can't hope to compete with Discourse on features (yet!), but I think Flarum's elegance sets it apart. Out of the box, it's pretty, fast, easy to use, and works beautifully on mobile. And it's written in PHP, so is super easy to install – any low-end shared host will do.
I like the fact that Flarum has an html-only version for browsers with disabled javascript, but it seems to be an alternate implementation, not the same content with less interactivity as it would be expected - it shows much less information and doesn't seem to have feature parity with the interactive version.
This means that the software will only be usable from interactive sessions on "standard" mainstream browsers, and won't be easy to integrate with batch-processing tools (like web scrappers or data warehousing) or non-standard environments (anything enabled for the semantic web or developers creating handcrafted personal scripts to enhance their workflows). Classic "static" forums don't suffer from such limitations, being based on simple html and having predictable navigation structures.
Ok - I see how it solves the automation problem. But it means that humans and bots are accessing different web resources to get the same content - it abandons the original idea of the World Wide Web where a single content resource was expected to be used by humans and computers alike using a unified, simple syntax.
Are you talking about content negotiation? I don't think a "single content resource" really makes sense. When humans access a page, they aren't just looking at a single resource, they're looking at a blend of disparate resources (e.g. all the content in the navigation, sidebar, footer, peripheral sections, etc). Hence the need for a dedicated API that returns pristine data.
> it abandons the original idea of the World Wide Web where a single content resource was expected to be used by humans and computers alike using a unified, simple syntax.
I believe we are long past that idea, it's just too much of a restriction for the web in order to compete for audience with other technologies (meaning apps).
It just depends what framework/language you are familiar with. Discourse makes sense if you work with Rails (you'll have an easier time both deploying and customizing the UI). If you work with PHP then Flarum would be a better choice.
I think a lot of the issues with deploying and managing Discourse are probably spot-on, but as a user rather than an administrator, it's by far my favorite forum UI of the many I've come across through the years. YMMV I suppose.
I took a peek at the source code. Extensions are Composer packages that hook into the core dispatcher, while the frontend extends Mithril components written in ES6. I'm in love.
The design is incredibly on-point. The breakpoints for smaller screens work well for me, and everything is where I would expect it to be. The subtle animations and the crisp/clean interface are very refreshing.
Last time I looked at the forums/bb landscape it still seemed to be dominated by phpBB, WordPress' bbPress, and vBulletin. I hope these really fall out of style, as I just don't believe communication online happens in a way that lends itself to those architectures anymore.
Very nice. I love the technology stack, and am curious whether it can run on shared hosting. I see some bash scripts in the source though, and I wonder whether this will alienate windows devs or not.
The technology choices seem to be: PHP + Laravel components + LessCss + Mithrill.
Thanks! The compiled source (http://flarum.org/download) should run on shared hosting no problems. The bash scripts are only for building that ZIP that we put up for download, and setting up a Vagrant development environment. See http://flarum.org/docs/contributing for more info.
We output a copy of the page's data within <noscript> tags. (e.g. http://discuss.flarum.org/?nojs=1) Admittedly it's currently pretty bare-bones and not actually very optimized, haha
I was looking at forum software for the first time in years just last month, and was surprised at how fresh EsoTalk looked compared to the traditionally crufty UI patterns of even more progressive forum packages. As you might imagine, I was then completely blown away when I saw its successor! Congratulations on the beta launch; it looks amazing.
I couldn't find information about this in the documentation. How hard is it going to be either to replace the core authentication with my own implementation, or use Flarum's authentication outside of Flarum? My goal would be to write a lightweight CMS which shares a login with the forum.
> A piece of software that depends on extensions will surely fail without the establishment of an ecosystem. I do not intend to make the same mistake with Flarum.
This seems incorrect to me. If you look today, there are still a several people that actively develop plugins for esoTalk. The community has contributed plugins for Markdown, OAuth, signatures, and social sharing. I myself have made Mandrill and Mailchimp integrations within the last couple months.
> Without the feedback of a team, I have produced some low-quality code and APIs that will surely need revision.
This statement about Flarum sounds to me like the stated reason esoTalk[2] was left in favor of a complete rewrite—it needed a lot of work.
Reviewing some of the history... There was an open source forum solution that had an established base of users that was completely abandoned for an attempted kickstarter of a ground-up rewrite. The kickstarter didn't work, so they're bootstrapping it and going to try to monetize with a paid marketplace and a "service-based business." It all strikes me as a promotional effort to base a kickstarter and a business around.
Toby has already been successful in making a fast and simple forum software, esoTalk. Toby, if your interests are in making freely available forum software but your career path remains focused on medical school, why invest so much time into starting a business around new forum software instead of just putting some time into revamping what you already had?
I'm trying to see the motivation behind this as something which would justify killing off your own forum project and leaving folks who use your software, besides making some cash on a side business, but I can't.
Fair points. I guess I consider esoTalk to be somewhat of a lost cause in terms of the way it's built. It's a pain to implement fixes and features, maintain, and is pretty limited in what it can do (and how it can be extended). Simply put, I didn't enjoy working on it.
When I said "I have produced some low-quality code and APIs that will surely need revision", I'm mostly talking about more semantic things like class naming and organization. The majority of Flarum's architecture is very solid, testable, and will be easy to maintain. Doesn't compare to esoTalk.
Admittedly, if I just wanted to start a business and make some cash, you're right: I probably could've just persisted with esoTalk. But it's not all about money – it's also about doing the best work that I can, enjoying it, and making damn good forum software with great potential.
There will eventually be a migration path from esoTalk to Flarum, and I still merge PRs from time to time... so I like to think I'm not completely abandoning the esoTalk folk!
I'd say creating a solid, modular codebase upon modern PHP/JS best practices is a valid enough motivation. I've been waiting for a project like this myself.
I wonder how well it scales to upwards of thousands of comments, though. There are some forums I've seen where it's not unusual to have threads that are several hundred pages of 20+ posts each.
Basically, the thread author (or admins) mark particular posts, and a table of contents to them gets auto-generated, and each of those posts in the thread gets forward/back buttons to skip to the next/previous. It makes long-running threads much more navigable, especially single-purpose ones (game walkthroughs, following the news about specific events, etc).
Massive threads are somewhat of a proving ground for every forum implementation and feature. Like when you first realize that `OFFSET` SQL for pagination just isn't gonna cut it.
For example, I recently read a field report of someone migrating their Xenforo forum to Discourse (https://meta.discourse.org/t/discourse-for-me-6-weeks-in/319...) that had issues with megathreads after the migration since Discourse sends down a list of all post_ids in the topic, a known issue.
That threadmarks plugin is a brilliant idea, like a curated table-of-contents or places-of-interest. I'm going to implement that on my forum.
I really like that someone is still trying to innovate on PHP forums, and not by simply offering a service. There is still a market for self-hosted forums, and most of the current offerings are basically rotting on the vine.
What are the blockers on using Flarum in production? (Bugs, changing API's, etc) I would consider putting this into light use for a private forum to with maybe 10 to 40 users. If it is not yet ready for this, when would you expect it to be? (Note: your Roadmap is currently empty.)
My experience with many other projects would be that sometime prior to a Release Candidate you would want people to be testing and using the Beta.
I am just evaluating Discourse for a small group, but it looks like Flarum would be a better fit for my use case.
It's buggy, prone to spam, probably not secure, missing features, etc. Probably should've named it an alpha, almost. But if you're game you could give it a spin - we're running our support forum on it currently. Will fill out that roadmap tomorrow :)
This looks interesting, but it would need proper, nested subforums that are more discrete than the current tag system to really substitute for any of the major forums I use.
This isn't because of navigation, but because of the alerts and other cruft that particular sections in large, long-used forums accumulate over time. Per-section alerts (boxes at the top of the page separate from threads) in particular don't seem to be replicable here outside of the descriptions at the top.
Going off of how Toby's last forum project went[1], most things that aren't essential to the project are left open to implement as plugins. esoTalk does have a plugin that lets conversation authors mark one reply as an answer, so I think it's reasonable to guess that one will eventually appear for Flarum.
We built Flarum to be highly extensible, so something like this could easily be implemented! Eventually we'll probably make an official Q&A extension too. If you want to learn more about Flarum's extensibility, check out http://flarum.org/docs/extend/.
Mind reporting an issue for this? (https://github.com/flarum/core/issues) I can't test directly because I'm using a Mac, but it would be great if we can continue investigating on GitHub :)
1. Bug: The "read the rules" banner link is broken. http://discuss.flarum.org/d/392/frequently-asked-questions-p...
2. Bug: Long titles overlap with tags. http://imgur.com/jFGRHtC This is on Chrome 44.0, Windows 10.
3. Feedback: The Title/Tag banner at the top of every post seems too large. 141px tall and no way to dismiss/shrink. This is especially noticeable given the bold banner colors. It's very attractive, but I keep looking for the dismiss button.
4. Bug(?): Over quota error in pusher.min.js. http://imgur.com/xmXPLaq
5. Bug: Avatar 404s. http://imgur.com/xmXPLaq (same image as previous) http://imgur.com/QkPaxr9 (discussion list broken images)
6. Feedback: Why no infinite scroll on the main page? "Load More" works fine, but seems inconsistent with the in-thread scrolling.
7. Feedback: The "move" icon on the infinite scroll scrubber seems a touch odd, because it indicates 2-dimensional motion. Maybe "ns-resize"?
With all that said, this seems very nice. It's simple from a user perspective, and it's attractively designed. It's responsive, and from a quick glance the docs look nice. I love the infinite scroll scrubber. Nice work.