In PhpStorm, content is a collection of files with which you are currently working, possibly organized in a hierarchy of subfolders. The folder which is the highest in this hierarchy is called the content root folder or content root (shown as ) for short. A project has at least one content root folder which by default is the project folder itself.
Having several content roots enables you to work with files from several directories that do not have a common immediate parent. This is helpful when you use static contents, for example, icons. You can just save them all in a folder and then specify this folder as an extra content root in several projects.
Content root types
By default, all the files in a content root folder are involved in indexing, searching, parsing, code completion, etc. To change this status, folders within a content root can be assigned to the following categories:
- Source roots (or source folders; shown as ).
This is the root for namespaces used in your project.
Based on this setting, PhpStorm suggests the proper folder name when you want to create a new namespace under another parent namespace during creation or moving a PHP class, that is, when you are actually creating or moving a PHP class to a non-existing namespace under another parent namespace. If no Sources folder is specified, you will have to type the proper folder manually.
- Test source roots (or test source folders; shown as ).
- Resource roots (or resource folders; shown as ).
By assigning a folder to this category, you tell PhpStorm that files in it and in its subfolders can be referenced relative to this folder instead of specifying full paths to them.
- Excluded roots (shown as ) are ones that PhpStorm "almost ignores".
These roots contain files and folders ignored by PhpStorm when indexing, searching, parsing, watching etc.
Excluded roots are not visible to PhpStorm. Usually, one would like to exclude temporary build folders, generated output, logs, and other project output. Excluding the unnecessary paths is a good way to significantly improve performance.
Modules without content roots: Collections of dependencies
A module can be used solely as a collection of dependencies for other modules. In such cases, instead of specifying the necessary dependencies separately, you can add the dependency on the corresponding module.
A module used for such purpose, obviously, doesn't need a content root.