silverstripe-framework: the MVC base Silverstripe CMS is built on

The framework is a base, not a product you install

Silverstripe Framework is a PHP framework forming the base for the Silverstripe CMS, and the project description says so without hedging.

The important sentence is the second one. It requires a silverstripe-installer base project, and it is typically used alongside the cms module. So the framework is not a standalone MVC framework you can composer require and start using, and any expectation of that kind will end in a directory with no bootstrap.

That is a deliberate structure rather than an awkward one. The installer provides the skeleton project, the framework provides the MVC machinery, and the cms module provides the administration interface and the content editing experience. The three are versioned and released together, which is what makes the module conventions reliable, and the README carries a Silverstripe supported module badge pointing at the list of commercially supported modules.

The link structure in the README makes the shape of the ecosystem visible. There are separate bug trackers for the Framework, for the CMS and for the Installer, and separate changelogs. The forums and a developer mailing list sit alongside those. And the contributing section points at an extensive guide to contributing code, which tells you that a codebase of this size expects outside contributions rather than occasional patches.

So the framework is best understood as the engine of a three-part product that is developed and versioned as a unit, and choosing it means choosing the whole arrangement.

What you actually clone, and what the tooling directories signal

The README is thin on this project by design, so the repository's own file list is the more informative document. The top level entries are:

Reading that list as a set of answers to what a Silverstripe project contains, several things stand out.

The client/ directory next to src/ is the clearest signal. A framework that keeps its JavaScript in a sibling directory rather than buried in the template assets is making a statement about how the front end is built and shipped, and it is a sign that the framework expects to be run as a modern asset pipeline rather than as a set of ad hoc script tags.

The lang/ directory alongside a .tx/ directory is the Transifex configuration, so the translations are managed on a platform rather than by hand, and the two together tell you internationalisation is a maintained concern rather than an afterthought. The composer.json at the root, with a lockfile implied by the absence of any other dependency manifest, means the project is Composer managed.

The static analysis and style files are worth noticing for a different reason. A phpcs.xml.dist and a phpstan.neon.dist at the root are the kind of thing a project adds once it has enough contributors that style disagreements become a problem. They encode the project's standards in a file that runs in CI, and the CI workflow badge in the README is what makes them bite.

The phpunit.xml.dist and tests/ directory follow the same pattern, with the .dist suffix being the PHPUnit convention for a configuration that developers are expected to copy rather than edit in place, which keeps the repository free of local overrides.

The remaining files are the ones a Silverstripe developer recognises immediately. The _config.php and _config/ pair is the configuration layer, _register_database.php handles the environment and database selection, and the silverstripe_version file carries the framework version. The bin/ directory holds the command line entry point that the installer and the CMS both call.

None of this is documented in prose in the README, which is why the directory listing is worth reading directly before you start.

Installation is a three project arrangement, not a composer require

The installation section of the README is three lines long, and it points at the getting started documentation rather than repeating it. The reason is that there is nothing to install here on its own.

The framework repository ships a set of directories and configuration files rather than a single installable artefact, and the framework is not among them as something you run. It is a library that the installer project consumes.

The framework requires a silverstripe-installer base project. The installer is a separate repository, and it is the thing you start from, because it provides the skeleton, the public/ directory, the environment handling and the wiring between the framework and the CMS. The framework then goes into that skeleton, and the cms module is typically added on top to give you the administration interface and the content editing tools.

So the practical sequence is: start from the installer, add the framework, add the CMS, and configure the database. The README's only job is to point you at the getting started page that walks through it.

That arrangement has a consequence for how you read the version numbers. Because the three repositories are released and versioned together, a framework version, a CMS version and an installer version form a matched set. The release list here shows 6.2.10, 6.3.0-rc1 and 6.2.11, and the CMS and installer have their own matching tags, which means you are not choosing a framework version in isolation but a coherent triple.

The bug tracker section makes the same point about where problems belong. Bugs are tracked on GitHub, but the links go to three separate trackers, one for the framework, one for the CMS and one for the installer, and the framework repository is where a framework bug belongs. The issue reporting guidelines are a separate document, which suggests the project cares about the quality of reports as much as the quantity.

For an evaluation, the practical sequence is to read the server requirements page first, because a framework with a specific PHP and database requirement rules out hosts before you write any code, and then to work through the getting started guide rather than trying to reconstruct the setup from the repository layout.

The repository layout shows how Silverstripe splits concerns

The top level of the repository describes the framework's structure more clearly than the README does, and a few entries are worth pointing at.

There is a src/ directory holding the PHP source, a client/ directory for the JavaScript side, a templates/ directory for the rendering templates, a lang/ directory for translations, and a tests/ directory with a phpunit.xml.dist at the root. There is a bin/ directory, which is the conventional home for the command line entry point in a PHP framework, and the framework's own database and configuration machinery sits in the root rather than in src.

The configuration files are the notable ones. There is a _config.php file at the top level and a _config/ directory, and the leading underscore is the Silverstripe convention that marks a file as a configuration artefact rather than a class. There is a _register_database.php, which is what tells the framework which database and environment it should connect to. And there is a silverstripe_version file, a plain file holding the version rather than a Composer-managed constant, which is how the framework reports its own version to the CMS and to the installer.

The tooling files show a well-resourced project. There is a phpcs.xml.dist for coding standards and a phpstan.neon.dist for static analysis, a phpunit.xml.dist for the test runner, a .editorconfig and a .gitattributes for formatting, a .tx/ directory which is the configuration for Transifex, the translation platform, and a composer.json at the root.

The presence of a Transifex configuration alongside a lang/ directory is the clearest signal that this is a product with a translation programme rather than a library with a few contributors. The .github/ directory and the CI workflow badge complete the picture.

Where to ask, and what the community surfaces suggest

The links section of the README is short and it tells you how the project is supported, which is worth knowing before you commit to the framework.

There is a forum, a developer mailing list, and a GitHub issue tracker per repository. The mailing list is a Google group, silverstrip-dev, which is the traditional channel for framework design discussions, and the forum is where the wider community asks questions. Neither is a support contract, and the framework is one of the Silverstripe supported modules, which is the commercially backed option if you need someone to answer.

The contribution guide is described as extensive, and that word is doing some work. A guide of that length usually means the project has a defined architecture, a code style, a review process and a test expectation, and a contribution that ignores them will be slow to merge no matter how good the code is.

Two pieces of the repository point at the same idea from different directions. The CI workflow badge and the phpcs and phpstan configurations mean that a pull request is checked automatically against the standards before a human sees it. The CODE_OF_CONDUCT.md, CODE_OF_CONDUCT-style file and the .github/ directory mean that the project also has the process side in place, which is what you would expect from a codebase that has been in continuous use for many years and has correspondingly many contributors.

The hacktoberfest topic tag is a small detail that says something about the project. It means the maintainers participate in the annual event, which implies a maintained issue backlog with labels suitable for newcomers, and it is a reasonable signal that the project can accept outside contributions in a structured way.

For a team evaluating the framework, the honest summary is that you are choosing a three-repository arrangement with a permissive licence, a mature release process and a real community, and the documentation rather than the repository is where the decisions you need to make are written down.

Editorial conclusion

silverstripe-framework suits a team committed to the Silverstripe CMS, because the framework and the CMS are released and versioned together and the module conventions are where most of the value is. It does not suit you as a standalone MVC framework, since the README is explicit that it requires a silverstripe-installer base project and is typically used alongside the cms module. Before you start, read the server requirements page rather than assuming a generic PHP host will do, and note that this repository is only one of three tracked separately, with the framework, the CMS and the installer each having their own bug tracker.

Frequently asked questions

Official sources

1. License: BSD-3-Clause
2. Project website
3. README
4. Releases
5. silverstripe/silverstripe-framework on GitHub