Directory structure#

Introduction#

The directory-structure in Silverstripe is built on "convention over configuration", so the placement of some files and directories is meaningful to its logic.

Core structure#

Custom code structure#

We're using app/ as the default folder. Note that until Silverstripe 4.2, this directory was named mysite/, and PHP code was stored in a code/ rather than src/ folder.

Arbitrary directory-names are allowed, as long as they don't collide with existing modules or the directories lists in "Core Structure". Here's how you would reconfigure your default folder to myspecialapp.

# myspecialapp/_config/config.yml
---
Name: myspecialapp
---
SilverStripe\Core\Manifest\ModuleManifest:
    project: 'myspecialapp'

Check our JavaScript Coding Conventions for more details on folder and file naming in Silverstripe core modules.

Themes structure#

See themes.

Module structure#

Modules are commonly stored as composer packages in the vendor/ folder. They need to have a _config.php file or a _config/ directory present, and should follow the same conventions as posed in "Custom Site Structure".

Example Forum:

Note: Before Silverstripe 4.x, modules were living as top-level folders in the webroot itself. Some modules might not have been upgraded to support placement in vendor/.

Module documentation#

Module developers can bundle developer documentation with their code by producing plain text files inside a 'docs' folder located in the module folder. These files can be written with the Markdown syntax (see Contributing Documentation) and include media such as images or videos.

Inside the docs/ folder, developers should organise the markdown files into each separate language they wish to write documentation for (usually just en). Inside each languages' subfolder, developers then have freedom to create whatever structure they wish for organising the documentation they wish.

Example Blog Documentation:

Autoloading#

Silverstripe recursively detects classes in PHP files by building up a manifest used for autoloading, as well as respecting Composer's built-in autoloading for libraries. This means in most cases, you don't need to worry about include paths or require() calls in your own code - after adding a new class, simply regenerate the manifest by using a flush=1 query parameter. See the "Manifests" documentation for details.

Best practices#

Making /assets readonly#

See Secure coding