Flarum is a new interesting forum engine written in PHP. Well… is not really new, first beta release was almost 4 years ago, so it is with us for some time, but so far there was no stable release and project is still in beta stage. Although it already works pretty well and there are some big production deployments, there is still no backward compatibility promise and officially you should not use Flarum on production. Of course some people (like me) will ignore this warning and use this engine on production forums. I’ve used this engine for GG.deals forum and for some small local community forum. These are quite different cases, and I’d like to share my experience of using Flarum for these two forums.
Extensions system managed by Composer
Flarum core, by design, provides only some basic features that forum needs. Everything else should be provided by extensions. And when I say “basic features” I mean really basic features – even some obvious things like the ability to close threads, subscribe threads or BBCode/Markdown support are provided by extensions. Flarum is basically driven by extensions – thanks to a very flexible system most of the features that regular forum needs, can be implemented by extensions. To create real forum you need to build from the core and several extensions. And Composer is used to putting everything together.
As a PHP developer, I really like this design. Using extensions as the main source of forum features is really flexible and moves some maintenance burden from the core team to the community. The Flarum team provides core engine and some basic extensions, but everything else in on shoulders of community. Now you don’t have an excuse that some feature is not available in forum engine – most likely you should be able to write it yourself by creating a plugin. It also really helps when you want to change one single thing in existing feature – you can simply fork small package and adjust it for your needs (or create a completely different implementation and switch plugins).
Using Composer as extensions manager is also a great solution for me. I’m using Composer every day, and I really enjoy that it solves some annoying problems. First –
composer.lock simplifies installation on multiple environments. Finally, you don’t need to worry that on testing environment you have a different set of plugins than on production environment (and you don’t need to keep all vendor libraries in your repository). Just commit
composer.lock to your repository and run
composer install on both environments. This also makes it really easy to manage dependencies of your extension – just add it to
composer.json of your extension and Composer will do the rest. This may sound like some basic/irrelevant stuff, but you really appreciate it when you compare it to extremely outdated plugins system is WordPress, where simple stuff is no longer simple.
But there is also a black side of this approach. Relying on extensions provided by the community may lead to a really ugly ecosystem of badly written and conflicting between each other extensions (yes WordPress, I’m looking at you!). Creating and maintaining forum consisting of dozens of extensions may be much harder than installing one big monolith with gazillions of options. Composer may be also a great tool for developers, but it was not designed for use in production in this way. Resolving dependencies is a heavy process – it may take some time and a lot of memory to resolve all dependencies required to install a new extension. It may be a really big problem for a regular user which just want to hit a button and install extension – the process may take too much time or just fail due to memory limit on hosting server.
Stable or not?
Well, that depends. I have two installations of Flarum and both works without any problems. Technically Flarum is in beta, but it already is pretty stable and there should be no risk that something will break really hard. But beta status means that some thinks may be a little harder than in usual stable software.
First, installing Flarum is not really straightforward. There is no official installation package which you could drop on your hosting. Flarum needs to be installed using Composer from the shell – this can be an unpleasant experience for people used to the WordPress installer. And that is just the beginning – default installation is quite ascetic, you need to a couple of must-have plugins to provide some features that are standard in different forum engines. And it is not so easy either – the last release of Flarum introduced some major breaking changes in extensions API, and some extensions are still not compatible with the last release. Finding all interesting plugins (database of all Flarum extensions is quite big already) and ensuring that they’re working fine will take some time and may require technical/programming skills. If these sound scary for you and you just want to use/test Flarum, you may try to use Free Flarum as hosting service – it will handle installing Flarum and most of the popular extensions for you. For installing extension Bazaar extension by Flagrow may be also helpful.
The second problem with Flarum is that there is no stable line with some minor bugfixes. Patch releases are rare and fix only some major security issues – other issues will be fixed by next beta release. And unfortunately, beta releases are also rare – beta 8 was released in November 2018, and 6 months later there is still no beta 9 release. This means that even if some bugs was fixed 6 months ago, there is still no release with this bugfix. To handle such bugs you need to fork a package, cherry-pick a commit with the fix from upstream, and use this fork in
composer.json – this will require some basic knowledge about git and Composer, so you may have some hard time as non-developer.
Slow development can also worry – Flarum is still quite simple and lacks some features. Localization can be problematic since some core extensions do not support translations – you need to fork a package and translate texts in views. Event existing localization packages may need some work (that is why I created my own localization package for the Polish language). Personally, I’m feeling like users management and notifications systems still needs some work and at the current state, it could be really hard to manage a big forum powered by Flarum. For a big project, you should probably expect, that you will need to create your own extensions to provide some important features.
Flarum UI is really great. It may lack some advanced features, but if you want just write and read posts on forum, Flarum gives me the best user experience so far – it is fast, clean and really intuitive. It also has really low hosting requirements – it is basic LAMP, so you could host Flarum on any decent shared hosting. If I need forum engine for a big and demanding community, where I get thousands of users and new posts daily, I would probably hesitate between Flarum and Discourse, but for a smaller community, Flarum should be much easier to host and maintain (even considering some initial burden with setup and installing extensions).
I’m using Flarum for two forums and I think it was a good decision. I really hope this project will move forward and development will speed up a little. PHP definitely needs some modern forum engine and Flarum looks like the best candidate for such role.