mirror of
https://github.com/silverstripe/silverstripe-framework
synced 2024-10-01 13:48:37 +02:00
Merge pull request #8212 from open-sausages/pulls/4/docs-app-folder-use
DOCS Consistent app/ folder and composer use
This commit is contained in:
Luke Edwards
GitHub
commit
a33a08091d
@ -79,7 +79,7 @@ The php installer needs to be able to write files during installation, which sho
|
||||
needs to create/have write-access to:
|
||||
|
||||
* The main installation directory (for creating .htaccess file and assets directory)
|
||||
* The mysite folder (to create _config.php)
|
||||
* The `app/` folder (to create _config.php)
|
||||
* After the install, the assets directory is the only directory that needs write access.
|
||||
* Image thumbnails will not show in the CMS if permission is not given
|
||||
|
||||
@ -103,7 +103,7 @@ You could enable other users to access these files with the below config.
|
||||
Note: Please adjust the values below to those appropriate for your server configuration.
|
||||
You may require `0666` for combined files generated during requests where they are cleared or refreshed only during a flush.
|
||||
|
||||
*mysite/_config/assetperms.yml*
|
||||
*app/_config/assetperms.yml*
|
||||
|
||||
```yaml
|
||||
---
|
||||
|
||||
@ -75,7 +75,7 @@ e.g. `/etc/nginx/sites-enabled/mysite`:
|
||||
server {
|
||||
listen 80;
|
||||
root /var/www/mysite/public;
|
||||
server_name www.mysite.com;
|
||||
server_name www.example.com;
|
||||
|
||||
error_log /var/log/nginx/mysite.error.log;
|
||||
access_log /var/log/nginx/mysite.access.log;
|
||||
|
||||
@ -51,14 +51,14 @@ Environment::setEnv('API_KEY', 'AABBCCDDEEFF012345');
|
||||
## Including an extra `.env` file
|
||||
|
||||
Sometimes it may be useful to include an extra `.env` file - on a shared local development environment where all
|
||||
database credentials could be the same. To do this, you can add this snippet to your `mysite/_config.php` file:
|
||||
database credentials could be the same. To do this, you can add this snippet to your `app/_config.php` file:
|
||||
|
||||
Note that by default variables cannot be overloaded from this file; Existing values will be preferred
|
||||
over values in this file.
|
||||
|
||||
```php
|
||||
use SilverStripe\Core\EnvironmentLoader;
|
||||
$env = BASE_PATH . '/mysite/.env';
|
||||
$env = BASE_PATH . '/app/.env';
|
||||
$loader = new EnvironmentLoader();
|
||||
$loader->loadFile($env);
|
||||
```
|
||||
|
||||
@ -17,21 +17,37 @@ Directory | Description
|
||||
|
||||
## Custom Code Structure
|
||||
|
||||
We're using `<mysite>` as an example - arbitrary directory-names are allowed, as long as they don't collide with
|
||||
existing modules or the directories lists in "Core 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.
|
||||
|
||||
| Directory | Description |
|
||||
| --------- | ----------- |
|
||||
| `<mysite>/` | This directory contains all of your code that defines your website. |
|
||||
| `<mysite>/_config` | YAML configuration specific to your application |
|
||||
| `<mysite>/src` | PHP code for model and controller (subdirectories are optional) |
|
||||
| `<mysite>/tests` | PHP Unit tests |
|
||||
| `<mysite>/templates` | HTML [templates](/developer_guides/templates) with *.ss-extension for the `$default` theme |
|
||||
| `<mysite>/css ` | CSS files |
|
||||
| `<mysite>/images ` | Images used in the HTML templates |
|
||||
| `<mysite>/javascript` | Javascript and other script files |
|
||||
| `<mysite>/client` | More complex projects can alternatively contain frontend assets in a common `client` folder |
|
||||
| `<mysite>/themes/<yourtheme>` | Custom nested themes (note: theme structure is described below) |
|
||||
| `app/` | This directory contains all of your code that defines your website. |
|
||||
| `app/_config` | YAML configuration specific to your application |
|
||||
| `app/src` | PHP code for model and controller (subdirectories are optional) |
|
||||
| `app/tests` | PHP Unit tests |
|
||||
| `app/templates` | HTML [templates](/developer_guides/templates) with *.ss-extension for the `$default` theme |
|
||||
| `app/css ` | CSS files |
|
||||
| `app/images ` | Images used in the HTML templates |
|
||||
| `app/javascript` | Javascript and other script files |
|
||||
| `app/client` | More complex projects can alternatively contain frontend assets in a common `client` folder |
|
||||
| `app/themes/<yourtheme>` | 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 `myspecialapp`.
|
||||
|
||||
*myspecialapp/_config/config.yml*
|
||||
|
||||
```yml
|
||||
---
|
||||
Name: myspecialapp
|
||||
---
|
||||
SilverStripe\Core\Manifest\ModuleManifest:
|
||||
project: 'myspecialapp'
|
||||
```
|
||||
|
||||
Check our [JavaScript Coding Conventions](javascript_coding_conventions) for more details
|
||||
on folder and file naming in SilverStripe core modules.
|
||||
@ -77,18 +93,18 @@ separate language they wish to write documentation for (usually just `en`). Insi
|
||||
each languages' subfolder, developers then have freedom to create whatever structure
|
||||
they wish for organising the documentation they wish.
|
||||
|
||||
Example Forum Documentation:
|
||||
Example Blog Documentation:
|
||||
|
||||
| Directory | Description |
|
||||
| --------- | ----------- |
|
||||
| `blog/docs` | |
|
||||
| `blog/docs/_manifest_exclude` | Empty file to signify that SilverStripe does not need to load classes from this folder |
|
||||
| `blog/docs/en/` | English documentation |
|
||||
| `blog/docs/en/index.md` | Documentation homepage. Should provide an introduction and links to remaining docs |
|
||||
| `blog/docs/en/Getting_Started.md` | Documentation page. Naming convention is Uppercase and underscores. |
|
||||
| `blog/docs/en/_images/` | Folder to store any images or media |
|
||||
| `blog/docs/en/Some_Topic/` | You can organise documentation into nested folders. Naming convention is Uppercase and underscores. |
|
||||
| `blog/docs/en/04_Some_Topic/00_Getting_Started.md`|Structure is created by use of numbered prefixes. This applies to nested folders and documentations pages, index.md should not have a prefix.|
|
||||
| `vendor/silverstripe/blog/docs` | |
|
||||
| `vendor/silverstripe/blog/docs/_manifest_exclude` | Empty file to signify that SilverStripe does not need to load classes from this folder |
|
||||
| `vendor/silverstripe/blog/docs/en/` | English documentation |
|
||||
| `vendor/silverstripe/blog/docs/en/index.md` | Documentation homepage. Should provide an introduction and links to remaining docs |
|
||||
| `vendor/silverstripe/blog/docs/en/Getting_Started.md` | Documentation page. Naming convention is Uppercase and underscores. |
|
||||
| `vendor/silverstripe/blog/docs/en/_images/` | Folder to store any images or media |
|
||||
| `vendor/silverstripe/blog/docs/en/Some_Topic/` | You can organise documentation into nested folders. Naming convention is Uppercase and underscores. |
|
||||
| `vendor/silverstripe/blog/docs/en/04_Some_Topic/00_Getting_Started.md`|Structure is created by use of numbered prefixes. This applies to nested folders and documentations pages, index.md should not have a prefix.|
|
||||
|
||||
|
||||
## Autoloading
|
||||
|
||||
@ -17,7 +17,7 @@ along with any [relationships](relations) defined as `$has_one`, `$has_many`, `$
|
||||
|
||||
Let's look at a simple example:
|
||||
|
||||
**mysite/code/Player.php**
|
||||
**app/code/Player.php**
|
||||
|
||||
```php
|
||||
use SilverStripe\ORM\DataObject;
|
||||
@ -73,7 +73,7 @@ automatically set on the `DataObject`.
|
||||
* Created: A date/time field set to the creation date of this record
|
||||
* LastEdited: A date/time field set to the date this record was last edited through `write()`
|
||||
|
||||
**mysite/code/Player.php**
|
||||
**app/code/Player.php**
|
||||
|
||||
```php
|
||||
use SilverStripe\ORM\DataObject;
|
||||
|
||||
@ -11,7 +11,7 @@ about how to store its data in the database and how to format the information co
|
||||
|
||||
In the `Player` example, we have four database columns each with a different data type (Int, Varchar).
|
||||
|
||||
**mysite/code/Player.php**
|
||||
**app/code/Player.php**
|
||||
|
||||
```php
|
||||
use SilverStripe\ORM\DataObject;
|
||||
@ -104,7 +104,7 @@ output. You can manually create instances of a Data Type and pass it through to
|
||||
If this case, we'll create a new method for our `Player` that returns the full name. By wrapping this in a [DBVarchar](api:SilverStripe\ORM\FieldType\DBVarchar)
|
||||
object we can control the formatting and it allows us to call methods defined from `Varchar` as `LimitCharacters`.
|
||||
|
||||
**mysite/code/Player.php**
|
||||
**app/code/Player.php**
|
||||
|
||||
```php
|
||||
use SilverStripe\ORM\FieldType\DBField;
|
||||
|
||||
@ -543,7 +543,7 @@ In templates, you don't need to worry about this distinction. The `$Content` var
|
||||
default, and only preview draft content if explicitly requested (e.g. by the "preview" feature in the CMS, or by adding ?stage=Stage to the URL). If you want
|
||||
to force a specific stage, we recommend the `Controller->init()` method for this purpose, for example:
|
||||
|
||||
**mysite/code/MyController.php**
|
||||
**app/code/MyController.php**
|
||||
```php
|
||||
public function init()
|
||||
{
|
||||
@ -569,7 +569,7 @@ You can opt for a session base stage setting through the `Versioned.use_session`
|
||||
Warning: This can lead to leaking of unpublished information, if a live URL is viewed in draft mode,
|
||||
and the result is cached due to agressive cache settings (not varying on cookie values).
|
||||
|
||||
*mysite/src/MyObject.php*
|
||||
*app/src/MyObject.php*
|
||||
|
||||
```php
|
||||
use SilverStripe\Core\Injector\Injector;
|
||||
@ -603,7 +603,7 @@ class MyObject extends DataObject {
|
||||
}
|
||||
```
|
||||
|
||||
*mysite/src/MyObjectController.php*
|
||||
*app/src/MyObjectController.php*
|
||||
|
||||
```php
|
||||
use SilverStripe\Control\Controller;
|
||||
@ -638,7 +638,7 @@ class MyObjectController extends Controller
|
||||
}
|
||||
```
|
||||
|
||||
*mysite/_config/routes.yml*
|
||||
*app/_config/routes.yml*
|
||||
|
||||
```yml
|
||||
SilverStripe\Control\Director:
|
||||
|
||||
@ -51,7 +51,7 @@ support the following:
|
||||
* `unique`: Index plus uniqueness constraint on the value
|
||||
* `fulltext`: Fulltext content index
|
||||
|
||||
**mysite/code/MyTestObject.php**
|
||||
**app/code/MyTestObject.php**
|
||||
|
||||
```php
|
||||
use SilverStripe\ORM\DataObject;
|
||||
|
||||
@ -9,7 +9,7 @@ processed through [SSViewer](api:SilverStripe\View\SSViewer). This process repla
|
||||
|
||||
An example of a SilverStripe template is below:
|
||||
|
||||
**mysite/templates/Page.ss**
|
||||
**app/templates/Page.ss**
|
||||
|
||||
```ss
|
||||
<html>
|
||||
@ -48,7 +48,7 @@ text-based format.
|
||||
## Template file location
|
||||
|
||||
SilverStripe templates are plain text files that have `.ss` extension and located within the `templates` directory of
|
||||
a module, theme, or your `mysite` folder.
|
||||
a module, theme, or your `app/` folder.
|
||||
|
||||
By default, templates will have the same name as the class they are used to render. So, your `Page` class will
|
||||
be rendered with the `templates/Page.ss` template.
|
||||
@ -98,7 +98,7 @@ For more detail around how variables are inserted and formatted into a template
|
||||
|
||||
Variables can come from your database fields, or custom methods you define on your objects.
|
||||
|
||||
**mysite/code/Page.php**
|
||||
**app/code/Page.php**
|
||||
|
||||
```php
|
||||
public function UsersIpAddress()
|
||||
@ -107,7 +107,7 @@ public function UsersIpAddress()
|
||||
}
|
||||
```
|
||||
|
||||
**mysite/code/Page.ss**
|
||||
**app/code/Page.ss**
|
||||
|
||||
```html
|
||||
<p>You are coming from $UsersIpAddress.</p>
|
||||
@ -122,7 +122,7 @@ object the methods get called on. For the standard `Page.ss` template the scope
|
||||
class. This object gives you access to all the database fields on [PageController](api:SilverStripe\CMS\Model\SiteTree\PageController), its corresponding [Page](api:SilverStripe\CMS\Model\SiteTree\Page)
|
||||
record and any subclasses of those two.
|
||||
|
||||
**mysite/code/Layout/Page.ss**
|
||||
**app/code/Layout/Page.ss**
|
||||
|
||||
```ss
|
||||
$Title
|
||||
|
||||
@ -349,7 +349,7 @@ of the `silverstripe/cms` module.
|
||||
<div class="info" markdown="1">
|
||||
To customise the markup that the `$Breadcrumbs` generates, copy `templates/BreadcrumbsTemplate.ss`
|
||||
from the `silverstripe/cms` module to
|
||||
`mysite/templates/BreadcrumbsTemplate.ss`, modify the newly copied template and flush your SilverStripe cache.
|
||||
`app/templates/BreadcrumbsTemplate.ss`, modify the newly copied template and flush your SilverStripe cache.
|
||||
</div>
|
||||
|
||||
## Forms
|
||||
|
||||
@ -176,7 +176,7 @@ You can also use any of the below options in order to tweak this behaviour:
|
||||
|
||||
In some cases it may be necessary to create a new storage backend for combined files, if the default location
|
||||
is not appropriate. Normally a single backend is used for all site assets, so a number of objects must be
|
||||
replaced. For instance, the below will set a new set of dependencies to write to `mysite/javascript/combined`
|
||||
replaced. For instance, the below will set a new set of dependencies to write to `app/javascript/combined`
|
||||
|
||||
|
||||
```yaml
|
||||
@ -194,7 +194,7 @@ SilverStripe\Core\Injector\Injector:
|
||||
SilverStripe\Assets\Flysystem\PublicAdapter.custom-adapter:
|
||||
class: SilverStripe\Assets\Flysystem\PublicAssetAdapter
|
||||
constructor:
|
||||
Root: ./mysite/javascript
|
||||
Root: ./app/javascript
|
||||
# Set flysystem filesystem that uses this adapter
|
||||
League\Flysystem\Filesystem.custom-filesystem:
|
||||
class: 'League\Flysystem\Filesystem'
|
||||
|
||||
@ -10,7 +10,7 @@ subclasses).
|
||||
|
||||
The following will render the given data into a template. Given the template:
|
||||
|
||||
**mysite/templates/Coach_Message.ss**
|
||||
**app/templates/Coach_Message.ss**
|
||||
|
||||
```ss
|
||||
<strong>$Name</strong> is the $Role on our team.
|
||||
@ -19,7 +19,7 @@ The following will render the given data into a template. Given the template:
|
||||
Our application code can render into that view using `renderWith`. This method is called on the [ViewableData](api:SilverStripe\View\ViewableData)
|
||||
instance with a template name or an array of templates to render.
|
||||
|
||||
**mysite/code/Page.php**
|
||||
**app/code/Page.php**
|
||||
|
||||
```php
|
||||
$arrayData = new SilverStripe\View\ArrayData([
|
||||
|
||||
@ -44,7 +44,7 @@ Our site looks mostly the same across both templates with just the main content
|
||||
footer and navigation will remain the same and we don't want to replicate this work across more than one spot. The
|
||||
`$Layout` function allows us to define the child template area which can be overridden.
|
||||
|
||||
**mysite/templates/Page.ss**
|
||||
**app/templates/Page.ss**
|
||||
|
||||
```ss
|
||||
<html>
|
||||
@ -62,7 +62,7 @@ footer and navigation will remain the same and we don't want to replicate this w
|
||||
</body>
|
||||
```
|
||||
|
||||
**mysite/templates/Layout/Page.ss**
|
||||
**app/templates/Layout/Page.ss**
|
||||
|
||||
```ss
|
||||
<p>You are on a $Title page</p>
|
||||
@ -70,7 +70,7 @@ footer and navigation will remain the same and we don't want to replicate this w
|
||||
$Content
|
||||
```
|
||||
|
||||
**mysite/templates/Layout/HomePage.ss**
|
||||
**app/templates/Layout/HomePage.ss**
|
||||
|
||||
```ss
|
||||
<h1>This is the homepage!</h1>
|
||||
@ -100,7 +100,7 @@ to determine resolution priority. This search is based on the following three co
|
||||
the module author, and does not normally need to be customised. This includes the `$project` and
|
||||
`$other_modules` placeholder values.
|
||||
- `SilverStripe\Core\Manifest\ModuleManifest.project` - The name of the `$project` module, which
|
||||
defaults to `mysite`.
|
||||
defaults to `app`.
|
||||
|
||||
### ThemeResourceLoader
|
||||
|
||||
@ -161,18 +161,10 @@ will only defer to our modules templates folder if not found elsewhere.
|
||||
|
||||
### Declaring project
|
||||
|
||||
It is a good idea to define one of your modules as the `project`. Commonly, this is the
|
||||
`mysite/` module, but there is nothing compulsory about that module name.
|
||||
|
||||
*myapp/_config/config.yml*
|
||||
|
||||
```yml
|
||||
---
|
||||
Name: myproject
|
||||
---
|
||||
SilverStripe\Core\Manifest\ModuleManifest:
|
||||
project: 'myapp'
|
||||
```
|
||||
The default project structure contains an `app/` folder,
|
||||
which also acts as as a module in terms of template priorities.
|
||||
See [/getting_started/directory_structure](Directory Structure)
|
||||
to find out how to rename this folder.
|
||||
|
||||
### About module "names"
|
||||
|
||||
|
||||
@ -34,7 +34,7 @@ As you've added new files to your SilverStripe installation, make sure you clear
|
||||
After installing the files through either method, update the current theme in SilverStripe. This can be done by
|
||||
altering the `SSViewer.themes` setting in a [config.yml](../configuration)
|
||||
|
||||
**mysite/_config/app.yml**
|
||||
**app/_config/app.yml**
|
||||
|
||||
```yaml
|
||||
SilverStripe\View\SSViewer:
|
||||
|
||||
@ -10,7 +10,7 @@ All objects that are being rendered in a template should be a [ViewableData](api
|
||||
For instance, if we provide a [DBHtmlText](api:SilverStripe\ORM\FieldType\DBHtmlText) instance to the template we can call the `FirstParagraph` method. This will
|
||||
output the result of the [DBHtmlText::FirstParagraph()](api:SilverStripe\ORM\FieldType\DBHtmlText::FirstParagraph()) method to the template.
|
||||
|
||||
**mysite/code/Page.ss**
|
||||
**app/code/Page.ss**
|
||||
|
||||
```ss
|
||||
$Content.FirstParagraph
|
||||
@ -44,7 +44,7 @@ your text instances. For other objects such as [DBDatetime](api:SilverStripe\ORM
|
||||
When rendering an object to the template such as `$Me` the `forTemplate` method is called. This method can be used to
|
||||
provide default template for an object.
|
||||
|
||||
**mysite/code/Page.php**
|
||||
**app/code/Page.php**
|
||||
|
||||
```php
|
||||
use SilverStripe\CMS\Model\SiteTree;
|
||||
@ -59,7 +59,7 @@ class Page extends SiteTree
|
||||
}
|
||||
```
|
||||
|
||||
**mysite/templates/Page.ss**
|
||||
**app/templates/Page.ss**
|
||||
|
||||
```ss
|
||||
$Me
|
||||
|
||||
@ -5,7 +5,7 @@ title: How to Create a Navigation Menu
|
||||
In this how-to, we'll create a simple menu which you can use as the primary navigation for your website. This outputs a
|
||||
top level menu with a nested second level using the `Menu` loop and a `Children` loop.
|
||||
|
||||
**mysite/templates/Page.ss**
|
||||
**app/templates/Page.ss**
|
||||
|
||||
```ss
|
||||
<ul>
|
||||
|
||||
@ -8,7 +8,7 @@ all your record, then wraps it in a [PaginatedList](api:SilverStripe\ORM\Paginat
|
||||
|
||||
The `PaginatedList` will automatically set up query limits and read the request for information.
|
||||
|
||||
**mysite/code/Page.php**
|
||||
**app/code/Page.php**
|
||||
|
||||
```php
|
||||
use SilverStripe\ORM\PaginatedList;
|
||||
@ -34,7 +34,7 @@ There are two ways to generate pagination controls: [PaginatedList::Pages()](api
|
||||
|
||||
The first step is to simply list the objects in the template:
|
||||
|
||||
**mysite/templates/Page.ss**
|
||||
**app/templates/Page.ss**
|
||||
|
||||
```ss
|
||||
<ul>
|
||||
@ -46,7 +46,7 @@ The first step is to simply list the objects in the template:
|
||||
By default this will display 10 pages at a time. The next step is to add pagination controls below this so the user can
|
||||
switch between pages:
|
||||
|
||||
**mysite/templates/Page.ss**
|
||||
**app/templates/Page.ss**
|
||||
|
||||
```ss
|
||||
<% if $PaginatedPages.MoreThanOnePage %>
|
||||
|
||||
@ -30,7 +30,7 @@ There are cases where this can be unhelpful. HTML anchors created from Ajax resp
|
||||
situations, you can disable anchor link rewriting by setting the `SSViewer.rewrite_hash_links` configuration value to
|
||||
`false`.
|
||||
|
||||
**mysite/_config/app.yml**
|
||||
**app/_config/app.yml**
|
||||
|
||||
```yml
|
||||
SilverStripe\View\SSViewer:
|
||||
|
||||
@ -6,7 +6,7 @@ summary: A brief look at the definition of a Controller, creating actions and ho
|
||||
The following example is for a simple [Controller](api:SilverStripe\Control\Controller) class. When building off the SilverStripe Framework you will
|
||||
subclass the base `Controller` class.
|
||||
|
||||
**mysite/code/controllers/TeamController.php**
|
||||
**app/code/controllers/TeamController.php**
|
||||
|
||||
```php
|
||||
use SilverStripe\Control\Controller;
|
||||
@ -47,11 +47,11 @@ routing.
|
||||
Make sure that after you have modified the `routes.yml` file, that you clear your SilverStripe caches using `?flush=1`.
|
||||
</div>
|
||||
|
||||
**mysite/_config/routes.yml**
|
||||
**app/_config/routes.yml**
|
||||
|
||||
```yml
|
||||
---
|
||||
Name: mysiteroutes
|
||||
Name: approutes
|
||||
After: framework/_config/routes#coreroutes
|
||||
---
|
||||
SilverStripe\Control\Director:
|
||||
@ -77,7 +77,7 @@ Action methods can return one of four main things:
|
||||
* an [HTTPResponse](api:SilverStripe\Control\HTTPResponse) containing a manually defined `status code` and `body`.
|
||||
* an [HTTPResponse_Exception](api:SilverStripe\Control\HTTPResponse_Exception). A special type of response which indicates an error. By returning the exception, the execution pipeline can adapt and display any error handlers.
|
||||
|
||||
**mysite/code/controllers/TeamController.php**
|
||||
**app/code/controllers/TeamController.php**
|
||||
|
||||
```php
|
||||
/**
|
||||
@ -163,7 +163,7 @@ For more information about templates, inheritance and how to render into views,
|
||||
Each controller should define a `Link()` method. This should be used to avoid hard coding your routing in views,
|
||||
as well as give other features in SilverStripe the ability to influence link behaviour.
|
||||
|
||||
**mysite/code/controllers/TeamController.php**
|
||||
**app/code/controllers/TeamController.php**
|
||||
|
||||
```php
|
||||
public function Link($action = null)
|
||||
|
||||
@ -15,11 +15,11 @@ routing.
|
||||
These routes by standard, go into a `routes.yml` file in your applications `_config` folder alongside your other
|
||||
[Configuration](../configuration) information.
|
||||
|
||||
**mysite/_config/routes.yml**
|
||||
**app/_config/routes.yml**
|
||||
|
||||
```yml
|
||||
---
|
||||
Name: mysiteroutes
|
||||
Name: approutes
|
||||
After:
|
||||
- '#rootroutes'
|
||||
- '#coreroutes'
|
||||
@ -158,7 +158,7 @@ you can specify these in your Controller class via the **$url_handlers** static
|
||||
This is useful when you want to provide custom actions for the mapping of `teams/*`. Say for instance we want to respond
|
||||
`coaches`, and `staff` to the one controller action `payroll`.
|
||||
|
||||
**mysite/code/controllers/TeamController.php**
|
||||
**app/code/controllers/TeamController.php**
|
||||
|
||||
```php
|
||||
use SilverStripe\Control\Controller;
|
||||
|
||||
@ -6,7 +6,7 @@ summary: Move users around your site using automatic redirection.
|
||||
Controllers can facilitate redirecting users from one place to another using `HTTP` redirection using the `Location`
|
||||
HTTP header.
|
||||
|
||||
**mysite/code/Page.php**
|
||||
**app/code/Page.php**
|
||||
|
||||
|
||||
```php
|
||||
|
||||
@ -16,7 +16,7 @@ In addition, you should return an `HTTPResponse` object. In normal cases, this s
|
||||
`$response` object returned by `$delegate`, perhaps with some modification. However, sometimes you
|
||||
will deliberately return a different response, e.g. an error response or a redirection.
|
||||
|
||||
**mysite/code/CustomMiddleware.php**
|
||||
**app/code/CustomMiddleware.php**
|
||||
|
||||
```php
|
||||
use SilverStripe\Control\Middleware\HTTPMiddleware;
|
||||
@ -57,7 +57,7 @@ use of it.
|
||||
By adding the service or class name to the `Director.Middlewares` property via injector,
|
||||
array, a middleware will be executed on every request:
|
||||
|
||||
**mysite/_config/app.yml**
|
||||
**app/_config/app.yml**
|
||||
|
||||
|
||||
```yaml
|
||||
@ -77,7 +77,7 @@ SilverStripe\Core\Injector\Injector:
|
||||
Because these are service names, you can configure properties into a custom service if you would
|
||||
like:
|
||||
|
||||
**mysite/_config/app.yml**
|
||||
**app/_config/app.yml**
|
||||
|
||||
```yaml
|
||||
SilverStripe\Core\Injector\Injector:
|
||||
@ -99,7 +99,7 @@ as a replacement for your controller, and register it as a service with a `Middl
|
||||
property. The controller which does the work should be registered under the
|
||||
`RequestHandler` property.
|
||||
|
||||
**mysite/_config/app.yml**
|
||||
**app/_config/app.yml**
|
||||
|
||||
```yaml
|
||||
SilverStripe\Core\Injector\Injector:
|
||||
|
||||
@ -30,7 +30,7 @@ $form = new Form(
|
||||
|
||||
In practice, this looks like:
|
||||
|
||||
**mysite/code/PageController.php**
|
||||
**app/code/PageController.php**
|
||||
|
||||
```php
|
||||
use SilverStripe\CMS\Controllers\ContentController;
|
||||
@ -73,7 +73,7 @@ class PageController extends ContentController
|
||||
|
||||
```
|
||||
|
||||
**mysite/templates/Page.ss**
|
||||
**app/templates/Page.ss**
|
||||
|
||||
```ss
|
||||
$HelloForm
|
||||
|
||||
@ -92,7 +92,7 @@ two ways to go about this:
|
||||
A custom `FormField` which handles the validation. This means the `FormField` can be reused throughout the site and have
|
||||
the same validation logic applied to it throughout.
|
||||
|
||||
**mysite/code/CustomNumberField.php**
|
||||
**app/code/CustomNumberField.php**
|
||||
|
||||
```php
|
||||
use SilverStripe\Forms\TextField;
|
||||
|
||||
@ -16,7 +16,7 @@ $field = new TextField(..);
|
||||
$field->setTemplate('MyCustomTextField');
|
||||
```
|
||||
|
||||
Both `MyCustomTemplate.ss` and `MyCustomTextField.ss` should be located in **mysite/templates/** or the same directory as the core.
|
||||
Both `MyCustomTemplate.ss` and `MyCustomTextField.ss` should be located in **app/templates/** or the same directory as the core.
|
||||
|
||||
<div class="notice" markdown="1">
|
||||
It's recommended to copy the contents of the template you're going to replace and use that as a start. For instance, if
|
||||
|
||||
@ -12,7 +12,7 @@ Browsers without support receive an `<input type=text>` based polyfill.
|
||||
|
||||
The following example will add a simple DateField to your Page, allowing you to enter a date manually.
|
||||
|
||||
**mysite/code/Page.php**
|
||||
**app/code/Page.php**
|
||||
|
||||
|
||||
```php
|
||||
|
||||
@ -13,7 +13,7 @@ information about inserted images or media elements.
|
||||
The framework comes with a [HTMLEditorField](api:SilverStripe\Forms\HTMLEditor\HTMLEditorField) form field class which encapsulates most of the required
|
||||
functionality. It is usually added through the [DataObject::getCMSFields()](api:SilverStripe\ORM\DataObject::getCMSFields()) method:
|
||||
|
||||
**mysite/code/MyObject.php**
|
||||
**app/code/MyObject.php**
|
||||
|
||||
|
||||
```php
|
||||
@ -99,7 +99,7 @@ In its simplest form, the configuration of the editor includes adding and removi
|
||||
You can add plugins to the editor using the Framework's [HtmlEditorConfig::enablePlugins()](api:SilverStripe\Forms\HTMLEditor\HtmlEditorConfig::enablePlugins()) method. This will
|
||||
transparently generate the relevant underlying TinyMCE code.
|
||||
|
||||
**mysite/_config.php**
|
||||
**app/_config.php**
|
||||
|
||||
```php
|
||||
use SilverStripe\Forms\HTMLEditor\HtmlEditorConfig;
|
||||
@ -116,7 +116,7 @@ details).
|
||||
Plugins and advanced themes can provide additional buttons that can be added (or removed) through the
|
||||
configuration. Here is an example of adding a `ssmacron` button after the `charmap` button:
|
||||
|
||||
**mysite/_config.php**
|
||||
**app/_config.php**
|
||||
|
||||
```php
|
||||
HtmlEditorConfig::get('cms')->insertButtonsAfter('charmap', 'ssmacron');
|
||||
@ -124,7 +124,7 @@ HtmlEditorConfig::get('cms')->insertButtonsAfter('charmap', 'ssmacron');
|
||||
|
||||
Buttons can also be removed:
|
||||
|
||||
**mysite/_config.php**
|
||||
**app/_config.php**
|
||||
|
||||
```php
|
||||
HtmlEditorConfig::get('cms')->removeButtons('tablecontrols', 'blockquote', 'hr');
|
||||
@ -145,7 +145,7 @@ One example of the usage of this capability is to redefine the TinyMCE's [whitel
|
||||
tags](http://www.tinymce.com/wiki.php/Configuration:extended_valid_elements) - the tags that will not be stripped
|
||||
from the HTML source by the editor.
|
||||
|
||||
**mysite/_config.php**
|
||||
**app/_config.php**
|
||||
|
||||
```php
|
||||
// Add start and type attributes for <ol>, add <object> and <embed> with all attributes.
|
||||
@ -172,10 +172,10 @@ The default setting for the CMS's `extended_valid_elements` we are overriding he
|
||||
It is also possible to add custom plugins to TinyMCE, for example toolbar buttons.
|
||||
You can enable them through [HtmlEditorConfig::enablePlugins()](api:SilverStripe\Forms\HTMLEditor\HtmlEditorConfig::enablePlugins()):
|
||||
|
||||
**mysite/_config.php**
|
||||
**app/_config.php**
|
||||
|
||||
```php
|
||||
HtmlEditorConfig::get('cms')->enablePlugins(['myplugin' => '../../../mysite/javascript/myplugin/editor_plugin.js']);
|
||||
HtmlEditorConfig::get('cms')->enablePlugins(['myplugin' => '../../../app/javascript/myplugin/editor_plugin.js']);
|
||||
```
|
||||
|
||||
You can learn how to [create a plugin](http://www.tinymce.com/wiki.php/Creating_a_plugin) from the TinyMCE documentation.
|
||||
@ -288,7 +288,7 @@ Example: Remove field for "image captions"
|
||||
```php
|
||||
use SilverStripe\Core\Extension;
|
||||
|
||||
// File: mysite/code/MyToolbarExtension.php
|
||||
// File: app/code/MyToolbarExtension.php
|
||||
class MyToolbarExtension extends Extension
|
||||
{
|
||||
public function updateFieldsForImage(&$fields, $url, $file)
|
||||
@ -299,7 +299,7 @@ class MyToolbarExtension extends Extension
|
||||
```
|
||||
|
||||
```php
|
||||
// File: mysite/_config.php
|
||||
// File: app/_config.php
|
||||
use SilverStripe\Admin\ModalController;
|
||||
|
||||
ModalController::add_extension('MyToolbarExtension');
|
||||
@ -333,7 +333,7 @@ of the CMS you have to take care of instantiate yourself:
|
||||
use SilverStripe\Admin\ModalController;
|
||||
use SilverStripe\Control\Controller;
|
||||
|
||||
// File: mysite/code/MyController.php
|
||||
// File: app/code/MyController.php
|
||||
class MyObjectController extends Controller
|
||||
{
|
||||
public function Modals()
|
||||
@ -347,7 +347,7 @@ Note: The dialogs rely on CMS-access, e.g. for uploading and browsing files,
|
||||
so this is considered advanced usage of the field.
|
||||
|
||||
```php
|
||||
// File: mysite/_config.php
|
||||
// File: app/_config.php
|
||||
HtmlEditorConfig::get('cms')->disablePlugins('ssbuttons');
|
||||
HtmlEditorConfig::get('cms')->removeButtons('sslink', 'ssmedia');
|
||||
HtmlEditorConfig::get('cms')->addButtonsToLine(2, 'link', 'media');
|
||||
|
||||
@ -27,7 +27,7 @@ a `GridField` has almost no functionality. The `GridFieldConfig` instance and th
|
||||
responsible for all the user interactions including formatting data to be readable, modifying data and performing any
|
||||
actions such as deleting records.
|
||||
|
||||
**mysite/code/Page.php**
|
||||
**app/code/Page.php**
|
||||
|
||||
|
||||
```php
|
||||
@ -63,7 +63,7 @@ This will display a bare bones `GridField` instance under `Pages` tab in the CMS
|
||||
The configuration of those `GridFieldComponent` instances and the addition or subtraction of components is done through
|
||||
the `getConfig()` method on `GridField`.
|
||||
|
||||
**mysite/code/Page.php**
|
||||
**app/code/Page.php**
|
||||
|
||||
|
||||
```php
|
||||
|
||||
@ -7,7 +7,7 @@ to reuse the `Form` across multiple `Controller` classes rather than just one. A
|
||||
code for a `Form` is to create it as a subclass to `Form`. Let's look at a example of a `Form` which is on our
|
||||
`Controller` but would be better written as a subclass.
|
||||
|
||||
**mysite/code/Page.php**
|
||||
**app/code/Page.php**
|
||||
|
||||
|
||||
```php
|
||||
@ -75,7 +75,7 @@ class PageController extends ContentController
|
||||
Now that is a bit of code to include on our controller and generally makes the file look much more complex than it
|
||||
should be. Good practice would be to move this to a subclass and create a new instance for your particular controller.
|
||||
|
||||
**mysite/code/forms/SearchForm.php**
|
||||
**app/code/forms/SearchForm.php**
|
||||
|
||||
```php
|
||||
use SilverStripe\Forms\FieldList;
|
||||
@ -147,7 +147,7 @@ class SearchForm extends Form
|
||||
|
||||
Our controller will now just have to create a new instance of this form object. Keeping the file light and easy to read.
|
||||
|
||||
**mysite/code/Page.php**
|
||||
**app/code/Page.php**
|
||||
|
||||
|
||||
```php
|
||||
|
||||
@ -9,7 +9,7 @@ For example, a basic search form. We want to use the [Form](api:SilverStripe\For
|
||||
totally custom template to meet our needs. To do this, we'll provide the class with a unique template through
|
||||
`setTemplate`.
|
||||
|
||||
**mysite/code/Page.php**
|
||||
**app/code/Page.php**
|
||||
|
||||
|
||||
```php
|
||||
@ -30,7 +30,7 @@ public function SearchForm()
|
||||
}
|
||||
```
|
||||
|
||||
**mysite/templates/Includes/SearchForm.ss**
|
||||
**app/templates/Includes/SearchForm.ss**
|
||||
|
||||
|
||||
```ss
|
||||
|
||||
@ -100,7 +100,7 @@ class ContactPageController extends PageController
|
||||
{
|
||||
$email = new Email();
|
||||
|
||||
$email->setTo('siteowner@mysite.com');
|
||||
$email->setTo('test@example.com');
|
||||
$email->setFrom($data['Email']);
|
||||
$email->setSubject("Contact Message from {$data["Name"]}");
|
||||
|
||||
|
||||
@ -25,7 +25,7 @@ Configuration values are static properties on any SilverStripe class. These shou
|
||||
marked with a `@config` docblock. The API documentation will also list the static properties for the class. They should
|
||||
be marked `private static` and follow the `lower_case_with_underscores` structure.
|
||||
|
||||
**mysite/code/MyClass.php**
|
||||
**app/code/MyClass.php**
|
||||
|
||||
|
||||
```php
|
||||
@ -62,7 +62,7 @@ $config = $this->config()->get('property')';
|
||||
|
||||
You may need to apply the [Configurable](api:SilverStripe\Core\Config\Configurable) trait in order to access the `config()` method.
|
||||
|
||||
**mysite/code/MyOtherClass.php**
|
||||
**app/code/MyOtherClass.php**
|
||||
|
||||
```php
|
||||
use SilverStripe\Core\Config\Configurable;
|
||||
@ -94,7 +94,7 @@ And mutable methods:
|
||||
|
||||
To set those configuration options on our previously defined class we can define it in a `YAML` file.
|
||||
|
||||
**mysite/_config/app.yml**
|
||||
**app/_config/app.yml**
|
||||
|
||||
|
||||
```yml
|
||||
@ -210,7 +210,7 @@ directory you can add YAML files that contain values for the configuration syste
|
||||
|
||||
<div class="info" markdown="1">
|
||||
The name of the files within the applications `_config` directly are arbitrary. Our examples use
|
||||
`mysite/_config/app.yml` but you can break this file down into smaller files, or clearer patterns like `extensions.yml`,
|
||||
`app/_config/app.yml` but you can break this file down into smaller files, or clearer patterns like `extensions.yml`,
|
||||
`email.yml` if you want. For add-on's and modules, it is recommended that you name them with `<module_name>.yml`.
|
||||
</div>
|
||||
|
||||
|
||||
@ -35,7 +35,7 @@ echo $config->Title;
|
||||
|
||||
To extend the options available in the panel, define your own fields via a [DataExtension](api:SilverStripe\ORM\DataExtension).
|
||||
|
||||
**mysite/code/extensions/CustomSiteConfig.php**
|
||||
**app/code/extensions/CustomSiteConfig.php**
|
||||
|
||||
|
||||
```php
|
||||
@ -61,7 +61,7 @@ class CustomSiteConfig extends DataExtension
|
||||
|
||||
Then activate the extension.
|
||||
|
||||
**mysite/_config/app.yml**
|
||||
**app/_config/app.yml**
|
||||
|
||||
|
||||
```yml
|
||||
|
||||
@ -6,18 +6,18 @@ summary: Extend core functionality with modules.
|
||||
SilverStripe is designed to be a modular application system - even the CMS is simply a module that plugs into the core
|
||||
framework.
|
||||
|
||||
A module is a collection of classes, templates, and other resources that is loaded into a top-level directory such as
|
||||
the `framework`, `cms` or `mysite` folders. The only thing that identifies a folder as a SilverStripe module is the
|
||||
existence of a `_config` directory or `_config.php` at the top level of the directory.
|
||||
A module is a collection of classes, templates, and other resources that is loaded into a directory.
|
||||
Usually this directory is a [Composer package](https://getcomposer.org/), which is placed in the `vendor/` folder.
|
||||
SilverStripe modulies are just Composer packages with a toplevel `_config` directory or `_config.php` file.
|
||||
|
||||
```
|
||||
mysite/
|
||||
app/
|
||||
|
|
||||
+-- _config/
|
||||
+-- src/
|
||||
+-- ..
|
||||
|
|
||||
my_custom_module/
|
||||
vendor/my_vendor/my_module/
|
||||
|
|
||||
+-- _config/
|
||||
+-- ...
|
||||
@ -26,11 +26,6 @@ my_custom_module/
|
||||
SilverStripe will automatically include any PHP classes and templates from within your module when you next flush your
|
||||
cache.
|
||||
|
||||
<div class="info" markdown="1">
|
||||
In a default SilverStripe installation, even resources in `framework` and `mysite` are treated in exactly the same as
|
||||
every other module. Order of priority is usually alphabetical unless stated.
|
||||
</div>
|
||||
|
||||
Creating a module is a good way to re-use abstract code and templates across multiple projects. SilverStripe already
|
||||
has certain modules included, for example the `cms` module and core functionality such as commenting and spam protection
|
||||
are also abstracted into modules allowing developers the freedom to choose what they want.
|
||||
@ -44,20 +39,7 @@ are also abstracted into modules allowing developers the freedom to choose what
|
||||
|
||||
## Installation
|
||||
|
||||
Modules should exist in the root folder of your SilverStripe installation.
|
||||
|
||||
<div class="info" markdown="1">
|
||||
The root directory is the one containing the *framework* and *mysite* subdirectories. If your site is installed under
|
||||
`/Users/sam.minnee/Sites/website/` your modules will go in the `/Users/sam.minnee/Sites/website/` directory.
|
||||
</div>
|
||||
|
||||
<div class="notice" markdown="1">
|
||||
After you add or remove modules, make sure you rebuild the database, class and configuration manifests by going to http://yoursite.com/dev/build?flush=1
|
||||
</div>
|
||||
|
||||
### From Composer
|
||||
|
||||
Our preferred way to manage module dependencies is through the [Composer](http://getcomposer.org) package manager. It
|
||||
Modules are installed through the [Composer](http://getcomposer.org) package manager. It
|
||||
enables you to install modules from specific versions, checking for compatibilities between modules and even allowing
|
||||
to track development branches of them. To install modules using this method, you will first need to setup SilverStripe
|
||||
with [Composer](../../getting_started/composer).
|
||||
@ -77,27 +59,12 @@ tag name.
|
||||
composer require silverstripe/blog 1.1.0
|
||||
```
|
||||
|
||||
<div class="info" markdown="1">
|
||||
For more information on using Composer version constraints, please [see here](https://getcomposer.org/doc/articles/versions.md). To lock down to a specific version, branch or commit, read up on
|
||||
[Composer "lock" files](http://getcomposer.org/doc/01-basic-usage.md#composer-lock-the-lock-file).
|
||||
</div>
|
||||
|
||||
## From an Archive Download
|
||||
|
||||
<div class="alert" markdown="1">
|
||||
Some modules might not work at all with this approach since they rely on the
|
||||
Composer [autoloader](http://getcomposer.org/doc/01-basic-usage.md#autoloading), additional modules or post-install
|
||||
hooks, so we recommend using Composer.
|
||||
</div>
|
||||
|
||||
Alternatively, you can download the archive file from the [modules page](http://www.silverstripe.org/modules) and
|
||||
extract it to the root folder mentioned above.
|
||||
Composer is using [version constraints](https://getcomposer.org/doc/articles/versions.md).
|
||||
To lock down to a specific version, branch or commit, read up on
|
||||
["lock" files](http://getcomposer.org/doc/01-basic-usage.md#composer-lock-the-lock-file).
|
||||
|
||||
<div class="notice" markdown="1">
|
||||
The main folder extracted from the archive might contain the version number or additional "container" folders above the
|
||||
actual module codebase. You need to make sure the folder name is the correct name of the module (e.g. "blog/" rather
|
||||
than "silverstripe-blog/"). This folder should contain a `_config/` directory. While the module might register and
|
||||
operate in other structures, paths to static files such as CSS or JavaScript won't work.
|
||||
After you add or remove modules, make sure you rebuild the database, class and configuration manifests by going to http://yoursite.com/dev/build?flush=1
|
||||
</div>
|
||||
|
||||
## Publishing your own SilverStripe module
|
||||
|
||||
@ -15,7 +15,7 @@ For performance reasons a few classes are excluded from receiving extensions, in
|
||||
and `RequestHandler`. You can still apply extensions to descendants of these classes.
|
||||
</div>
|
||||
|
||||
**mysite/code/extensions/MyMemberExtension.php**
|
||||
**app/code/extensions/MyMemberExtension.php**
|
||||
|
||||
|
||||
```php
|
||||
@ -43,7 +43,7 @@ Convention is for extension class names to end in `Extension`. This isn't a requ
|
||||
After this class has been created, it does not yet apply it to any object. We need to tell SilverStripe what classes
|
||||
we want to add the `MyMemberExtension` too. To activate this extension, add the following via the [Configuration API](../configuration).
|
||||
|
||||
**mysite/_config/app.yml**
|
||||
**app/_config/app.yml**
|
||||
|
||||
|
||||
```yml
|
||||
@ -76,7 +76,7 @@ Extra database fields can be added with a extension in the same manner as if the
|
||||
they're applied to. These will be added to the table of the base object - the extension will actually edit the $db,
|
||||
$has_one etc.
|
||||
|
||||
**mysite/code/extensions/MyMemberExtension.php**
|
||||
**app/code/extensions/MyMemberExtension.php**
|
||||
|
||||
|
||||
```php
|
||||
@ -101,7 +101,7 @@ class MyMemberExtension extends DataExtension
|
||||
}
|
||||
```
|
||||
|
||||
**mysite/templates/Page.ss**
|
||||
**app/templates/Page.ss**
|
||||
|
||||
|
||||
```ss
|
||||
@ -114,14 +114,14 @@ $CurrentMember.Image
|
||||
Methods that have a unique name will be called as part of the `__call` method on [Object](api:Object). In the previous example
|
||||
we added a `SayHi` method which is unique to our extension.
|
||||
|
||||
**mysite/templates/Page.ss**
|
||||
**app/templates/Page.ss**
|
||||
|
||||
```ss
|
||||
<p>$CurrentMember.SayHi</p>
|
||||
// "Hi Sam"
|
||||
```
|
||||
|
||||
**mysite/code/Page.php**
|
||||
**app/code/Page.php**
|
||||
|
||||
```php
|
||||
use SilverStripe\Security\Security;
|
||||
@ -157,7 +157,7 @@ variables at that given point. In this case, the core function `getValidator` on
|
||||
`updateValidator` hook for developers to modify the core method. The `MyMemberExtension` would modify the core member's
|
||||
validator by defining the `updateValidator` method.
|
||||
|
||||
**mysite/code/extensions/MyMemberExtension.php**
|
||||
**app/code/extensions/MyMemberExtension.php**
|
||||
|
||||
|
||||
```php
|
||||
|
||||
@ -48,7 +48,7 @@ ShortcodeParser::get_active()->parse($text);
|
||||
|
||||
First we need to define a callback for the shortcode.
|
||||
|
||||
**mysite/code/Page.php**
|
||||
**app/code/Page.php**
|
||||
|
||||
|
||||
```php
|
||||
@ -81,7 +81,7 @@ These parameters are passed to the `MyShortCodeMethod` callback:
|
||||
|
||||
To register a shortcode you call the following.
|
||||
|
||||
**mysite/_config.php**
|
||||
**app/_config.php**
|
||||
|
||||
|
||||
```php
|
||||
|
||||
@ -28,7 +28,7 @@ $object = Injector::inst()->create('MyClassName');
|
||||
The benefit of constructing objects through this syntax is `ClassName` can be swapped out using the
|
||||
[Configuration API](../configuration) by developers.
|
||||
|
||||
**mysite/_config/app.yml**
|
||||
**app/_config/app.yml**
|
||||
|
||||
```yml
|
||||
SilverStripe\Core\Injector\Injector:
|
||||
@ -104,7 +104,7 @@ echo (is_string($object->textProperty));
|
||||
|
||||
The [Configuration YAML](../configuration) does the hard work of configuring those `$dependencies` for us.
|
||||
|
||||
**mysite/_config/app.yml**
|
||||
**app/_config/app.yml**
|
||||
|
||||
```yml
|
||||
Injector:
|
||||
@ -160,7 +160,7 @@ the `factory` key in the service definition, and the factory service will be use
|
||||
|
||||
An example using the `MyFactory` service to create instances of the `MyService` service is shown below:
|
||||
|
||||
**mysite/_config/app.yml**
|
||||
**app/_config/app.yml**
|
||||
|
||||
```yml
|
||||
SilverStripe\Core\Injector\Injector:
|
||||
@ -168,7 +168,7 @@ SilverStripe\Core\Injector\Injector:
|
||||
factory: MyFactory
|
||||
```
|
||||
|
||||
**mysite/code/MyFactory.php**
|
||||
**app/code/MyFactory.php**
|
||||
|
||||
|
||||
```php
|
||||
@ -189,7 +189,7 @@ $instance = Injector::inst()->get('MyService');
|
||||
|
||||
To override the `$dependency` declaration for a class, define the following configuration file.
|
||||
|
||||
**mysite/_config/app.yml**
|
||||
**app/_config/app.yml**
|
||||
|
||||
```yml
|
||||
MyController:
|
||||
|
||||
@ -43,7 +43,7 @@ This doesn't cover all cases used by SilverStripe so is not a complete solution,
|
||||
used.
|
||||
</div>
|
||||
|
||||
**mysite/code/MySQLWriteDbAspect.php**
|
||||
**app/code/MySQLWriteDbAspect.php**
|
||||
|
||||
|
||||
```php
|
||||
@ -77,7 +77,7 @@ class MySQLWriteDbAspect implements BeforeCallAspect
|
||||
To actually make use of this class, a few different objects need to be configured. First up, define the `writeDb`
|
||||
object that's made use of above.
|
||||
|
||||
**mysite/_config/app.yml**
|
||||
**app/_config/app.yml**
|
||||
|
||||
|
||||
```yml
|
||||
@ -97,7 +97,7 @@ of type `MySQLDatabase`, configured to point at the 'write_database'.
|
||||
|
||||
Next, this should be bound into an instance of the `Aspect` class
|
||||
|
||||
**mysite/_config/app.yml**
|
||||
**app/_config/app.yml**
|
||||
|
||||
```yml
|
||||
SilverStripe\Core\Injector\Injector:
|
||||
@ -108,7 +108,7 @@ SilverStripe\Core\Injector\Injector:
|
||||
|
||||
Next, we need to define the database connection that will be used for all non-write queries
|
||||
|
||||
**mysite/_config/app.yml**
|
||||
**app/_config/app.yml**
|
||||
|
||||
```yml
|
||||
SilverStripe\Core\Injector\Injector:
|
||||
@ -125,7 +125,7 @@ SilverStripe\Core\Injector\Injector:
|
||||
The final piece that ties everything together is the [AopProxyService](api:SilverStripe\Core\Injector\AopProxyService) instance that will be used as the replacement
|
||||
object when the framework creates the database connection.
|
||||
|
||||
**mysite/_config/app.yml**
|
||||
**app/_config/app.yml**
|
||||
|
||||
```yml
|
||||
SilverStripe\Core\Injector\Injector:
|
||||
@ -146,7 +146,7 @@ defined method\_name
|
||||
|
||||
Overall configuration for this would look as follows
|
||||
|
||||
**mysite/_config/app.yml**
|
||||
**app/_config/app.yml**
|
||||
|
||||
```yml
|
||||
SilverStripe\Core\Injector\Injector:
|
||||
|
||||
@ -12,31 +12,35 @@ of your module containing the meta-data about your module.
|
||||
For more information about what your `composer.json` file should include, consult the
|
||||
[Composer Documentation](http://getcomposer.org/doc/01-basic-usage.md).
|
||||
|
||||
A basic usage of a module for 3.1 that requires the CMS would look similar to
|
||||
this:
|
||||
|
||||
**mycustommodule/composer.json**
|
||||
|
||||
```json
|
||||
{
|
||||
"name": "your-vendor-name/module-name",
|
||||
"name": "my-vendor/my-module",
|
||||
"description": "One-liner describing your module",
|
||||
"type": "silverstripe-module",
|
||||
"homepage": "http://github.com/your-vendor-name/module-name",
|
||||
"homepage": "http://github.com/my-vendor/my-module",
|
||||
"keywords": ["silverstripe", "some-tag", "some-other-tag"],
|
||||
"license": "BSD-3-Clause",
|
||||
"authors": [
|
||||
{"name": "Your Name","email": "your@email.com"}
|
||||
],
|
||||
"support": {
|
||||
"issues": "http://github.com/your-vendor-name/module-name/issues"
|
||||
"issues": "http://github.com/my-vendor/my-module/issues"
|
||||
},
|
||||
"require": {
|
||||
"silverstripe/cms": "^4",
|
||||
"silverstripe/framework": "^4"
|
||||
},
|
||||
"autoload": {
|
||||
"psr-4": {
|
||||
"MyVendor\\MyModule\\": "src/"
|
||||
}
|
||||
},
|
||||
"extra": {
|
||||
"installer-name": "module-name",
|
||||
"installer-name": "my-module",
|
||||
"expose": [
|
||||
"client"
|
||||
],
|
||||
"screenshots": [
|
||||
"relative/path/screenshot1.png",
|
||||
"http://myhost.com/screenshot2.png"
|
||||
@ -45,48 +49,19 @@ this:
|
||||
}
|
||||
```
|
||||
|
||||
Once your module is published online with a service like Github.com or Bitbucket.com, submit the repository to
|
||||
|
||||
|
||||
Once your module is published online with a service like github.com or bitbucket.com, submit the repository to
|
||||
[Packagist](https://packagist.org/) to have the module accessible to developers. It'll automatically get picked
|
||||
up by [addons.silverstripe.org](http://addons.silverstripe.org/) website.
|
||||
up by [addons.silverstripe.org](http://addons.silverstripe.org/) website due to the `silverstripe` keyword in the file.
|
||||
|
||||
## Vendor modules
|
||||
Note that SilverStripe modules have the following distinct characteristics:
|
||||
|
||||
By default `silverstripe-module` type libraries are installed to the root web folder, however a new type
|
||||
`silverstripe-vendormodule` allows you to publish your module to the vendor directory.
|
||||
|
||||
The below is an example of a vendor module composer.json:
|
||||
|
||||
```json
|
||||
{
|
||||
"name": "tractorcow/test-vendor-module",
|
||||
"description": "Test module for silverstripe/vendor-plugin",
|
||||
"type": "silverstripe-vendormodule",
|
||||
"require": {
|
||||
"silverstripe/vendor-plugin": "^1.0",
|
||||
"silverstripe/cms": "^4.0"
|
||||
},
|
||||
"license": "BSD-3-Clause",
|
||||
"autoload": {
|
||||
"psr-4": {
|
||||
"TractorCow\\TestVendorModule\\": "src/"
|
||||
}
|
||||
},
|
||||
"extra": {
|
||||
"expose": [
|
||||
"client"
|
||||
]
|
||||
},
|
||||
"minimum-stability": "dev"
|
||||
}
|
||||
```
|
||||
|
||||
Note that these modules have the following distinct characteristics:
|
||||
|
||||
- Library type is `silverstripe-vendormodule`
|
||||
- SilverStripe can hook in to the composer installation process by declaring `type: silverstripe/vendormodule`.
|
||||
- Any folder which should be exposed to the public webroot must be declared in the `extra.expose` config.
|
||||
These paths will be automatically rewritten to public urls which don't directly serve files from the `vendor`
|
||||
folder. For instance, `vendor/tractorcow/test-vendor-module/client` will be rewritten to
|
||||
`resources/tractorcow/test-vendor-module/client`.
|
||||
folder. For instance, `vendor/my-vendor/my-module/client` will be rewritten to
|
||||
`resources/my-vendor/my-module/client`.
|
||||
- Any module which uses the folder expose feature must require `silverstripe/vendor-plugin` in order to
|
||||
support automatic rewriting and linking. For more information on this plugin you can see the
|
||||
[silverstripe/vendor-plugin github page](https://github.com/silverstripe/vendor-plugin).
|
||||
@ -97,7 +72,7 @@ this is how you would require a script in this module:
|
||||
```php
|
||||
use SilverStripe\View\Requirements;
|
||||
|
||||
Requirements::javascript('tractorcow/test-vendor-module:client/js/script.js');
|
||||
Requirements::javascript('my-vendor/my-module:client/js/script.js');
|
||||
```
|
||||
|
||||
## Releasing versions
|
||||
|
||||
@ -13,7 +13,7 @@ address. We want our CMS authors to be able to embed the map using the following
|
||||
So we've got the address as "content" of our new `googlemap` shortcode tags, plus some `width` and `height` arguments.
|
||||
We'll add defaults to those in our shortcode parser so they're optional.
|
||||
|
||||
**mysite/_config.php**
|
||||
**app/_config.php**
|
||||
|
||||
```php
|
||||
use SilverStripe\View\Parsers\ShortcodeParser;
|
||||
|
||||
@ -6,7 +6,7 @@ summary: Test models, database logic and your object methods.
|
||||
A Unit Test is an automated piece of code that invokes a unit of work in the application and then checks the behavior
|
||||
to ensure that it works as it should. A simple example would be to test the result of a PHP method.
|
||||
|
||||
**mysite/code/Page.php**
|
||||
**app/code/Page.php**
|
||||
|
||||
|
||||
```php
|
||||
@ -21,7 +21,7 @@ class Page extends SiteTree
|
||||
}
|
||||
```
|
||||
|
||||
**mysite/tests/PageTest.php**
|
||||
**app/tests/PageTest.php**
|
||||
|
||||
|
||||
```php
|
||||
@ -37,7 +37,7 @@ class PageTest extends SapphireTest
|
||||
```
|
||||
|
||||
<div class="info" markdown="1">
|
||||
Tests for your application should be stored in the `mysite/tests` directory. Test cases for add-ons should be stored in
|
||||
Tests for your application should be stored in the `app/tests` directory. Test cases for add-ons should be stored in
|
||||
the `(modulename)/tests` directory.
|
||||
|
||||
Test case classes should end with `Test` (e.g `PageTest`) and test methods must start with `test` (e.g `testMyMethod`).
|
||||
@ -88,7 +88,7 @@ needs.
|
||||
|
||||
<phpunit bootstrap="vendor/silverstripe/framework/tests/bootstrap.php" colors="true">
|
||||
<testsuite name="Default">
|
||||
<directory>mysite/tests</directory>
|
||||
<directory>app/tests</directory>
|
||||
</testsuite>
|
||||
<groups>
|
||||
<exclude>
|
||||
|
||||
@ -12,7 +12,7 @@ fixtures - all we have to do is define them.
|
||||
To include your fixture file in your tests, you should define it as your `$fixture_file`:
|
||||
|
||||
|
||||
**mysite/tests/MyNewTest.php**
|
||||
**app/tests/MyNewTest.php**
|
||||
|
||||
|
||||
```php
|
||||
@ -29,7 +29,7 @@ You can also use an array of fixture files, if you want to use parts of multiple
|
||||
If you are using [api:SilverStripe\Dev\TestOnly] dataobjects in your fixtures, you must
|
||||
declare these classes within the $extra_dataobjects variable.
|
||||
|
||||
**mysite/tests/MyNewTest.php**
|
||||
**app/tests/MyNewTest.php**
|
||||
|
||||
```php
|
||||
use SilverStripe\Dev\SapphireTest;
|
||||
@ -84,7 +84,7 @@ class Team extends DataObject implements TestOnly
|
||||
|
||||
We can represent multiple instances of them in `YAML` as follows:
|
||||
|
||||
**mysite/tests/fixtures.yml**
|
||||
**app/tests/fixtures.yml**
|
||||
|
||||
```yml
|
||||
|
||||
@ -340,7 +340,7 @@ values based on other fixture data.
|
||||
$factory->define('Member', [
|
||||
'Email' => function($obj, $data, $fixtures) {
|
||||
if(isset($data['FirstName']) {
|
||||
$obj->Email = strtolower($data['FirstName']) . '@example.org';
|
||||
$obj->Email = strtolower($data['FirstName']) . '@example.com';
|
||||
}
|
||||
},
|
||||
'Score' => function($obj, $data, $fixtures) {
|
||||
|
||||
@ -5,7 +5,7 @@ title: How to write a SapphireTest
|
||||
Here is an example of a test which extends [SapphireTest](api:SilverStripe\Dev\SapphireTest) to test the URL generation of the page. It also showcases
|
||||
how you can load default records into the test database.
|
||||
|
||||
**mysite/tests/PageTest.php**
|
||||
**app/tests/PageTest.php**
|
||||
|
||||
```php
|
||||
use SilverStripe\Dev\SapphireTest;
|
||||
|
||||
@ -7,7 +7,7 @@ core of these tests are the same as `SapphireTest` unit tests but add several me
|
||||
and receiving [HTTPResponse](api:SilverStripe\Control\HTTPResponse) objects. In this How To, we'll see how to write a test to query a page, check the
|
||||
response and modify the session within a test.
|
||||
|
||||
**mysite/tests/HomePageTest.php**
|
||||
**app/tests/HomePageTest.php**
|
||||
|
||||
|
||||
```php
|
||||
@ -28,7 +28,7 @@ class HomePageTest extends FunctionalTest
|
||||
|
||||
// We should see a login form
|
||||
$login = $this->submitForm("LoginFormID", null, [
|
||||
'Email' => 'test@test.com',
|
||||
'Email' => 'test@example.com',
|
||||
'Password' => 'wrongpassword'
|
||||
]);
|
||||
|
||||
|
||||
@ -25,7 +25,7 @@ on a public server very carefully.
|
||||
Test mode is designed for staging environments or other private collaboration sites before deploying a site live.
|
||||
|
||||
In this mode error messages are hidden from the user and SilverStripe includes [BasicAuth](api:SilverStripe\Security\BasicAuth) integration if you
|
||||
want to password protect the site. You can enable that by adding this to your `mysite/_config/app.yml` file:
|
||||
want to password protect the site. You can enable that by adding this to your `app/_config/app.yml` file:
|
||||
|
||||
|
||||
```yml
|
||||
@ -50,7 +50,7 @@ Live sites should always run in live mode. You should not run production website
|
||||
|
||||
You can check for the current environment type in [config files](../configuration) through the `environment` variant.
|
||||
|
||||
**mysite/_config/app.yml**
|
||||
**app/_config/app.yml**
|
||||
|
||||
```yml
|
||||
---
|
||||
|
||||
@ -44,7 +44,7 @@ template caching when modifying this config, as this key is cached within the te
|
||||
For example, to ensure that the cache is configured to respect another variable, and if the current logged in
|
||||
user does not influence your template content, you can update this key as below;
|
||||
|
||||
**mysite/_config/app.yml**
|
||||
**app/_config/app.yml**
|
||||
|
||||
|
||||
```yml
|
||||
|
||||
@ -450,9 +450,9 @@ given variable is done safely, with the assumption that it's an integer.
|
||||
|
||||
To cast the variable as an integer, place `(int)` or `(integer)` before the variable.
|
||||
|
||||
For example: a page with the URL paramaters *mysite.com/home/add/1* requires that ''Director::urlParams['ID']'' be an
|
||||
For example: a page with the URL paramaters *example.com/home/add/1* requires that ''Director::urlParams['ID']'' be an
|
||||
integer. We cast it by adding `(int)` - ''(int)Director::urlParams['ID']''. If a value other than an integer is
|
||||
passed, such as *mysite.com/home/add/dfsdfdsfd*, then it returns 0.
|
||||
passed, such as *example.com/home/add/dfsdfdsfd*, then it returns 0.
|
||||
|
||||
Below is an example with different ways you would use this casting technique:
|
||||
|
||||
@ -461,7 +461,7 @@ Below is an example with different ways you would use this casting technique:
|
||||
public function CaseStudies()
|
||||
{
|
||||
|
||||
// cast an ID from URL parameters e.g. (mysite.com/home/action/ID)
|
||||
// cast an ID from URL parameters e.g. (example.com/home/action/ID)
|
||||
$anotherID = (int)Director::urlParam['ID'];
|
||||
|
||||
// perform a calculation, the prerequisite being $anotherID must be an integer
|
||||
@ -612,7 +612,7 @@ this whitelist in your `.env` file, any request presenting a `Host` header that
|
||||
_not_ in this list will be blocked with a HTTP 400 error:
|
||||
|
||||
```
|
||||
SS_ALLOWED_HOSTS="www.mysite.com,mysite.com,subdomain.mysite.com"
|
||||
SS_ALLOWED_HOSTS="www.example.com,example.com,subdomain.example.com"
|
||||
```
|
||||
|
||||
Please note that if this configuration is defined, you _must_ include _all_ subdomains (eg www.)
|
||||
|
||||
@ -18,7 +18,7 @@ SilverStripe\Core\Injector\Injector:
|
||||
Swift_Transport: Swift_SendmailTransport
|
||||
```
|
||||
|
||||
For example, to use SMTP, create a file mysite/_config/email.yml:
|
||||
For example, to use SMTP, create a file app/_config/email.yml:
|
||||
|
||||
```yml
|
||||
---
|
||||
@ -65,7 +65,7 @@ $email->send();
|
||||
|
||||
<div class="info" markdown="1">
|
||||
The default HTML template for emails is named `GenericEmail` and is located in `vendor/silverstripe/framework/templates/SilverStripe/Email/`.
|
||||
To customise this template, copy it to the `mysite/templates/Email/` folder or use `setHTMLTemplate` when you create the
|
||||
To customise this template, copy it to the `app/templates/Email/` folder or use `setHTMLTemplate` when you create the
|
||||
`Email` instance.
|
||||
</div>
|
||||
|
||||
@ -75,7 +75,7 @@ To customise this template, copy it to the `mysite/templates/Email/` folder or u
|
||||
HTML emails can use custom templates using the same template language as your website template. You can also pass the
|
||||
email object additional information using the `setData` and `addData` methods.
|
||||
|
||||
**mysite/templates/Email/MyCustomEmail.ss**
|
||||
**app/templates/Email/MyCustomEmail.ss**
|
||||
|
||||
|
||||
```ss
|
||||
@ -125,12 +125,12 @@ $this->send();
|
||||
|
||||
You can set the default sender address of emails through the `Email.admin_email` [configuration setting](/developer_guides/configuration).
|
||||
|
||||
**mysite/_config/app.yml**
|
||||
**app/_config/app.yml**
|
||||
|
||||
|
||||
```yaml
|
||||
SilverStripe\Control\Email\Email:
|
||||
admin_email: support@silverstripe.org
|
||||
admin_email: support@example.com
|
||||
```
|
||||
|
||||
<div class="alert" markdown="1">
|
||||
@ -151,7 +151,7 @@ live systems.
|
||||
|
||||
Configuration of those properties looks like the following:
|
||||
|
||||
**mysite/_config.php**
|
||||
**app/_config.php**
|
||||
|
||||
```php
|
||||
use SilverStripe\Control\Email\Email;
|
||||
@ -172,7 +172,7 @@ marked as spam.
|
||||
|
||||
```php
|
||||
$email = new Email(..);
|
||||
$email->setReplyTo('me@address.com');
|
||||
$email->setReplyTo('reply@example.com');
|
||||
```
|
||||
|
||||
### Setting Custom Headers
|
||||
|
||||
@ -55,7 +55,7 @@ RSSFeed::linkToFeed($link, $title);
|
||||
You can use [RSSFeed](api:SilverStripe\Control\RSS\RSSFeed) to easily create a feed showing your latest Page updates. The following example adds a page
|
||||
`/home/rss/` which displays an XML file the latest updated pages.
|
||||
|
||||
**mysite/code/Page.php**
|
||||
**app/code/Page.php**
|
||||
|
||||
```php
|
||||
use SilverStripe\Control\RSS\RSSFeed;
|
||||
@ -169,7 +169,7 @@ the object. To customise the XML produced use `setTemplate`.
|
||||
|
||||
Say from that last example we want to include the Players Team in the XML feed we might create the following XML file.
|
||||
|
||||
**mysite/templates/PlayersRss.ss**
|
||||
**app/templates/PlayersRss.ss**
|
||||
|
||||
```xml
|
||||
<?xml version="1.0"?>
|
||||
@ -192,7 +192,7 @@ Say from that last example we want to include the Players Team in the XML feed w
|
||||
|
||||
`setTemplate` can then be used to tell RSSFeed to use that new template.
|
||||
|
||||
**mysite/code/Page.php**
|
||||
**app/code/Page.php**
|
||||
|
||||
```php
|
||||
use SilverStripe\Control\RSS\RSSFeed;
|
||||
|
||||
@ -15,7 +15,7 @@ containing a list of football players and the team they play for. The file we ha
|
||||
This data needs to be imported into our application. For this, we have two `DataObjects` setup. `Player` contains
|
||||
information about the individual player and a relation set up for managing the `Team`.
|
||||
|
||||
**mysite/code/Player.php**.
|
||||
**app/code/Player.php**.
|
||||
|
||||
|
||||
```php
|
||||
@ -37,7 +37,7 @@ class Player extends DataObject
|
||||
}
|
||||
```
|
||||
|
||||
**mysite/code/FootballTeam.php**
|
||||
**app/code/FootballTeam.php**
|
||||
|
||||
|
||||
```php
|
||||
@ -67,7 +67,7 @@ column
|
||||
|
||||
Our final import looks like this.
|
||||
|
||||
**mysite/code/PlayerCsvBulkLoader.php**
|
||||
**app/code/PlayerCsvBulkLoader.php**
|
||||
|
||||
|
||||
```php
|
||||
|
||||
@ -31,7 +31,7 @@ you want to set.
|
||||
```php
|
||||
use SilverStripe\i18n\i18n;
|
||||
|
||||
// mysite/_config.php
|
||||
// app/_config.php
|
||||
i18n::set_locale('de_DE'); // Setting the locale to German (Germany)
|
||||
i18n::set_locale('ca_AD'); // Setting to Catalan (Andorra)
|
||||
```
|
||||
|
||||
@ -188,7 +188,7 @@ SilverStripe\Assets\Storage\DBFile:
|
||||
#### Resampled image quality
|
||||
|
||||
To adjust the quality of the generated images when they are resampled, add the
|
||||
following to your `mysite/config/config.yml` file:
|
||||
following to your `app/_config/config.yml` file:
|
||||
|
||||
|
||||
```yml
|
||||
|
||||
@ -179,9 +179,9 @@ assets/
|
||||
|
||||
The urls for these two files, however, do not reflect the physical structure directly.
|
||||
|
||||
* `http://www.mysite.com/assets/33be1b95cb/OldCompanyLogo.gif` will be served directly from the web server,
|
||||
* `http://www.example.com/assets/33be1b95cb/OldCompanyLogo.gif` will be served directly from the web server,
|
||||
and will not invoke a php request.
|
||||
* `http://www.mysite.com/assets/a870de278b/NewCompanyLogo.gif` will be routed via a 404 handler to PHP,
|
||||
* `http://www.example.com/assets/a870de278b/NewCompanyLogo.gif` will be routed via a 404 handler to PHP,
|
||||
which will be passed to the `[ProtectedFileController](api:SilverStripe\Assets\Storage\ProtectedFileController)` controller, which will serve
|
||||
up the content of the hidden file, conditional on a permission check.
|
||||
|
||||
@ -240,11 +240,11 @@ to deny any and all direct web requests.
|
||||
In order to better ensure these files are protected, it's recommended to move this outside of the web
|
||||
root altogether.
|
||||
|
||||
For instance, given your web root is in the folder `/sites/mysite/www`, you can tell the asset store
|
||||
to put protected files into `/sites/mysite/protected` with the below `.env` setting:
|
||||
For instance, given your web root is in the folder `/sites/myapp/www`, you can tell the asset store
|
||||
to put protected files into `/sites/myapp/protected` with the below `.env` setting:
|
||||
|
||||
```
|
||||
SS_PROTECTED_ASSETS_PATH="/sites/mysite/protected"
|
||||
SS_PROTECTED_ASSETS_PATH="/sites/myapp/protected"
|
||||
```
|
||||
|
||||
### Configuring: File types
|
||||
|
||||
@ -74,7 +74,7 @@ This corresponds to a file with the following properties:
|
||||
- Variant: FitWzYwLDYwXQ (corresponds to Fit[60,60])
|
||||
|
||||
The URL for this file will match the physical location on disk:
|
||||
`http://www.mysite.com/assets/Uploads/b63923d8d4/BannerHeader__FitWzYwLDYwXQ.jpg`.
|
||||
`http://www.example.com/assets/Uploads/b63923d8d4/BannerHeader__FitWzYwLDYwXQ.jpg`.
|
||||
|
||||
For more information on how protected files are stored see the [file security](/developer_guides/files/file_security)
|
||||
section.
|
||||
|
||||
@ -17,7 +17,7 @@ also be used in other areas of your application.
|
||||
Let's assume we want to manage a simple product listing as a sample data model: A product can have a name, price, and
|
||||
a category.
|
||||
|
||||
**mysite/code/Product.php**
|
||||
**app/code/Product.php**
|
||||
|
||||
|
||||
```php
|
||||
@ -38,7 +38,7 @@ class Product extends DataObject
|
||||
}
|
||||
```
|
||||
|
||||
**mysite/code/Category.php**
|
||||
**app/code/Category.php**
|
||||
|
||||
|
||||
```php
|
||||
@ -62,7 +62,7 @@ DataObject's you want to scaffold an interface for. The class can manage multipl
|
||||
|
||||
We'll name it `MyAdmin`, but the class name can be anything you want.
|
||||
|
||||
**mysite/code/MyAdmin.php**
|
||||
**app/code/MyAdmin.php**
|
||||
|
||||
|
||||
```php
|
||||
@ -103,7 +103,7 @@ The [DataObject](api:SilverStripe\ORM\DataObject) API has more granular permissi
|
||||
Available checks are `canEdit()`, `canCreate()`, `canView()` and `canDelete()`. Models check for administrator
|
||||
permissions by default. For most cases, less restrictive checks make sense, e.g. checking for general CMS access rights.
|
||||
|
||||
**mysite/code/Category.php**
|
||||
**app/code/Category.php**
|
||||
|
||||
|
||||
```php
|
||||
@ -144,7 +144,7 @@ class makes a guess at how those fields should be searched, e.g. showing a check
|
||||
To remove, add or modify searchable fields, define a new [DataObject::$searchable_fields](api:SilverStripe\ORM\DataObject::$searchable_fields) static on your model
|
||||
class (see [SearchContext](../search/searchcontext) docs for details).
|
||||
|
||||
**mysite/code/Product.php**
|
||||
**app/code/Product.php**
|
||||
|
||||
|
||||
```php
|
||||
@ -170,7 +170,7 @@ The results are shown in a tabular listing, powered by the [GridField](../forms/
|
||||
the [GridFieldDataColumns](api:SilverStripe\Forms\GridField\GridFieldDataColumns) component. This component looks for a [DataObject::$summary_fields](api:SilverStripe\ORM\DataObject::$summary_fields) static on your
|
||||
model class, where you can add or remove columns. To change the title, use [DataObject::$field_labels](api:SilverStripe\ORM\DataObject::$field_labels).
|
||||
|
||||
**mysite/code/Product.php**
|
||||
**app/code/Product.php**
|
||||
|
||||
|
||||
```php
|
||||
@ -195,7 +195,7 @@ can be customized by additional SQL filters, joins.
|
||||
|
||||
For example, we might want to exclude all products without prices in our sample `MyAdmin` implementation.
|
||||
|
||||
**mysite/code/MyAdmin.php**
|
||||
**app/code/MyAdmin.php**
|
||||
|
||||
|
||||
```php
|
||||
@ -220,7 +220,7 @@ class MyAdmin extends ModelAdmin
|
||||
You can also customize the search behavior directly on your `ModelAdmin` instance. For example, we might want to have a
|
||||
checkbox which limits search results to expensive products (over $100).
|
||||
|
||||
**mysite/code/MyAdmin.php**
|
||||
**app/code/MyAdmin.php**
|
||||
|
||||
```php
|
||||
use SilverStripe\Forms\CheckboxField;
|
||||
@ -257,7 +257,7 @@ class MyAdmin extends ModelAdmin
|
||||
To alter how the results are displayed (via [GridField](api:SilverStripe\Forms\GridField\GridField)), you can also overload the `getEditForm()` method. For
|
||||
example, to add a new component.
|
||||
|
||||
**mysite/code/MyAdmin.php**
|
||||
**app/code/MyAdmin.php**
|
||||
|
||||
|
||||
```php
|
||||
@ -294,7 +294,7 @@ class MyAdmin extends ModelAdmin
|
||||
The above example will add the component to all `GridField`s (of all managed models). Alternatively we can also add it
|
||||
to only one specific `GridField`:
|
||||
|
||||
**mysite/code/MyAdmin.php**
|
||||
**app/code/MyAdmin.php**
|
||||
|
||||
|
||||
```php
|
||||
|
||||
@ -390,7 +390,7 @@ in a single Ajax request.
|
||||
```php
|
||||
use SilverStripe\Admin\LeftAndMain;
|
||||
|
||||
// mysite/code/MyAdmin.php
|
||||
// app/code/MyAdmin.php
|
||||
class MyAdmin extends LeftAndMain
|
||||
{
|
||||
private static $url_segment = 'myadmin';
|
||||
|
||||
@ -38,7 +38,7 @@ feature.
|
||||
Like most of the CMS, the preview UI is powered by
|
||||
[jQuery entwine](https://github.com/hafriedlander/jquery.entwine). This means
|
||||
its defaults are configured through JavaScript, by setting entwine properties.
|
||||
In order to achieve this, create a new file `mysite/javascript/MyLeftAndMain.Preview.js`.
|
||||
In order to achieve this, create a new file `app/javascript/MyLeftAndMain.Preview.js`.
|
||||
|
||||
In the following example we configure three aspects:
|
||||
|
||||
@ -75,14 +75,14 @@ Note how the configuration happens in different entwine namespaces
|
||||
}(jQuery));
|
||||
```
|
||||
|
||||
Load the file in the CMS via setting adding 'mysite/javascript/MyLeftAndMain.Preview.js'
|
||||
Load the file in the CMS via setting adding 'app/javascript/MyLeftAndMain.Preview.js'
|
||||
to the `LeftAndMain.extra_requirements_javascript` [configuration value](../configuration)
|
||||
|
||||
|
||||
```yml
|
||||
SilverStripe\Admin\LeftAndMain:
|
||||
extra_requirements_javascript:
|
||||
- mysite/javascript/MyLeftAndMain.Preview.js
|
||||
- app/javascript/MyLeftAndMain.Preview.js
|
||||
```
|
||||
|
||||
In order to find out which configuration values are available, the source code
|
||||
|
||||
@ -4,7 +4,7 @@ summary: Add custom CSS properties to the rich-text editor.
|
||||
# WYSIWYG Styles
|
||||
|
||||
SilverStripe lets you customise the style of content in the CMS. This is done by setting up a CSS file called
|
||||
`editor.css` in either your theme or in your `mysite` folder. This is set through yaml config:
|
||||
`editor.css` in either your theme or in your `app/` folder. This is set through yaml config:
|
||||
|
||||
```yaml
|
||||
---
|
||||
@ -12,22 +12,22 @@ name: MyCSS
|
||||
---
|
||||
SilverStripe\Forms\HTMLEditor\TinyMCEConfig:
|
||||
editor_css:
|
||||
- 'mysite/css/editor.css'
|
||||
- 'app/css/editor.css'
|
||||
```
|
||||
|
||||
Will load the `mysite/css/editor.css` file.
|
||||
Will load the `app/css/editor.css` file.
|
||||
|
||||
Alternatively, you can set this on a specific `TinyMCEConfig` instance via `setContentCSS` method.
|
||||
|
||||
```php
|
||||
$config = new TinyMCEConfig();
|
||||
$config->setContentCSS([ '/mysite/client/css/editor.css' ]);
|
||||
$config->setContentCSS([ '/app/client/css/editor.css' ]);
|
||||
```
|
||||
|
||||
## Custom style dropdown
|
||||
|
||||
The custom style dropdown can be enabled via the `importcss` plugin bundled with admin module. ([Doc](https://www.tinymce.com/docs/plugins/importcss/))
|
||||
Use the below code in `mysite/_config.php`:
|
||||
Use the below code in `app/_config.php`:
|
||||
|
||||
```php
|
||||
use SilverStripe\Forms\HTMLEditor\TinyMCEConfig;
|
||||
|
||||
@ -112,7 +112,7 @@ The above query is almost self-descriptive. It gets a user by ID, returns his or
|
||||
{
|
||||
"user": {
|
||||
"name": "Test user",
|
||||
"email": "me@example.com",
|
||||
"email": "test@example.com",
|
||||
"blogPosts": [
|
||||
{
|
||||
"title": "How to be awesome at GraphQL",
|
||||
|
||||
@ -135,9 +135,9 @@ extras.
|
||||
|
||||
Continuing our example let's add a "constructive" style to our *Clean-up* button. First you need to be able to add
|
||||
custom JS code into the CMS. You can do this by adding a new source file, here
|
||||
`mysite/javascript/CMSMain.CustomActionsExtension.js`, and requiring it
|
||||
`app/javascript/CMSMain.CustomActionsExtension.js`, and requiring it
|
||||
through a YAML configuration value: `LeftAndMain.extra_requirements_javascript`.
|
||||
Set it to 'mysite/javascript/CMSMain.CustomActionsExtension.js'.
|
||||
Set it to 'app/javascript/CMSMain.CustomActionsExtension.js'.
|
||||
|
||||
You can now add the styling in response to `afterrefreshalternate` event. Let's use entwine to avoid accidental memory
|
||||
leaks. The only complex part here is how the entwine handle is constructed. `onbuttonafterrefreshalternate` can be
|
||||
|
||||
@ -18,7 +18,7 @@ provide a custom title and icon.
|
||||
|
||||
First we'll need a custom icon. For this purpose SilverStripe uses 16x16
|
||||
black-and-transparent PNG graphics. In this case we'll place the icon in
|
||||
`mysite/images`, but you are free to use any location.
|
||||
`app/images`, but you are free to use any location.
|
||||
|
||||
|
||||
```php
|
||||
@ -27,7 +27,7 @@ use SilverStripe\Admin\ModelAdmin;
|
||||
class ProductAdmin extends ModelAdmin
|
||||
{
|
||||
// ...
|
||||
private static $menu_icon = 'mysite/images/product-icon.png';
|
||||
private static $menu_icon = 'app/images/product-icon.png';
|
||||
}
|
||||
```
|
||||
|
||||
|
||||
@ -18,7 +18,7 @@ Here's a brief example on how to add sorting and a new column for a
|
||||
hypothetical `NewsPageHolder` type, which contains `NewsPage` children.
|
||||
|
||||
|
||||
**mysite/code/NewsPageHolder.php**
|
||||
**app/code/NewsPageHolder.php**
|
||||
|
||||
```php
|
||||
class NewsPageHolder extends Page
|
||||
@ -27,7 +27,7 @@ class NewsPageHolder extends Page
|
||||
}
|
||||
```
|
||||
|
||||
**mysite/code/NewsPage.php**
|
||||
**app/code/NewsPage.php**
|
||||
|
||||
```php
|
||||
class NewsPage extends Page
|
||||
@ -44,7 +44,7 @@ before its rendered. In this case, we limit our logic to the desired page type,
|
||||
although it's just as easy to implement changes which apply to all page types,
|
||||
or across page types with common characteristics.
|
||||
|
||||
**mysite/code/NewsPageHolderCMSMainExtension.php**
|
||||
**app/code/NewsPageHolderCMSMainExtension.php**
|
||||
|
||||
```php
|
||||
use SilverStripe\Core\Extension;
|
||||
@ -78,7 +78,7 @@ class NewsPageHolderCMSMainExtension extends Extension
|
||||
Now you just need to enable the extension in your [configuration file](../../configuration).
|
||||
|
||||
```yml
|
||||
// mysite/_config/config.yml
|
||||
// app/_config/config.yml
|
||||
SilverStripe\Admin\LeftAndMain:
|
||||
extensions:
|
||||
- NewsPageHolderCMSMainExtension
|
||||
|
||||
@ -28,7 +28,7 @@ Modules may come with their own additional reports.
|
||||
Custom reports can be created quickly and easily. A general knowledge of SilverStripe's
|
||||
[datamodel and ORM](../../model/data_model_and_orm) is useful before creating a custom report.
|
||||
|
||||
Inside the *mysite/code* folder create a file called *CustomSideReport.php*. Inside this file we can add our site reports.
|
||||
Inside the *app/code* folder create a file called *CustomSideReport.php*. Inside this file we can add our site reports.
|
||||
|
||||
The following example will create a report to list every page on the current site.
|
||||
|
||||
|
||||
@ -16,7 +16,7 @@ guide on [CMS Architecture](/developer_guides/customising_the_admin_interface/cm
|
||||
## Overload a CMS template
|
||||
|
||||
If you place a template with an identical name into your application template
|
||||
directory (usually `mysite/templates/`), it'll take priority over the built-in
|
||||
directory (usually `app/templates/`), it'll take priority over the built-in
|
||||
one.
|
||||
|
||||
CMS templates are inherited based on their controllers, similar to subclasses of
|
||||
@ -26,7 +26,7 @@ We can use this to create a different base template with `LeftAndMain.ss`
|
||||
|
||||
Copy the template markup of the base implementation at `templates/SilverStripe/Admin/Includes/LeftAndMain_Menu.ss`
|
||||
from the `silverstripe/admin` module
|
||||
into `mysite/templates/Includes/LeftAndMain_Menu.ss`. It will automatically be picked up by
|
||||
into `app/templates/Includes/LeftAndMain_Menu.ss`. It will automatically be picked up by
|
||||
the CMS logic. Add a new section into the `<ul class="cms-menu-list">`
|
||||
|
||||
|
||||
@ -52,7 +52,7 @@ hardcoded links underneath the left-hand menu. We'll make these dynamic further
|
||||
In order to show the links a bit separated from the other menu entries,
|
||||
we'll add some CSS, and get it to load
|
||||
with the CMS interface. Paste the following content into a new file called
|
||||
`mysite/css/BookmarkedPages.css`:
|
||||
`app/css/BookmarkedPages.css`:
|
||||
|
||||
|
||||
```css
|
||||
@ -66,14 +66,14 @@ Load the new CSS file into the CMS, by setting the `LeftAndMain.extra_requiremen
|
||||
```yml
|
||||
SilverStripe\Admin\LeftAndMain:
|
||||
extra_requirements_css:
|
||||
- mysite/css/BookmarkedPages.css
|
||||
- app/css/BookmarkedPages.css
|
||||
```
|
||||
|
||||
## Create a "bookmark" flag on pages
|
||||
|
||||
Now we'll define which pages are actually bookmarked, a flag that is stored in
|
||||
the database. For this we need to decorate the page record with a
|
||||
`DataExtension`. Create a new file called `mysite/code/BookmarkedPageExtension.php`
|
||||
`DataExtension`. Create a new file called `app/code/BookmarkedPageExtension.php`
|
||||
and insert the following code.
|
||||
|
||||
|
||||
@ -117,7 +117,7 @@ pages from the database into the template we've already created (with hardcoded
|
||||
links)? Again, we extend a core class: The main CMS controller called
|
||||
`LeftAndMain`.
|
||||
|
||||
Add the following code to a new file `mysite/code/BookmarkedLeftAndMainExtension.php`;
|
||||
Add the following code to a new file `app/code/BookmarkedLeftAndMainExtension.php`;
|
||||
|
||||
|
||||
```php
|
||||
@ -143,7 +143,7 @@ SilverStripe\Admin\LeftAndMain:
|
||||
```
|
||||
|
||||
As the last step, replace the hardcoded links with our list from the database.
|
||||
Find the `<ul>` you created earlier in `mysite/admin/templates/LeftAndMain.ss`
|
||||
Find the `<ul>` you created earlier in `app/admin/templates/LeftAndMain.ss`
|
||||
and replace it with the following:
|
||||
|
||||
|
||||
|
||||
@ -12,10 +12,9 @@ See our [upgrade notes and changelogs](/changelogs/4.0.0) for 4.0.0 specific inf
|
||||
|
||||
## Composer
|
||||
|
||||
SilverStripe CMS is becoming more modular, and
|
||||
[composer is becoming the preferred way to manage your code](/getting_started/composer).
|
||||
|
||||
For projects managed through Composer, we recommend using `recipe-cms` in your `composer.json` file to help you keep
|
||||
SilverStripe CMS is a modular system, and [Composer](http://getcomposer.org)
|
||||
is the default way to manage your modules ([instructions](/getting_started/composer)).
|
||||
We recommend using `recipe-cms` in your `composer.json` file to help you keep
|
||||
up to date and run `composer update`.
|
||||
|
||||
```json
|
||||
@ -44,11 +43,11 @@ through the [Composer dependency update section](/changelogs/4.0.0#deps)
|
||||
* Backup your webroot files.
|
||||
* Download the new release and uncompress it to a temporary folder.
|
||||
* Leave custom folders like *themes* in place.
|
||||
* Rename `mysite/code` folder to `app/src`, updating your `app/_config/mysite.yml` config to set the new project name.
|
||||
* Rename `app/code` folder to `app/src`, updating your `app/_config/app.yml` config to set the new project name.
|
||||
* Identify system folders in your webroot (`cms`, `framework` and any additional modules).
|
||||
* Delete existing system folders (or move them outside of your webroot).
|
||||
* Add a `private static $table_name = 'MyDataObject'` for any custom DataObjects in your code that are namespaced. This ensures that your database table name will be `MyDataObject` instead of `Me_MyPackage_Model_MyDataObject` (converts your namespace to the table_name).
|
||||
* Ensure you add [namespaces](http://php.net/manual/en/language.namespaces.php) to any custom classes in your `mysite` folder. Your namespaces should follow the pattern of `Vendor\Package` with anything additional defined at your discretion. **Note:** The `Page` and `PageController` classes *must* be defined in the global namespace (or without a namespace).
|
||||
* Ensure you add [namespaces](http://php.net/manual/en/language.namespaces.php) to any custom classes in your `app/` folder. Your namespaces should follow the pattern of `Vendor\Package` with anything additional defined at your discretion. **Note:** The `Page` and `PageController` classes *must* be defined in the global namespace (or without a namespace).
|
||||
* Install the updated framework, CMS and any other modules you require by updating your `composer.json` configuration and running `composer update`. Some features have been split into their own modules, such as `asset-admin` and `errorpage`. Please refer to [`recipe-cms` composer.json](https://github.com/silverstripe/recipe-cms) and [`recipe-core` composer.json](https://github.com/silverstripe/recipe-core) for a list of recommended modules to include.
|
||||
* Check if you need to adapt your code to changed PHP APIs. For more information please refer to [the changelog](/changelogs/4.0.0). There is an upgrader tool available to help you with most of the changes required (see below).
|
||||
* Visit http://yoursite.com/dev/build/?flush=1 to rebuild the website database.
|
||||
@ -191,7 +190,7 @@ SilverStripe 4 introduces [PSR-3](http://www.php-fig.org/psr/psr-3/) compatible
|
||||
|
||||
Please see the changelogs for more details on how to implement logging.
|
||||
|
||||
[Upgrade `mysite/_config.php`](/changelogs/4.0.0#config-php)
|
||||
[Upgrade `app/_config.php`](/changelogs/4.0.0#config-php)
|
||||
The globals `$database` and `$databaseConfig` are deprecated. You should upgrade your site `_config.php` files to use the [.env configuration](#env).
|
||||
`conf/ConfigureFromEnv.php` is no longer used, and references to this file should be deleted.
|
||||
|
||||
|
||||
@ -10,7 +10,7 @@
|
||||
### App folder name
|
||||
|
||||
The standard 'mysite' code naming convention has changed in 4.2. Although existing sites can continue
|
||||
to use 'mysite/code` to store their base project code, the recommendation and new default is to
|
||||
to use 'app/code` to store their base project code, the recommendation and new default is to
|
||||
store code in `app/src`.
|
||||
|
||||
Additionally, we reinforce the recommendation to use psr-4 autoloading in your project to speed up
|
||||
@ -141,7 +141,7 @@ Two new commands have been added to the SilverStripe upgrader tool: `environment
|
||||
|
||||
`environment` allows you to convert your `_ss_environment.php` file to an equivalent `.env` file when migrating a SilverStripe 3 project to SilverStripe 4.
|
||||
|
||||
`reorganise` renames your `mysite` and `mysite/code` folders to `app` and `app/src`. It also warns you of any occurence of `mysite` in your codebase.
|
||||
`reorganise` renames your `mysite` and `app/code` folders to `app` and `app/src`. It also warns you of any occurence of `mysite` in your codebase.
|
||||
|
||||
```
|
||||
cd ~/my-project-root
|
||||
|
||||
@ -90,7 +90,7 @@ turned off via either `.env` or in your _config.php. Deprecation
|
||||
notices are always disabled on both live and test.
|
||||
|
||||
|
||||
`mysite/_config.php`
|
||||
`app/_config.php`
|
||||
|
||||
|
||||
|
||||
|
||||
Loading…
Reference in New Issue
Block a user