Inside the phpBB master branch and its 4.0.0-dev source tree

A bulletin board developers build from source

phpBB is a forum engine written in PHP, and this repository is where its core, its extensions and its automated tests are developed. The distinction matters for anyone deciding what to deploy, because the tree you clone here is a development source rather than an installation. Site operators who want a running board take a package from phpBB.com instead; the audience for this repository is patch contributors, extension authors and anyone who needs to know how the engine is assembled underneath.

The top-level layout follows from that split. Entries include build/, phpBB/, tests/ and vagrant/, next to phpunit.xml.dist, psalm.xml, eslint.config.mjs, composer.phar, doctum.phar, SECURITY.md and git-tools/. Application code sits under phpBB/, which is also where the two setup guides live, while the repository root holds the tools phpBB expects to find already on disk rather than installed globally.

The GPL-2.0 grant requires that forks redistributing modified code carry the same licence terms, and the last push landed on 2026-10-03.

Version 2 history sitting beside a 4.0.0-dev master

The repository description states that it also contains the history of version 2, so a single clone carries the whole line of phpBB development rather than one branch's worth of it. The version field in package.json reads 4.0.0-dev, which is the clearest signal that master sits ahead of the stable series people are running. The CI table in README.md then calls master the Latest development version and gives a separate row for 3.3.x, labelled Development of version 3.3.x.

That split is easy to miss, and it decides where a change belongs. Reading only the repository description, a contributor could assume master still carries the 3.3 line. No file in the tree maps the 4.0.0-dev string to a numbered series, and the repository has no GitHub releases to look back through, so the branch table in README.md is the only routing information offered. Anyone who wants 3.3.x work needs that sibling branch, not the default one, and nobody has written down how the two diverge over time.

Why the dependency install calls a phar by path

README.md documents a two step build for running an installation from the repo rather than from a pre-built package, and the first step is a fork. The clone command below points at your own GitHub account instead of the project, so it resolves only once that fork exists.

git clone https://github.com/your_github_name/phpbb.git

The dependency step then moves into phpBB/ from the root of the cloned repository. The path in the second command is the detail worth pausing on: composer.phar is committed at the top level, one directory above the folder you now stand in, so the command reaches up with ../ before handing the phar to php.

cd phpBB
php ../composer.phar install

doctum.phar sits at the root for the same reason, which keeps both PHP tools travelling with the checkout and out of a global installation. Run that command from the repository root instead of from phpBB/ and ../ resolves outside the tree, so the phar is not found at all.

Repo checkout against the pre-built phpBB.com package

README.md draws the line between two ways of obtaining phpBB, and the difference decides how much work an adopter inherits. Running from the repo is explicitly not the same as using a pre-built package: the source route needs a fork, a clone and a composer step, while the phpBB.com route hands over something already built for hosting. Nothing in README.md explains how to convert a board installed from a pre-built package into one running from a checkout, and no rollback path is documented either, so the two routes read as separate setups rather than a supported upgrade path.

For development there are two further routes, named only as files in the tree. phpBB/docs/vagrant.md covers Vagrant and phpBB/docs/codespaces.md covers the cloud based environment, with a .devcontainer/ entry and a vagrant/ directory at the root beside them. A contributor without a working local PHP stack can skip assembling one, provided they read the document that matches their own host, since neither file is reachable from the repository index.

npm test exits one on every run by design

The same package.json that records the 4.0.0-dev version also carries a test script that cannot pass. It prints an error and exits with status 1:

"test": "echo \"Error: no test specified\" && exit 1"

A contributor who reaches for the familiar command learns that within a second. Actual test execution does not go through npm: unit and functional tests exist to prevent regressions, run through the bamboo continuous integration instance at bamboo.phpbb.com and through GitHub Actions on tests.yml, with phpunit.xml.dist at the repository root holding the PHPUnit configuration. Two neighbouring fields show the same placeholder habit, since main is a single space character and author is empty.

package.json is therefore not a published npm artifact but a metadata and linting manifest for the tree. Nothing in the repository explains who is expected to run the phpunit configuration locally, and the README routes anyone looking for testing guidance to the development documentation index on area51.phpbb.com.

eslint 9 flat config and stylelint 14 in one file

The devDependencies list is short and exposes how the tree is checked. JavaScript and config files go through eslint ^9.28.0 with globals ^17.0.0, and the flat config eslint.config.mjs sits at the repository root instead of a legacy .eslintrc file. CSS is handled apart from that, by stylelint ^14.7.0 with stylelint-order ^5.0.0, next to a .stylelintrc entry. Two lint stacks, two eras of configuration format, and a single manifest holding both.

A fifth devDependency, web-push-testing ^1.1.1, exists for browser push work, and README.md does not say how those tests are invoked or where their fixtures live. Contributor setup is partly documented on area51.phpbb.com, but the lint configuration is entirely in the tree, which means a fork has to keep those pinned ranges working before it changes anything else.

Edge 18 and Safari 13 set the browser floor

The browserslist array is the clearest statement of which browsers the front end targets, and it is written exclusions first. It accepts more than 1 percent of tracked usage, then drops ie 11, samsung 10.1, and_uc 12.12 and op_mini all, and only afterwards names the floors: edge >= 18, ff >= 72, chrome >= 79, safari >= 13 and ios >= 12.4.

Two things follow from those numbers. Internet Explorer is excluded by name rather than by accident, and the accepted floors are Edge 18, Firefox 72 and Chrome 79, so users on older corporate browsers sit outside the tested set no matter what the operators would prefer. The same array decides what a build targets, which puts support policy in package.json rather than in a settings screen, and README.md does not connect those entries to any particular stylesheet build step.

For a board whose members include long term customers on locked down machines, that file is the first thing to read rather than the installation guide.

A tracker ticket gates the pull request

The contribution flow is ordered, and the order runs through a tracker rather than through the repository. A contributor creates an account on phpBB.com, creates a ticket on tracker.phpbb.com unless one already exists, reads the Coding Guidelines and the Git Contribution Guidelines hosted on area51.phpbb.com, and only then sends a pull request. Both guideline documents are linked from README.md, and the index at area51.phpbb.com/docs/dev/index.html covers core development, extensions and automated testing.

Because the ticket precedes the code, a fork started before the tracker has an entry can end up with a pull request that nobody is watching. Security reports follow a different path: SECURITY.md sits at the repository root, outside the public ticket flow, and README.md does not describe what it contains. Day to day development discussion happens on the area51 forum rather than in the tracker, which is where a contributor learns whether a change has already been rejected.

Editorial conclusion

phpBB suits a self-hosted forum operator who is comfortable reading the area51 development documentation and running the composer dependency step, and it does not suit a quick hosted setup, because the pre-built package from phpBB.com skips the clone and install path the README documents for contributors. Before committing to the source tree, confirm that your PHP and database versions match what the Vagrant or Codespaces environment supplies, since README.md names no system requirements, and check tracker.phpbb.com for an existing ticket before sending a pull request to master.

Frequently asked questions

Official sources

1. Issues
2. License: GPL-2.0
3. phpbb/phpbb on GitHub
4. Project website
5. README