# Contributing

Interested in contributing to Flarum development? That's great! From opening a bug report to creating a pull request: every contribution is appreciated and welcome.

Before contributing, please read the code of conduct.

This document is a guide for developers who want to contribute code to Flarum. If you're just getting started, we recommend that you read the Getting Started documentation in the Extension docs to understand a bit more about how Flarum works.

# What to Work On

Check out our upcoming Milestones (opens new window) for an overview of what needs to be done. See the Good first issue (opens new window) label for a list of issues that should be relatively easy to get started with.

If you're planning to go ahead and work on something, please comment on the relevant issue or create a new one first. This way we can ensure that your precious work is not in vain.

# Development Setup

flarum/flarum (opens new window) is a "skeleton" application which uses Composer to download flarum/core (opens new window) and a bunch of extensions (opens new window). In order to work on these, we recommend forking and cloning them into a Composer path repository (opens new window):

git clone https://github.com/flarum/flarum.git
cd flarum

# Set up a Composer path repository for Flarum packages
composer config repositories.0 path "packages/*"
git clone https://github.com/<username>/core.git packages/core
git clone https://github.com/<username>/tags.git packages/tags # etc

Next, ensure that Composer accepts unstable releases from your local copies by setting the minimum-stability key to dev in composer.json.

Finally, run composer install to complete the installation from the path repositories.

After your local installation is set up, make sure you've enabled debug mode in config.php, and set display_errors to On in your php config. This will allow you to see error details for both Flarum and PHP. Debug mode also forces a re-compilation of Flarum's asset files on each request, removing the need to call php flarum cache:clear after each change to the extension's javascript or CSS.

Flarum's front-end code is written in ES6 and transpiled into JavaScript. During development you will need to recompile the JavaScript using Node.js (opens new window). Please do not commit the resulting dist files when sending PRs; this is automatically taken care of when changes are merged into the master branch.

cd packages/core/js
npm install
npm run dev

The process is the same for extensions.

cd packages/tags/js
npm install
npm link ../../core/js
npm run dev

# Development Workflow

A typical contribution workflow looks like this:

  1. 🌳 Branch off the appropriate branch into a new feature branch.

    • Bug fixes should be sent to the latest stable branch.
    • Minor features that are fully backwards compatible with the current Flarum release may be sent to the latest stable branch.
    • Major features should always be sent to the master branch, which contains the upcoming Flarum release.
    • Internally we use the naming scheme <initials>/<short-description> (eg. tz/refactor-frontend).
  2. 🔨 Write some code.

  3. 🚦 Test your code.

    • Add unit tests as necessary when fixing bugs or adding features.
    • Run the test suite with vendor/bin/phpunit in the relevant package folder.
  1. 💾 Commit your code with a descriptive message.

  2. 🎁 Submit a Pull Request on GitHub.

    • Fill out the pull request template.
    • If your change is visual, include a screenshot or GIF demonstrating the change.
    • Do NOT check-in the JavaScript dist files. These will be compiled automatically on merge.
  3. 🤝 Engage with the Flarum team for approval.

    • Team members will review your code. We may suggest some changes or improvements or alternatives, but for small changes your pull request should be accepted quickly.
    • When addressing feedback, push additional commits instead of overwriting or squashing (we will squash on merge).
  4. 🕺 Dance like you just contributed to Flarum.

# Coding Style

In order to keep the Flarum codebase clean and consistent, we have a number of coding style guidelines that we follow. When in doubt, read the source code.

Don't worry if your code styling isn't perfect! StyleCI will automatically merge any style fixes into Flarum repositories after pull requests are merged. This allows us to focus on the content of the contribution and not the code style.


Flarum follows the PSR-2 (opens new window) coding standard and the PSR-4 (opens new window) autoloading standard. On top of this, we conform to a number of other style rules (opens new window). We use PHP 7 type hinting and return type declarations where possible, and PHPDoc (opens new window) to provide inline documentation. Try and mimic the style used by the rest of the codebase in your contributions.

  • Namespaces should be singular (eg. Flarum\Discussion, not Flarum\Discussions)
  • Interfaces should be suffixed with Interface (eg. MailableInterface)
  • Abstract classes should be prefixed with Abstract (eg. AbstractModel)
  • Traits should be suffixed with Trait (eg. ScopeVisibilityTrait)

# JavaScript

Flarum's JavaScript mostly follows the Airbnb Style Guide (opens new window). We use ESDoc (opens new window) to provide inline documentation.

# Database

Columns should be named according to their data type:

  • DATETIME or TIMESTAMP: {verbed}_at (eg. created_at, read_at) or {verbed}_until (eg. suspended_until)
  • INT that is a count: {noun}_count (eg. comment_count, word_count)
  • Foreign key: {verbed}_{entity}_id (eg. hidden_user_id)
    • Verb can be omitted for primary relationship (eg. post author is just user_id)
  • BOOL: is_{adjective} (eg. is_locked)

Tables should be named as follows:

  • Use plural form (discussions)
  • Separate multiple words with underscores (access_tokens)
  • For relationships tables, join the two table names in singular form with an underscore in alphabetical order (eg. discussion_user)


Flarum's CSS classes roughly follow the SUIT CSS naming conventions (opens new window) using the format .ComponentName-descendentName--modifierName.

# Translations

We use a standard key format to name translation keys descriptively and consistently.

# Development Tools

Most Flarum contributors develop with PHPStorm (opens new window) or VSCode (opens new window).

To serve a local forum, Laravel Valet (opens new window) (Mac), XAMPP (opens new window) (Windows), and Docker-Flarum (opens new window) (Linux) are popular choices.

# Contributor License Agreement

By contributing your code to Flarum you grant the Flarum Foundation (Stichting Flarum) a non-exclusive, irrevocable, worldwide, royalty-free, sublicensable, transferable license under all of Your relevant intellectual property rights (including copyright, patent, and any other rights), to use, copy, prepare derivative works of, distribute and publicly perform and display the Contributions on any licensing terms, including without limitation: (a) open source licenses like the MIT license; and (b) binary, proprietary, or commercial licenses. Except for the licenses granted herein, You reserve all right, title, and interest in and to the Contribution.

You confirm that you are able to grant us these rights. You represent that You are legally entitled to grant the above license. If Your employer has rights to intellectual property that You create, You represent that You have received permission to make the Contributions on behalf of that employer, or that Your employer has waived such rights for the Contributions.

You represent that the Contributions are Your original works of authorship, and to Your knowledge, no other person claims, or has the right to claim, any right in any invention or patent related to the Contributions. You also represent that You are not legally obligated, whether by entering into an agreement or otherwise, in any way that conflicts with the terms of this license.


Last Updated: 5/25/2021, 12:55:36 PM