The directory-structure in Silverstripe is built on "convention over configuration", so the placement of some files and directories is meaningful to its logic.
|Webserver public webroot|
|Images and other files uploaded via the Silverstripe CMS. You can also place your own content inside it, and link to it from within the content area of the CMS.|
|Default location for protected assets|
|Exposed public files added from modules. Folders within this parent will match that of the source root location (this can be altered by configuration).|
|Silverstripe modules and other supporting libraries (e.g. the framework is in |
|Standard theme installation location|
Custom Code Structure
app/ as the default folder.
|This directory contains all of your code that defines your website.|
|YAML configuration specific to your application|
|PHP code specific to your application (subdirectories are optional)|
|PHP unit/functional/end-to-end tests|
|HTML templates with |
|Contains yaml translation tables|
|Custom nested themes (note: theme structure is described below)|
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
--- Name: myspecialapp --- SilverStripe\Core\Manifest\ModuleManifest: project: 'myspecialapp'
|Standard "simple" theme|
|Custom theme base directory|
|Theme CSS files|
Modules are commonly stored as composer packages in the
vendor/ folder. They need to have a
_config.php file or
_config/ directory present, and should follow the same conventions as posed in "Custom Site Structure".
Example for the silverstripe/blog module:
|This directory contains all of your code that defines the module.|
|YAML configuration specific to the module|
|PHP code specific to the module (subdirectories are optional)|
Module developers can bundle developer documentation with their code by producing plain text files inside a
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.
docs/ folder, developers should organise the markdown files into each separate language they wish to write
documentation for (e.g.
en for english documentation). Inside each languages' subfolder, developers then have freedom to create whatever
structure they wish for organising the documentation they wish.
Example Blog Documentation:
|Empty file to signify that Silverstripe does not need to load classes from this folder|
|Documentation homepage. Should provide an introduction and links to remaining docs|
|Documentation page. Naming convention is Uppercase and underscores.|
|Folder to store any images or media|
|You can organise documentation into nested folders. Naming convention is Uppercase and underscores.|
|Structure is created by use of numbered prefixes. This applies to nested folders and documentations pages, |
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
flush=1 query parameter. See the "Manifests" documentation for
Making /assets readonly
See Secure coding