tonyair
/
silverstripe-framework
mirror of https://github.com/silverstripe/silverstripe-framework
1
0
Fork 0
Code Issues Projects Releases Wiki Activity

FIX Add namespaces in markdown docs (#7088) 

* FIX Add namespaces in markdown docs

* FIX Convert doc [link] to [link-text](link-uri)
This commit is contained in:
Saophalkun Ponlu 2017-07-03 13:22:12 +12:00 committed by Chris Joe
parent 40f8b04501
commit 63ba092765
118 changed files with 759 additions and 740 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
docs/en/00_Getting_Started/01_Installation/05_Common_Problems.md
View File

@ -51,7 +51,7 @@ to a lot of development problems. Here are some specifics situations:
## A SQL query fails with "Column not found" or "Table not found"
Whenever you change the model definitions in PHP (e.g. when adding a property to the [$db](api:DataObject::$db) array,
Whenever you change the model definitions in PHP (e.g. when adding a property to the [$db](api:SilverStripe\ORM\DataObject::$db) array,
creating a new page type), SilverStripe will need to update the database. Visiting `http://localhost/dev/build` in
your browser runs a script that will check the database schema and update it as necessary. Putting `?flush=1` on the
end makes sure that nothing that's linked to the old database structure will be carried over. If things aren't saving,
@ -71,7 +71,7 @@ every page on the site, if that's easier.
## I can see unparsed PHP output in my browser
Please make sure all code inside `*.php` files is wrapped in classes. Due to the way [api:ManifestBuilder]
Please make sure all code inside `*.php` files is wrapped in classes. Due to the way [ClassManifest](api:SilverStripe\Core\Manifest\ClassManifest)
includes all files with this extension, any **procedural code will be executed on every call**. The most common error here
is putting a test.php/phpinfo.php file in the document root. See [datamodel](/developer_guides/model/data_model_and_orm) and [controllers](/developer_guides/controllers)
for ways how to structure your code.

32
docs/en/01_Tutorials/02_Extending_A_Basic_Site.md
View File

@ -36,11 +36,11 @@ final page. Lets look at each one individually:
### Model
All content on our site is stored in a database. Each class that is a child of the [api:DataObject] class will have its own table in our database.
All content on our site is stored in a database. Each class that is a child of the [DataObject](api:SilverStripe\ORM\DataObject) class will have its own table in our database.
Every object of such a class will correspond to a row in that table -
this is our "data object", the **"model"** of Model-View-Controller. A page type has a data object that represents all the data for our page. Rather than inheriting
directly from [api:DataObject], it inherits from [api:SiteTree]. We generally create a "Page" data object, and subclass this for all other page types. This allows us to define behavior that is consistent across all pages in our site.
directly from [DataObject](api:SilverStripe\ORM\DataObject), it inherits from [SiteTree](api:SilverStripe\CMS\Model\SiteTree). We generally create a "Page" data object, and subclass this for all other page types. This allows us to define behavior that is consistent across all pages in our site.
### View
@ -49,7 +49,7 @@ presentation of our website.
### Controller
Each page type also has a **"controller"**. The controller contains all the code used to manipulate our data before it is rendered. For example, suppose we were making an auction site, and we only wanted to display the auctions closing in the next ten minutes. We would implement this logic in the controller. The controller for a page should inherit from [api:ContentController]. Just as we create a "Page" data object and subclass it for the rest of the site, we also create a "Page_Controller" that is subclassed.
Each page type also has a **"controller"**. The controller contains all the code used to manipulate our data before it is rendered. For example, suppose we were making an auction site, and we only wanted to display the auctions closing in the next ten minutes. We would implement this logic in the controller. The controller for a page should inherit from [ContentController](api:SilverStripe\CMS\Controllers\ContentController). Just as we create a "Page" data object and subclass it for the rest of the site, we also create a "Page_Controller" that is subclassed.
Creating a new page type requires creating each of these three elements. We will then have full control over presentation, the database, and editable CMS fields.
@ -95,7 +95,7 @@ Let's create the *ArticleHolder* page type.
Here we have done something interesting: the *$allowed_children* field. This is one of a number of static fields we can define to change the properties of a page type. The *$allowed_children* field is an array of page types that are allowed
to be children of the page in the site tree. As we only want **news articles** in the news section, we only want pages of the type *ArticlePage* as children. We can enforce this in the CMS by setting the *$allowed_children* field within this class.
We will be introduced to other fields like this as we progress; there is a full list in the documentation for [api:SiteTree].
We will be introduced to other fields like this as we progress; there is a full list in the documentation for [SiteTree](api:SilverStripe\CMS\Model\SiteTree).
Now that we have created our page types, we need to let SilverStripe rebuild the database: [http://localhost/your_site_name/dev/build](http://localhost/your_site_name/dev/build). SilverStripe should detect that there are two new page types, and add them to the list of page types in the database.
@ -162,7 +162,7 @@ Let's walk through this method.
Firstly, we get the fields from the parent class; we want to add fields, not replace them. The *$fields* variable
returned is a [api:FieldList] object.
returned is a [FieldList](api:SilverStripe\Forms\FieldList) object.
:::php
$fields->addFieldToTab('Root.Main', new TextField('Author'), 'Content');
@ -170,14 +170,14 @@ returned is a [api:FieldList] object.
We can then add our new fields with *addFieldToTab*. The first argument is the tab on which we want to add the field to:
"Root.Main" is the tab which the content editor is on. The second argument is the field to add; this is not a database field, but a [api:FormField] - see the documentation for more details.
"Root.Main" is the tab which the content editor is on. The second argument is the field to add; this is not a database field, but a [FormField](api:SilverStripe\Forms\FormField) - see the documentation for more details.
<div class="hint" markdown="1">
Note: By default, the CMS only has one tab. Creating new tabs is much like adding to existing tabs. For instance: `$fields->addFieldToTab('Root.NewTab', new TextField('Author'));`
would create a new tab called "New Tab", and a single "Author" textfield inside.
</div>
We have added two fields: A simple [api:TextField] and a [api:DateField].
We have added two fields: A simple [TextField](api:SilverStripe\Forms\TextField) and a [DateField](api:SilverStripe\Forms\DateField).
There are many more fields available in the default installation, listed in ["form field types"](/developer_guides/forms/field_types/common_subclasses).
:::php
@ -232,7 +232,7 @@ By enabling *showCalendar* you show a calendar overlay when clicking on the fiel
:::php
$dateField->setConfig('dateformat', 'dd/MM/YYYY');
*dateFormat* allows you to specify how you wish the date to be entered and displayed in the CMS field. See the [api:DateField] documentation for more configuration options.
*dateFormat* allows you to specify how you wish the date to be entered and displayed in the CMS field. See the [DBDateField](api:SilverStripe\ORM\FieldType\DBDateField) documentation for more configuration options.
:::php
$fields->addFieldToTab('Root.Main', new TextField('Author', 'Author Name'), 'Content');
@ -269,13 +269,13 @@ First, the template for displaying a single article:
Most of the code is just like the regular Page.ss, we include an informational div with the date and the author of the Article.
To access the new fields, we use *$Date* and *$Author*. In fact, all template variables and page controls come from either the data object or the controller for the page being displayed. The *$Title* variable comes from the *Title* field of the [api:SiteTree] class. *$Date* and *$Author* come from the *ArticlePage* table through your custom Page. *$Content* comes from the *SiteTree* table through the same data object. The data for your page is
To access the new fields, we use *$Date* and *$Author*. In fact, all template variables and page controls come from either the data object or the controller for the page being displayed. The *$Title* variable comes from the *Title* field of the [SiteTree](api:SilverStripe\CMS\Model\SiteTree) class. *$Date* and *$Author* come from the *ArticlePage* table through your custom Page. *$Content* comes from the *SiteTree* table through the same data object. The data for your page is
spread across several tables in the database matched by id - e.g. *Content* is in the *SiteTree* table, and *Date* and
*Author* are in the *ArticlePage* table. SilverStripe matches this data, and collates it into a single data object.
![](../_images/tutorial2_data-collation.jpg)
Rather than using *$Date* directly, we use *$Date.Nice*. If we look in the [api:Date] documentation, we can see
Rather than using *$Date* directly, we use *$Date.Nice*. If we look in the [DBDate](api:SilverStripe\ORM\FieldType\DBDate) documentation, we can see
that the *Nice* function returns the date in *dd/mm/yyyy* format, rather than the *yyyy-mm-dd* format stored in the
database.
@ -305,7 +305,7 @@ We'll now create a template for the article holder. We want our news section to
</div>
Here we use the page control *Children*. As the name suggests, this control allows you to iterate over the children of a page. In this case, the children are our news articles. The *$Link* variable will give the address of the article which we can use to create a link, and the *FirstParagraph* function of the [api:HTMLText] field gives us a nice summary of the article. The function strips all tags from the paragraph extracted.
Here we use the page control *Children*. As the name suggests, this control allows you to iterate over the children of a page. In this case, the children are our news articles. The *$Link* variable will give the address of the article which we can use to create a link, and the *FirstParagraph* function of the [DBHTMLText](api:SilverStripe\ORM\FieldType\DBHTMLText) field gives us a nice summary of the article. The function strips all tags from the paragraph extracted.
![](../_images/tutorial2_articleholder.jpg)
@ -398,7 +398,7 @@ The controller for a page is only created when page is actually visited, while t
## Creating a RSS feed
An RSS feed is something that no news section should be without. SilverStripe makes it easy to create RSS feeds by providing an [api:RSSFeed] class to do all the hard work for us. Add the following in the *ArticleHolder_Controller* class:
An RSS feed is something that no news section should be without. SilverStripe makes it easy to create RSS feeds by providing an [RSSFeed](api:SilverStripe\Control\RSS\RSSFeed) class to do all the hard work for us. Add the following in the *ArticleHolder_Controller* class:
**mysite/code/ArticleHolder.php**
@ -418,7 +418,7 @@ Ensure that when you have input the code to implement an RSS feed; flush the web
This function creates an RSS feed of all the news articles, and outputs it to the browser. If we go to [http://localhost/your_site_name/news/rss](http://localhost/your_site_name/news/rss) we should see our RSS feed. When there is more to a URL after a page's base URL, "rss" in this case, SilverStripe will call the function with that name on the controller if it exists.
Depending on your browser, you should see something like the picture below. If your browser doesn't support RSS, you will most likely see the XML output instead. For more on RSS, see [api:RSSFeed]
Depending on your browser, you should see something like the picture below. If your browser doesn't support RSS, you will most likely see the XML output instead. For more on RSS, see [RSSFeed](api:SilverStripe\Control\RSS\RSSFeed)
![](../_images/tutorial2_rss-feed.jpg)
@ -483,7 +483,7 @@ Nothing here should be new. The *StaffPage* page type is more interesting though
Instead of adding our *Image* as a field in *$db*, we have used the *$has_one* array. This is because an *Image* is not a simple database field like all the fields we have seen so far, but has its own database table. By using the *$has_one* array, we create a relationship between the *StaffPage* table and the *Image* table by storing the id of the respective *Image* in the *StaffPage* table.
We then add an [api:UploadField] in the *getCMSFields* function to the tab "Root.Images". Since this tab doesn't exist,
We then add an [UploadField](api:SilverStripe\AssetAdmin\Forms\UploadField) in the *getCMSFields* function to the tab "Root.Images". Since this tab doesn't exist,
the *addFieldToTab* function will create it for us. The *UploadField* allows us to select an image or upload a new one in
the CMS.
@ -497,7 +497,7 @@ a new *StaffHolder* called "Staff", and create some *StaffPage*s in it.
### Creating the staff section templates
The staff section templates aren't too difficult to create, thanks to the utility methods provided by the [api:Image] class.
The staff section templates aren't too difficult to create, thanks to the utility methods provided by the [Image](api:SilverStripe\Assets\Image) class.
**themes/simple/templates/Layout/StaffHolder.ss**
@ -521,7 +521,7 @@ The staff section templates aren't too difficult to create, thanks to the utilit
</div>
This template is very similar to the *ArticleHolder* template. The *ScaleWidth* method of the [api:Image] class
This template is very similar to the *ArticleHolder* template. The *ScaleWidth* method of the [Image](api:SilverStripe\Assets\Image) class
will resize the image before sending it to the browser. The resized image is cached, so the server doesn't have to
resize the image every time the page is viewed.

35
docs/en/01_Tutorials/03_Forms.md
View File

@ -82,11 +82,11 @@ $fields = new FieldList(
```
First we create our form fields.
We do this by creating a [api:FieldList] and passing our fields as arguments.
The first field is a [api:TextField] with the name 'Name'.
We do this by creating a [FieldList](api:SilverStripe\Forms\FieldList) and passing our fields as arguments.
The first field is a [TextField](api:SilverStripe\Forms\TextField) with the name 'Name'.
There is a second argument when creating a field which specifies the text on the label of the field. If no second
argument is passed, as in this case, it is assumed the label is the same as the name of the field.
The second field we create is an [api:OptionsetField]. This is a dropdown, and takes a third argument - an
The second field we create is an [OptionsetField](api:SilverStripe\Forms\OptionsetField). This is a dropdown, and takes a third argument - an
array mapping the values to the options listed in the dropdown.
```php
@ -98,14 +98,14 @@ $actions = new FieldList(
After creating the fields, we create the form actions. Form actions appear as buttons at the bottom of the form.
The first argument is the name of the function to call when the button is pressed, and the second is the label of the button.
Here we create a 'Submit' button which calls the 'doBrowserPoll' method, which we will create later.
All the form actions (in this case only one) are collected into a [api:FieldList] object the same way we did with
All the form actions (in this case only one) are collected into a [FieldList](api:SilverStripe\Forms\FieldList) object the same way we did with
the fields.
```php
return new Form($this, 'BrowserPollForm', $fields, $actions);
```
Finally we create the [api:Form] object and return it.
Finally we create the [Form](api:SilverStripe\Forms\Form) object and return it.
The first argument is the controller that contains the form, in most cases '$this'. The second is the name of the method
that returns the form, which is 'BrowserPollForm' in our case. The third and fourth arguments are the
FieldLists containing the fields and form actions respectively.
@ -186,8 +186,8 @@ All going according to plan, if you visit [http://localhost/your_site_name/home/
Great! We now have a browser poll form, but it doesn't actually do anything. In order to make the form work, we have to implement the 'doBrowserPoll()' method that we told it about.
First, we need some way of saving the poll submissions to the database, so we can retrieve the results later. We can do this by creating a new object that extends from [api:DataObject].
If you recall, in the [second tutorial](/tutorials/extending_a_basic_site) we said that all objects that inherit from DataObject and have their own fields are stored in tables the database. Also recall that all pages extend DataObject indirectly through [api:SiteTree]. Here instead of extending SiteTree (or [api:Page]) to create a page type, we will extend [api:DataObject] directly:
First, we need some way of saving the poll submissions to the database, so we can retrieve the results later. We can do this by creating a new object that extends from [DataObject](api:SilverStripe\ORM\DataObject).
If you recall, in the [second tutorial](/tutorials/extending_a_basic_site) we said that all objects that inherit from DataObject and have their own fields are stored in tables the database. Also recall that all pages extend DataObject indirectly through [SiteTree](api:SilverStripe\CMS\Model\SiteTree). Here instead of extending SiteTree (or [Page](api:SilverStripe\CMS\Model\SiteTree\Page)) to create a page type, we will extend [DataObject](api:SilverStripe\ORM\DataObject) directly:
**mysite/code/BrowserPollSubmission.php**
@ -224,7 +224,7 @@ class HomePageController extends PageController
}
```
A function that processes a form submission takes two arguments - the first is the data in the form, the second is the [api:Form] object.
A function that processes a form submission takes two arguments - the first is the data in the form, the second is the [Form](api:SilverStripe\Forms\Form) object.
In our function we create a new *BrowserPollSubmission* object. Since the name of our form fields, and the name of the database fields, are the same we can save the form directly into the data object.
We call the 'write' method to write our data to the database, and '$this->redirectBack()' will redirect the user back to the home page.
@ -239,6 +239,9 @@ Add a namespace import for `SilverStripe\Forms\RequiredFields`, then change the
**mysite/code/HomePage.php**
```php
use SilverStripe\Forms\Form;
use SilverStripe\Forms\RequiredFields;
public function BrowserPollForm()
{
// ...
@ -257,7 +260,7 @@ If we then open the homepage and attempt to submit the form without filling in t
Now that we have a working form, we need some way of showing the results.
The first thing to do is make it so a user can only vote once per session. If the user hasn't voted, show the form, otherwise show the results.
We can do this using a session variable. The [api:Session] class handles all session variables in SilverStripe. First modify the 'doBrowserPoll' to set the session variable 'BrowserPollVoted' when a user votes.
We can do this using a session variable. The [Session](api:SilverStripe\Control\Session) class handles all session variables in SilverStripe. First modify the 'doBrowserPoll' to set the session variable 'BrowserPollVoted' when a user votes.
**mysite/code/HomePageController.php**
@ -287,7 +290,7 @@ class HomePageController extends PageController
// ...
public function BrowserPollForm()
{
if (Session::get('BrowserPollVoted')) {
if (SilverStripe\Control\Session::get('BrowserPollVoted')) {
return false;
}
// ...
@ -302,13 +305,17 @@ Although the form is not shown, you'll still see the 'Browser Poll' heading. We'
Now that we're collecting data, it would be nice to show the results on the website as well. We could simply output every vote, but that's boring. Let's group the results by browser, through the SilverStripe data model.
In the [second tutorial](/tutorials/extending_a_basic_site), we got a collection of news articles for the home page by using the 'ArticleHolder::get()' function, which returns a [api:DataList]. We can get all submissions in the same fashion, through `BrowserPollSubmission::get()`. This list will be the starting point for our result aggregation.
In the [second tutorial](/tutorials/extending_a_basic_site), we got a collection of news articles for the home page by using the 'ArticleHolder::get()' function, which returns a [DataList](api:SilverStripe\ORM\DataList). We can get all submissions in the same fashion, through `BrowserPollSubmission::get()`. This list will be the starting point for our result aggregation.
Add the appropriate namespace imports, then create the function 'BrowserPollResults' on the *HomePageController* class.
**mysite/code/HomePageController.php**
```php
use SilverStripe\ORM\GroupedList;
use SilverStripe\ORM\ArrayList;
use SilverStripe\View\ArrayData;
public function BrowserPollResults()
{
$submissions = new GroupedList(BrowserPollSubmission::get());
@ -331,7 +338,7 @@ This code introduces a few new concepts, so let's step through it.
$submissions = new GroupedList(BrowserPollSubmission::get());
```
First we get all of the `BrowserPollSubmission` records from the database. This returns the submissions as a [api:DataList]. Then we wrap it inside a [api:GroupedList], which adds the ability to group those records. The resulting object will behave just like the original `DataList`, though (with the addition of a `groupBy()` method).
First we get all of the `BrowserPollSubmission` records from the database. This returns the submissions as a [DataList](api:SilverStripe\ORM\DataList). Then we wrap it inside a [GroupedList](api:SilverStripe\ORM\GroupedList), which adds the ability to group those records. The resulting object will behave just like the original `DataList`, though (with the addition of a `groupBy()` method).
```php
$total = $submissions->Count();
@ -349,9 +356,9 @@ foreach ($submissions->groupBy('Browser') as $browserName => $browserSubmissions
}
```
Now we create an empty [api:ArrayList] to hold the data we'll pass to the template. Its similar to [api:DataList], but can hold arbitrary objects rather than just DataObject` instances. Then we iterate over the 'Browser' submissions field.
Now we create an empty [ArrayList](api:SilverStripe\ORM\ArrayList) to hold the data we'll pass to the template. Its similar to [DataList](api:SilverStripe\ORM\DataList), but can hold arbitrary objects rather than just DataObject` instances. Then we iterate over the 'Browser' submissions field.
The `groupBy()` method splits our list by the 'Browser' field passed to it, creating new lists with submissions just for a specific browser. Each of those lists is keyed by the browser name. The aggregated result is then contained in an [api:ArrayData] object, which behaves much like a standard PHP array, but allows us to use it in SilverStripe templates.
The `groupBy()` method splits our list by the 'Browser' field passed to it, creating new lists with submissions just for a specific browser. Each of those lists is keyed by the browser name. The aggregated result is then contained in an [ArrayData](api:SilverStripe\View\ArrayData) object, which behaves much like a standard PHP array, but allows us to use it in SilverStripe templates.
The final step is to create the template to display our data. Change the 'BrowserPoll' div to the below.

2
docs/en/01_Tutorials/04_Site_Search.md
View File

@ -92,7 +92,7 @@ function, and then attempt to render it with *Page_results.ss*, falling back to
## Creating the template
Lastly we need the template for the search page. This template uses all the same techniques used in previous
tutorials. It also uses a number of pagination variables, which are provided by the [api:PaginatedList]
tutorials. It also uses a number of pagination variables, which are provided by the [PaginatedList](api:SilverStripe\ORM\PaginatedList)
class.
*themes/simple/templates/Layout/Page_results.ss*

6
docs/en/01_Tutorials/05_Dataobject_Relationship_Management.md
View File

@ -9,7 +9,7 @@ This tutorial is deprecated, and has been replaced by Lessons 7, 8, 9, and 10 in
## Overview
This tutorial explores the relationship and management of [DataObjects](api:DataObject). It builds on the [second tutorial](/tutorials/extending_a_basic_site) where we learnt how to define
This tutorial explores the relationship and management of [DataObjects](api:SilverStripe\ORM\DataObject). It builds on the [second tutorial](/tutorials/extending_a_basic_site) where we learnt how to define
additional fields on our models, and attach images to them.
## What are we working towards?
@ -205,7 +205,7 @@ It's empty by default, but you can add new students as required,
or relate them to the project by typing in the box above the table.
In our case, we want to manage those records, edit their details, and add new ones.
To accomplish this, we have added a specific [api:GridFieldConfig].
To accomplish this, we have added a specific [GridFieldConfig](api:SilverStripe\Forms\GridField\GridFieldConfig).
While we could've built the config from scratch, there's several
preconfigured instances. The `GridFieldConfig_RecordEditor` default configures
the field to edit records, rather than just viewing them.
@ -502,4 +502,4 @@ we suggest some excercises to make the solution more flexible:
and avoid any duplication between the two subclasses.
* Render mentor details in their own template
* Change the `GridField` to list only five records per page (the default is 20).
This configuration is stored in the [api:GridFieldPaginator] component
This configuration is stored in the [GridFieldPaginator](api:SilverStripe\Forms\GridField\GridFieldPaginator) component

32
docs/en/02_Developer_Guides/00_Model/01_Data_Model_and_ORM.md
View File

@ -10,7 +10,7 @@ information.
* Each database row maps to a PHP object.
* Each database column maps to a property on a PHP object.
All data tables in SilverStripe are defined as subclasses of [api:DataObject]. The [api:DataObject] class represents a
All data tables in SilverStripe are defined as subclasses of [DataObject](api:SilverStripe\ORM\DataObject). The [DataObject](api:SilverStripe\ORM\DataObject) class represents a
single row in a database table, following the ["Active Record"](http://en.wikipedia.org/wiki/Active_record_pattern)
design pattern. Database Columns are defined as [Data Types](/developer_guides/model/data_types_and_casting) in the static `$db` variable
along with any [relationships](relations) defined as `$has_one`, `$has_many`, `$many_many` properties on the class.
@ -65,7 +65,7 @@ You need to be logged in as an administrator to perform this command, unless you
or the command is run through [CLI](../cli).
</div>
When rebuilding the database schema through the [api:ClassLoader] the following additional properties are
When rebuilding the database schema through the [ClassLoader](api:SilverStripe\Core\Manifest\ClassLoader) the following additional properties are
automatically set on the `DataObject`.
* ID: Primary Key. When a new record is created, SilverStripe does not use the database's built-in auto-numbering
@ -107,7 +107,7 @@ Generates the following `SQL`.
## Creating Data Records
A new instance of a [api:DataObject] can be created using the `new` syntax.
A new instance of a [DataObject](api:SilverStripe\ORM\DataObject) can be created using the `new` syntax.
:::php
$player = new Player();
@ -175,7 +175,7 @@ Provided `filter` values are automatically escaped and do not require any escapi
## Lazy Loading
The `ORM` doesn't actually execute the [api:SQLSelect] until you iterate on the result with a `foreach()` or `<% loop %>`.
The `ORM` doesn't actually execute the [SQLSelect](api:SilverStripe\ORM\Queries\SQLSelect) until you iterate on the result with a `foreach()` or `<% loop %>`.
It's smart enough to generate a single efficient query at the last moment in time without needing to post-process the
result set in PHP. In `MySQL` the query generated by the ORM may look something like this
@ -222,7 +222,7 @@ Notice that we can step into the loop safely without having to check if `$player
// do something here
}
See the [Lists](lists) documentation for more information on dealing with [api:SS_List] instances.
See the [Lists](lists) documentation for more information on dealing with [SS_List](api:SilverStripe\ORM\SS_List) instances.
## Returning a single DataObject
@ -232,7 +232,7 @@ can use `byID($id)`:
:::php
$player = Player::get()->byID(5);
`get()` returns a [api:DataList] instance. You can use operations on that to get back a single record.
`get()` returns a [DataList](api:SilverStripe\ORM\DataList) instance. You can use operations on that to get back a single record.
:::php
$players = Player::get();
@ -473,7 +473,7 @@ You can use [SearchFilters](searchfilters) to add additional behavior to your `e
### Subtract
You can subtract entries from a [api:DataList] by passing in another DataList to `subtract()`
You can subtract entries from a [DataList](api:SilverStripe\ORM\DataList) by passing in another DataList to `subtract()`
:::php
$sam = Player::get()->filter('FirstName', 'Sam');
@ -528,7 +528,7 @@ automatically generated for them. In the above case, the table name would have b
`SilverStripe\BannerManager\BannerImage`
When creating raw SQL queries that contain table names, it is necessary to ensure your queries have the correct
table. This functionality can be provided by the [api:DataObjectSchema] service, which can be accessed via
table. This functionality can be provided by the [DataObjectSchema](api:SilverStripe\ORM\DataObjectSchema) service, which can be accessed via
`DataObject::getSchema()`. This service provides the following methods, most of which have a table and class
equivalent version.
@ -566,7 +566,7 @@ Occasionally, the system described above won't let you do exactly what you need
methods that manipulate the SQL query at a lower level. When using these, please ensure that all table and field names
are escaped with double quotes, otherwise some DB backends (e.g. PostgreSQL) won't work.
Under the hood, query generation is handled by the [api:DataQuery] class. This class does provide more direct access
Under the hood, query generation is handled by the [DataQuery](api:SilverStripe\ORM\DataQuery) class. This class does provide more direct access
to certain SQL features that `DataList` abstracts away from you.
In general, we advise against using these methods unless it's absolutely necessary. If the ORM doesn't do quite what
@ -668,7 +668,7 @@ Accessing the data is transparent to the developer.
The way the ORM stores the data is this:
* "Base classes" are direct sub-classes of [api:DataObject]. They are always given a table, whether or not they have
* "Base classes" are direct sub-classes of [DataObject](api:SilverStripe\ORM\DataObject). They are always given a table, whether or not they have
special fields. This is called the "base table". In our case, `SiteTree` is the base table.
* The base table's ClassName field is set to class of the given record. It's an enumeration of all possible
@ -678,9 +678,9 @@ sub-classes of the base class (including the base class itself).
example above, NewsSection didn't have its own data, so an extra table would be redundant.
* In all the tables, ID is the primary key. A matching ID number is used for all parts of a particular record:
record #2 in Page refers to the same object as record #2 in [api:SiteTree].
record #2 in Page refers to the same object as record #2 in [SiteTree](api:SilverStripe\CMS\Model\SiteTree).
To retrieve a news article, SilverStripe joins the [api:SiteTree], [api:Page] and NewsPage tables by their ID fields.
To retrieve a news article, SilverStripe joins the [SiteTree](api:SilverStripe\CMS\Model\SiteTree), [Page](api:SilverStripe\CMS\Model\SiteTree\Page) and NewsPage tables by their ID fields.
## Related Documentation
@ -688,7 +688,7 @@ To retrieve a news article, SilverStripe joins the [api:SiteTree], [api:Page] an
## API Documentation
* [api:DataObject]
* [api:DataList]
* [api:DataQuery]
* [api:DataObjectSchema]
* [DataObject](api:SilverStripe\ORM\DataObject)
* [DataList](api:SilverStripe\ORM\DataList)
* [DataQuery](api:SilverStripe\ORM\DataQuery)
* [DataObjectSchema](api:SilverStripe\ORM\DataObjectSchema)

20
docs/en/02_Developer_Guides/00_Model/02_Relations.md
View File

@ -3,7 +3,7 @@ summary: Relate models together using the ORM using has_one, has_many, and many_
# Relations between Records
In most situations you will likely see more than one [api:DataObject] and several classes in your data model may relate
In most situations you will likely see more than one [DataObject](api:SilverStripe\ORM\DataObject) and several classes in your data model may relate
to one another. An example of this is a `Player` object may have a relationship to one or more `Team` or `Coach` classes
and could take part in many `Games`. Relations are a key part of designing and building a good data model.
@ -132,7 +132,7 @@ available on both ends.
}
Much like the `has_one` relationship, `has_many` can be navigated through the `ORM` as well. The only difference being
you will get an instance of [api:HasManyList] rather than the object.
you will get an instance of [HasManyList](api:SilverStripe\ORM\HasManyList) rather than the object.
:::php
$team = Team::get()->first();
@ -223,8 +223,8 @@ to have the necessary accessors available on both ends.
</div>
Much like the `has_one` relationship, `many_many` can be navigated through the `ORM` as well.
The only difference being you will get an instance of [api:SilverStripe\ORM\ManyManyList] or
[api:SilverStripe\ORM\ManyManyThroughList] rather than the object.
The only difference being you will get an instance of [ManyManyList](api:SilverStripe\ORM\ManyManyList) or
[ManyManyThroughList](api:SilverStripe\ORM\ManyManyThroughList) rather than the object.
:::php
$team = Team::get()->byId(1);
@ -384,7 +384,7 @@ more likely that the user will select Categories for a Product than vice-versa.
## Adding relations
Adding new items to a relations works the same, regardless if you're editing a **has_many** or a **many_many**. They are
encapsulated by [api:HasManyList] and [api:ManyManyList], both of which provide very similar APIs, e.g. an `add()`
encapsulated by [HasManyList](api:SilverStripe\ORM\HasManyList) and [ManyManyList](api:SilverStripe\ORM\ManyManyList), both of which provide very similar APIs, e.g. an `add()`
and `remove()` method.
:::php
@ -404,7 +404,7 @@ and `remove()` method.
You can use the ORM to get a filtered result list without writing any SQL. For example, this snippet gets you the
"Players"-relation on a team, but only containing active players.
See [api:DataObject::$has_many] for more info on the described relations.
See [DataObject::$has_many](api:SilverStripe\ORM\DataObject::$has_many) for more info on the described relations.
:::php
<?php
@ -428,7 +428,7 @@ criteria on the added record.
## Relations on Unsaved Objects
You can also set *has_many* and *many_many* relations before the `DataObject` is saved. This behavior uses the
[api:UnsavedRelationList] and converts it into the correct `RelationList` when saving the `DataObject` for the first
[UnsavedRelationList](api:SilverStripe\ORM\UnsavedRelationList) and converts it into the correct `RelationList` when saving the `DataObject` for the first
time.
This unsaved lists will also recursively save any unsaved objects that they contain.
@ -444,6 +444,6 @@ for displaying the objects contained in the relation.
## API Documentation
* [api:HasManyList]
* [api:ManyManyList]
* [api:DataObject]
* [HasManyList](api:SilverStripe\ORM\HasManyList)
* [ManyManyList](api:SilverStripe\ORM\ManyManyList)
* [DataObject](api:SilverStripe\ORM\DataObject)

20
docs/en/02_Developer_Guides/00_Model/03_Lists.md
View File

@ -3,13 +3,13 @@ summary: The SS_List interface allows you to iterate through and manipulate a li
# Managing Lists
Whenever using the ORM to fetch records or navigate relationships you will receive an [api:SS_List] instance commonly as
either [api:DataList] or [api:RelationList]. This object gives you the ability to iterate over each of the results or
Whenever using the ORM to fetch records or navigate relationships you will receive an [SS_List](api:SilverStripe\ORM\SS_List) instance commonly as
either [DataList](api:SilverStripe\ORM\DataList) or [RelationList](api:SilverStripe\ORM\RelationList). This object gives you the ability to iterate over each of the results or
modify.
## Iterating over the list.
[api:SS_List] implements `IteratorAggregate`, allowing you to loop over the instance.
[SS_List](api:SilverStripe\ORM\SS_List) implements `IteratorAggregate`, allowing you to loop over the instance.
:::php
$members = Member::get();
@ -50,7 +50,7 @@ A map is an array where the array indexes contain data as well as the values. Yo
// 3 => 'Will'
// );
This functionality is provided by the [api:Map] class, which can be used to build a map around any `SS_List`.
This functionality is provided by the [Map](api:SilverStripe\ORM\Map) class, which can be used to build a map around any `SS_List`.
:::php
$members = Member::get();
@ -71,7 +71,7 @@ This functionality is provided by the [api:Map] class, which can be used to buil
## ArrayList
[api:ArrayList] exists to wrap a standard PHP array in the same API as a database backed list.
[ArrayList](api:SilverStripe\ORM\ArrayList) exists to wrap a standard PHP array in the same API as a database backed list.
:::php
$sam = Member::get()->byId(5);
@ -87,8 +87,8 @@ This functionality is provided by the [api:Map] class, which can be used to buil
## API Documentation
* [api:SS_List]
* [api:RelationList]
* [api:DataList]
* [api:ArrayList]
* [api:Map]
* [SS_List](api:SilverStripe\ORM\SS_List)
* [RelationList](api:SilverStripe\ORM\RelationList)
* [DataList](api:SilverStripe\ORM\DataList)
* [ArrayList](api:SilverStripe\ORM\ArrayList)
* [Map](api:SilverStripe\ORM\Map)

48
docs/en/02_Developer_Guides/00_Model/04_Data_Types_and_Casting.md
View File

@ -3,10 +3,10 @@ summary: Learn how how data is stored going in and coming out of the ORM and how
# Data Types and Casting
Each model in a SilverStripe [api:DataObject] will handle data at some point. This includes database columns such as
Each model in a SilverStripe [DataObject](api:SilverStripe\ORM\DataObject) will handle data at some point. This includes database columns such as
the ones defined in a `$db` array or simply a method that returns data for the template.
A Data Type is represented in SilverStripe by a [api:DBField] subclass. The class is responsible for telling the ORM
A Data Type is represented in SilverStripe by a [DBField](api:SilverStripe\ORM\FieldType\DBField) subclass. The class is responsible for telling the ORM
about how to store its data in the database and how to format the information coming out of the database, i.e. on a template.
In the `Player` example, we have four database columns each with a different data type (Int, Varchar).
@ -28,21 +28,21 @@ In the `Player` example, we have four database columns each with a different dat
## Available Types
* [api:Boolean]: A boolean field.
* [api:Currency]: A number with 2 decimal points of precision, designed to store currency values.
* [api:Date]: A date field
* [api:Decimal]: A decimal number.
* [api:Enum]: An enumeration of a set of strings
* [api:HTMLText]: A variable-length string of up to 2MB, designed to store HTML
* [api:HTMLVarchar]: A variable-length string of up to 255 characters, designed to store HTML
* [api:Int]: An integer field.
* [api:Percentage]: A decimal number between 0 and 1 that represents a percentage.
* [api:SS_Datetime]: A date / time field
* [api:Text]: A variable-length string of up to 2MB, designed to store raw text
* [api:Time]: A time field
* [api:Varchar]: A variable-length string of up to 255 characters, designed to store raw text.
* [DBBoolean](api:SilverStripe\ORM\FieldType\DBBoolean): A boolean field.
* [DBCurrency](api:SilverStripe\ORM\FieldType\DBCurrency): A number with 2 decimal points of precision, designed to store currency values.
* [DBDate](api:SilverStripe\ORM\FieldType\DBDate): A date field
* [DBDecimal](api:SilverStripe\ORM\FieldType\DBDecimal): A decimal number.
* [DBEnum](api:SilverStripe\ORM\FieldType\DBEnum): An enumeration of a set of strings
* [DBHTMLText](api:SilverStripe\ORM\FieldType\DBHTMLText): A variable-length string of up to 2MB, designed to store HTML
* [DBHTMLVarchar](api:SilverStripe\ORM\FieldType\DBHTMLVarchar): A variable-length string of up to 255 characters, designed to store HTML
* [DBInt](api:SilverStripe\ORM\FieldType\DBInt): An integer field.
* [DBPercentage](api:SilverStripe\ORM\FieldType\DBPercentage): A decimal number between 0 and 1 that represents a percentage.
* [DBDatetime](api:SilverStripe\ORM\FieldType\DBDatetime): A date / time field
* [DBText](api:SilverStripe\ORM\FieldType\DBText): A variable-length string of up to 2MB, designed to store raw text
* [DBTime](api:SilverStripe\ORM\FieldType\DBTime): A time field
* [DBVarchar](api:SilverStripe\ORM\FieldType\DBVarchar): A variable-length string of up to 255 characters, designed to store raw text.
See the [API documentation](api:DBField) for a full list of available Data Types. You can define your own [api:DBField] instances if required as well.
See the [API documentation](api:SilverStripe\ORM\FieldType\DBField) for a full list of available Data Types. You can define your own [DBField](api:SilverStripe\ORM\FieldType\DBField) instances if required as well.
## Default Values
@ -98,7 +98,7 @@ For example:
The Data Type does more than setup the correct database schema. They can also define methods and formatting helpers for
output. You can manually create instances of a Data Type and pass it through to the template.
If this case, we'll create a new method for our `Player` that returns the full name. By wrapping this in a [api:Varchar]
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**
@ -148,7 +148,7 @@ Rather than manually returning objects from your custom functions. You can use t
}
The properties on any SilverStripe object can be type casted automatically, by transforming its scalar value into an
instance of the [api:DBField] class, providing additional helpers. For example, a string can be cast as a [api:Text]
instance of the [DBField](api:SilverStripe\ORM\FieldType\DBField) class, providing additional helpers. For example, a string can be cast as a [DBText](api:SilverStripe\ORM\FieldType\DBText)
type, which has a `FirstSentence()` method to retrieve the first sentence in a longer piece of text.
On the most basic level, the class can be used as simple conversion class from one value to another, e.g. to round a
@ -157,7 +157,7 @@ number.
:::php
DBField::create_field('Double', 1.23456)->Round(2); // results in 1.23
Of course that's much more verbose than the equivalent PHP call. The power of [api:DBField] comes with its more
Of course that's much more verbose than the equivalent PHP call. The power of [DBField](api:SilverStripe\ORM\FieldType\DBField) comes with its more
sophisticated helpers, like showing the time difference to the current date:
:::php
@ -165,7 +165,7 @@ sophisticated helpers, like showing the time difference to the current date:
## Casting ViewableData
Most objects in SilverStripe extend from [api:ViewableData], which means they know how to present themselves in a view
Most objects in SilverStripe extend from [ViewableData](api:SilverStripe\View\ViewableData), which means they know how to present themselves in a view
context. Through a `$casting` array, arbitrary properties and getters can be casted:
:::php
@ -191,7 +191,7 @@ context. Through a `$casting` array, arbitrary properties and getters can be cas
## Casting HTML Text
The database field types [api:HTMLVarchar]/[api:HTMLText] and [api:Varchar]/[api:Text] are exactly the same in
The database field types [DBHTMLVarchar](api:SilverStripe\ORM\FieldType\DBHTMLVarchar)/[DBHTMLText](api:SilverStripe\ORM\FieldType\DBHTMLText) and [DBVarchar](api:SilverStripe\ORM\FieldType\DBVarchar)/[DBText](api:SilverStripe\ORM\FieldType\DBText) are exactly the same in
the database. However, the template engine knows to escape fields without the `HTML` prefix automatically in templates,
to prevent them from rendering HTML interpreted by browsers. This escaping prevents attacks like CSRF or XSS (see
"[security](../security)"), which is important if these fields store user-provided data.
@ -200,7 +200,7 @@ See the [Template casting](/developer_guides/templates/casting) section for cont
## Overloading
"Getters" and "Setters" are functions that help us save fields to our [api:DataObject] instances. By default, the
"Getters" and "Setters" are functions that help us save fields to our [DataObject](api:SilverStripe\ORM\DataObject) instances. By default, the
methods `getField()` and `setField()` are used to set column data. They save to the protected array, `$obj->record`.
We can overload the default behavior by making a function called "get`<fieldname>`" or "set`<fieldname>`".
@ -223,5 +223,5 @@ database column using `dbObject`.
## API Documentation
* [api:DataObject]
* [api:DBField]
* [DataObject](api:SilverStripe\ORM\DataObject)
* [DBField](api:SilverStripe\ORM\FieldType\DBField)

8
docs/en/02_Developer_Guides/00_Model/05_Extending_DataObjects.md
View File

@ -3,11 +3,11 @@ summary: Modify the data model without using subclasses.
# Extending DataObjects
You can add properties and methods to existing [api:DataObject]s like [api:Member] without hacking core code or sub
classing by using [api:DataExtension]. See the [Extending SilverStripe](../extending) guide for more information on
[api:DataExtension].
You can add properties and methods to existing [DataObject](api:SilverStripe\ORM\DataObject)s like [Member](api:SilverStripe\Security\Member) without hacking core code or sub
classing by using [DataExtension](api:SilverStripe\ORM\DataExtension). See the [Extending SilverStripe](../extending) guide for more information on
[DataExtension](api:SilverStripe\ORM\DataExtension).
The following documentation outlines some common hooks that the [api:Extension] API provides specifically for managing
The following documentation outlines some common hooks that the [Extension](api:SilverStripe\Core\Extension) API provides specifically for managing
data records.
## onBeforeWrite

20
docs/en/02_Developer_Guides/00_Model/06_SearchFilters.md
View File

@ -6,13 +6,13 @@ summary: Use suffixes on your ORM queries.
The `filter` and `exclude` operations specify exact matches by default. However, there are a number of suffixes that
you can put on field names to change this behavior. These are represented as `SearchFilter` subclasses and include.
* [api:StartsWithFilter]
* [api:EndsWithFilter]
* [api:PartialMatchFilter]
* [api:GreaterThanFilter]
* [api:GreaterThanOrEqualFilter]
* [api:LessThanFilter]
* [api:LessThanOrEqualFilter]
* [StartsWithFilter](api:SilverStripe\ORM\Filters\StartsWithFilter)
* [EndsWithFilter](api:SilverStripe\ORM\Filters\EndsWithFilter)
* [PartialMatchFilter](api:SilverStripe\ORM\Filters\PartialMatchFilter)
* [GreaterThanFilter](api:SilverStripe\ORM\Filters\GreaterThanFilter)
* [GreaterThanOrEqualFilter](api:SilverStripe\ORM\Filters\GreaterThanOrEqualFilter)
* [LessThanFilter](api:SilverStripe\ORM\Filters\LessThanFilter)
* [LessThanOrEqualFilter](api:SilverStripe\ORM\Filters\LessThanOrEqualFilter)
An example of a `SearchFilter` in use:
@ -29,14 +29,14 @@ An example of a `SearchFilter` in use:
'LastName:PartialMatch' => 'z'
));
Developers can define their own [api:SearchFilter] if needing to extend the ORM filter and exclude behaviors.
Developers can define their own [SearchFilter](api:SilverStripe\ORM\Filters\SearchFilter) if needing to extend the ORM filter and exclude behaviors.
These suffixes can also take modifiers themselves. The modifiers currently supported are `":not"`, `":nocase"` and
`":case"`. These negate the filter, make it case-insensitive and make it case-sensitive, respectively. The default
comparison uses the database's default. For MySQL and MSSQL, this is case-insensitive. For PostgreSQL, this is
case-sensitive.
Note that all search filters (e.g. `:PartialMatch`) refer to services registered with [api:Injector]
Note that all search filters (e.g. `:PartialMatch`) refer to services registered with [Injector](api:SilverStripe\Core\Injector\Injector)
within the `DataListFilter.` prefixed namespace. New filters can be registered using the below yml
config:
@ -61,4 +61,4 @@ The following is a query which will return everyone whose first name starts with
## API Documentation
* [api:SearchFilter]
* [SearchFilter](api:SilverStripe\ORM\Filters\SearchFilter)

8
docs/en/02_Developer_Guides/00_Model/07_Permissions.md
View File

@ -40,11 +40,11 @@ code.
<div class="alert" markdown="1">
These checks are not enforced on low-level ORM operations such as `write()` or `delete()`, but rather rely on being
checked in the invoking code. The CMS default sections as well as custom interfaces like [api:ModelAdmin] or
[api:GridField] already enforce these permissions.
checked in the invoking code. The CMS default sections as well as custom interfaces like [ModelAdmin](api:SilverStripe\Admin\ModelAdmin) or
[GridField](api:SilverStripe\Forms\GridField\GridField) already enforce these permissions.
</div>
## API Documentation
* [api:DataObject]
* [api:Permission]
* [DataObject](api:SilverStripe\ORM\DataObject)
* [Permission](api:SilverStripe\Security\Permission)

12
docs/en/02_Developer_Guides/00_Model/08_SQL_Select.md
View File

@ -82,7 +82,7 @@ E.g.
echo $row['BirthYear'];
}
The result of `SQLSelect::execute()` is an array lightly wrapped in a database-specific subclass of [api:SS_Query].
The result of `SQLSelect::execute()` is an array lightly wrapped in a database-specific subclass of [Query](api:SilverStripe\ORM\Connect\Query).
This class implements the *Iterator*-interface, and provides convenience-methods for accessing the data.
### DELETE
@ -275,8 +275,8 @@ An alternative approach would be a custom getter in the object definition.
## API Documentation
* [api:DataObject]
* [api:SQLSelect]
* [api:DB]
* [api:Query]
* [api:Database]
* [DataObject](api:SilverStripe\ORM\DataObject)
* [SQLSelect](api:SilverStripe\ORM\Queries\SQLSelect)
* [DB](api:SilverStripe\ORM\DB)
* [Query](api:SilverStripe\ORM\Connect\Query)
* [Database](api:SilverStripe\ORM\Connect\Database)

12
docs/en/02_Developer_Guides/00_Model/09_Validation.md
View File

@ -9,17 +9,17 @@ While this is a useful approach, it can lead to data inconsistencies if the reco
controller and form context.
Most validation constraints are actually data constraints which belong on the model. SilverStripe provides the
[api:DataObject::validate()] method for this purpose.
[DataObject::validate()](api:SilverStripe\ORM\DataObject::validate()) method for this purpose.
By default, there is no validation - objects are always valid! However, you can overload this method in your DataObject
sub-classes to specify custom validation, or use the `validate` hook through a [api:DataExtension].
sub-classes to specify custom validation, or use the `validate` hook through a [DataExtension](api:SilverStripe\ORM\DataExtension).
Invalid objects won't be able to be written - a [api:ValidationException] will be thrown and no write will occur.
Invalid objects won't be able to be written - a [ValidationException](api:SilverStripe\ORM\ValidationException) will be thrown and no write will occur.
It is expected that you call `validate()` in your own application to test that an object is valid before attempting a
write, and respond appropriately if it isn't.
The return value of `validate()` is a [api:ValidationResult] object.
The return value of `validate()` is a [ValidationResult](api:SilverStripe\ORM\ValidationResult) object.
:::php
<?php
@ -44,5 +44,5 @@ The return value of `validate()` is a [api:ValidationResult] object.
## API Documentation
* [api:DataObject]
* [api:ValidationResult];
* [DataObject](api:SilverStripe\ORM\DataObject)
* [ValidationResult](api:SilverStripe\ORM\ValidationResult);

16
docs/en/02_Developer_Guides/00_Model/10_Versioning.md
View File

@ -9,8 +9,8 @@ lifetime of a database record.
It is most commonly applied to pages in the CMS (the `SiteTree` class). Draft content edited in the CMS can be different
from published content shown to your website visitors.
Versioning in SilverStripe is handled through the [api:Versioned] class. As a [api:DataExtension] it is possible to
be applied to any [api:DataObject] subclass. The extension class will automatically update read and write operations
Versioning in SilverStripe is handled through the [Versioned](api:SilverStripe\Versioned\Versioned) class. As a [DataExtension](api:SilverStripe\ORM\DataExtension) it is possible to
be applied to any [DataObject](api:SilverStripe\ORM\DataObject) subclass. The extension class will automatically update read and write operations
done via the ORM via the `augmentSQL` database hook.
Adding Versioned to your `DataObject` subclass works the same as any other extension. It has one of two behaviours,
@ -101,7 +101,7 @@ The record is retrieved as a `DataObject`, but saving back modifications via `wr
rather than modifying the existing one.
</div>
In order to get a list of all versions for a specific record, we need to generate specialized [api:Versioned_Version]
In order to get a list of all versions for a specific record, we need to generate specialized [Versioned_Version](api:SilverStripe\Versioned\Versioned_Version)
objects, which expose the same database information as a `DataObject`, but also include information about when and how
a record was published.
@ -118,9 +118,9 @@ updated on the live stage. Through this mechanism the draft stage is the latest
for any record.
In addition, each call will automatically create a new version in the
`<class>_versions` table. To avoid this, use [api:Versioned::writeWithoutVersion()] instead.
`<class>_versions` table. To avoid this, use [Versioned::writeWithoutVersion()](api:SilverStripe\Versioned\Versioned::writeWithoutVersion()) instead.
To move a saved version from one stage to another, call [writeToStage(<stage>)](api:Versioned->writeToStage()) on the
To move a saved version from one stage to another, call [writeToStage(<stage>)](api:SilverStripe\Versioned\Versioned::writeToStage()) on the
object. The process of moving a version to a different stage is also called "publishing". This can be
done via one of several ways:
@ -242,7 +242,7 @@ E.g.
#### DataObject Ownership in HTML Content
If you are using `[api:HTMLText]` or `[api:HTMLVarchar]` fields in your `DataObject::$db` definitions,
If you are using `[DBHTMLText](api:SilverStripe\ORM\FieldType\DBHTMLText)` or `[DBHTMLVarchar](api:SilverStripe\ORM\FieldType\DBHTMLVarchar)` fields in your `DataObject::$db` definitions,
it's likely that your authors can insert images into those fields via the CMS interface.
These images are usually considered to be owned by the `DataObject`, and should be published alongside it.
The ownership relationship is tracked through an `[image]` [shortcode](/developer-guides/extending/shortcodes),
@ -252,7 +252,7 @@ the shortcode references the database identifier of the `Image` object.
### Custom SQL
We generally discourage writing `Versioned` queries from scratch, due to the complexities involved through joining
multiple tables across an inherited table scheme (see [api:Versioned::augmentSQL()]). If possible, try to stick to
multiple tables across an inherited table scheme (see [Versioned::augmentSQL()](api:SilverStripe\Versioned\Versioned::augmentSQL())). If possible, try to stick to
smaller modifications of the generated `DataList` objects.
Example: Get the first 10 live records, filtered by creation date:
@ -367,4 +367,4 @@ permissions, and avoid exposing unpublished content to your users.
## API Documentation
* [api:Versioned]
* [Versioned](api:SilverStripe\Versioned\Versioned)

16
docs/en/02_Developer_Guides/00_Model/11_Scaffolding.md
View File

@ -4,7 +4,7 @@ summary: A Model-driven approach to defining your application UI.
# Scaffolding
The ORM already has a lot of information about the data represented by a `DataObject` through its `$db` property, so
SilverStripe will use that information to provide scaffold some interfaces. This is done though [api:FormScaffolder]
SilverStripe will use that information to provide scaffold some interfaces. This is done though [FormScaffolder](api:SilverStripe\Forms\FormScaffolder)
to provide reasonable defaults based on the property type (e.g. a checkbox field for booleans). You can then further
customise those fields as required.
@ -72,8 +72,8 @@ system. The default is a set of array values listing the fields.
}
Searchable fields will be appear in the search interface with a default form field (usually a [api:TextField]) and a
default search filter assigned (usually an [api:ExactMatchFilter]). To override these defaults, you can specify
Searchable fields will be appear in the search interface with a default form field (usually a [TextField](api:SilverStripe\Forms\TextField)) and a
default search filter assigned (usually an [ExactMatchFilter](api:SilverStripe\ORM\Filters\ExactMatchFilter)). To override these defaults, you can specify
additional information on `$searchable_fields`:
:::php
@ -87,7 +87,7 @@ additional information on `$searchable_fields`:
);
}
If you assign a single string value, you can set it to be either a [api:FormField] or [api:SearchFilter]. To specify
If you assign a single string value, you can set it to be either a [FormField](api:SilverStripe\Forms\FormField) or [SearchFilter](api:SilverStripe\ORM\Filters\SearchFilter). To specify
both, you can assign an array:
:::php
@ -145,8 +145,8 @@ To include relations (`$has_one`, `$has_many` and `$many_many`) in your search,
### Summary Fields
Summary fields can be used to show a quick overview of the data for a specific [api:DataObject] record. The most common use
is their display as table columns, e.g. in the search results of a [api:ModelAdmin] CMS interface.
Summary fields can be used to show a quick overview of the data for a specific [DataObject](api:SilverStripe\ORM\DataObject) record. The most common use
is their display as table columns, e.g. in the search results of a [ModelAdmin](api:SilverStripe\Admin\ModelAdmin) CMS interface.
:::php
<?php
@ -224,5 +224,5 @@ Non-textual elements (such as images and their manipulations) can also be used i
## API Documentation
* [api:FormScaffolder]
* [api:DataObject]
* [FormScaffolder](api:SilverStripe\Forms\FormScaffolder)
* [DataObject](api:SilverStripe\ORM\DataObject)

2
docs/en/02_Developer_Guides/00_Model/12_Indexes.md
View File

@ -88,4 +88,4 @@ modify an index as the next `dev/build` will `DROP` the index, and then `ADD` it
## API Documentation
* [api:DataObject]
* [DataObject](api:SilverStripe\ORM\DataObject)

4
docs/en/02_Developer_Guides/00_Model/How_Tos/Dynamic_Default_Fields.md
View File

@ -1,8 +1,8 @@
# Dynamic Default Values
The [api:DataObject::$defaults] array allows you to specify simple static values to be the default values when a
The [DataObject::$defaults](api:SilverStripe\ORM\DataObject::$defaults) array allows you to specify simple static values to be the default values when a
record is created, but in many situations default values need to be dynamically calculated. In order to do this, the
[api:DataObject::populateDefaults()] method will need to be overloaded.
[DataObject::populateDefaults()](api:SilverStripe\ORM\DataObject::populateDefaults()) method will need to be overloaded.
This method is called whenever a new record is instantiated, and you must be sure to call the method on the parent
object!

12
docs/en/02_Developer_Guides/00_Model/How_Tos/Grouping_DataObject_Sets.md
View File

@ -1,13 +1,13 @@
# Grouping lists of records
The [api:SS_List] class is designed to return a flat list of records.
The [SS_List](api:SilverStripe\ORM\SS_List) class is designed to return a flat list of records.
These lists can get quite long, and hard to present on a single list.
[Pagination](/developer_guides/templates/how_tos/pagination) is one way to solve this problem,
by splitting up the list into multiple pages.
In this howto, we present an alternative to pagination:
Grouping a list by various criteria, through the [api:GroupedList] class.
This class is a [api:SS_ListDecorator], which means it wraps around a list,
Grouping a list by various criteria, through the [GroupedList](api:SilverStripe\ORM\GroupedList) class.
This class is a [ListDecorator](api:SilverStripe\ORM\ListDecorator), which means it wraps around a list,
adding new functionality.
It provides a `groupBy()` method, which takes a field name, and breaks up the managed list
@ -16,7 +16,7 @@ Similarly, the `GroupedBy()` method builds on this and returns the same data in
## Grouping Sets By First Letter
This example deals with breaking up a [api:SS_List] into sub-headings by the first letter.
This example deals with breaking up a [SS_List](api:SilverStripe\ORM\SS_List) into sub-headings by the first letter.
Let's say you have a set of Module objects, each representing a SilverStripe module, and you want to output a list of
these in alphabetical order, with each letter as a heading; something like the following list:
@ -88,7 +88,7 @@ In this case, the `getTitleFirstLetter()` method defined earlier is used to brea
Grouping a set by month is a very similar process.
The only difference would be to sort the records by month name, and
then create a method on the DataObject that returns the month name,
and pass that to the [api:GroupedList::GroupedBy()] call.
and pass that to the [GroupedList::GroupedBy()](api:SilverStripe\ORM\GroupedList::GroupedBy()) call.
We're reusing our example `Module` object,
but grouping by its built-in `Created` property instead,
@ -128,7 +128,7 @@ sorted by month name from January to December. This can be accomplshed by sortin
}
The final step is the render this into the template using the [api:GroupedList::GroupedBy()] method.
The final step is the render this into the template using the [GroupedList::GroupedBy()](api:SilverStripe\ORM\GroupedList::GroupedBy()) method.
:::ss
// Modules list grouped by the Month Posted

4
docs/en/02_Developer_Guides/00_Model/index.md
View File

@ -2,8 +2,8 @@ title: Model and Databases
summary: Learn how SilverStripe manages database tables, ways to query your database and how to publish data.
introduction: This guide will cover how to create and manipulate data within SilverStripe and how to use the ORM (Object Relational Model) to query data.
In SilverStripe, application data will be represented by a [api:DataObject] class. A `DataObject` subclass defines the
data columns, relationships and properties of a particular data record. For example, [api:Member] is a `DataObject`
In SilverStripe, application data will be represented by a [DataObject](api:SilverStripe\ORM\DataObject) class. A `DataObject` subclass defines the
data columns, relationships and properties of a particular data record. For example, [Member](api:SilverStripe\Security\Member) is a `DataObject`
which stores information about a person, CMS user or mail subscriber.
[CHILDREN Exclude="How_tos"]

22
docs/en/02_Developer_Guides/01_Templates/01_Syntax.md
View File

@ -4,7 +4,7 @@ summary: A look at the operations, variables and language controls you can use w
# Template Syntax
A template can contain any markup language (e.g HTML, CSV, JSON..) and before being rendered to the user, they're
processed through [api:SSViewer]. This process replaces placeholders such as `$Var` with real content from your
processed through [SSViewer](api:SilverStripe\View\SSViewer). This process replaces placeholders such as `$Var` with real content from your
[model](../model) and allows you to define logic controls like `<% if $Var %>`.
An example of a SilverStripe template is below:
@ -113,8 +113,8 @@ Variables can come from your database fields, or custom methods you define on yo
</div>
The variables that can be used in a template vary based on the object currently in [scope](#scope). Scope defines what
object the methods get called on. For the standard `Page.ss` template the scope is the current [api:PageController]
class. This object gives you access to all the database fields on [api:PageController], its corresponding [api:Page]
object the methods get called on. For the standard `Page.ss` template the scope is the current [PageController](api:SilverStripe\CMS\Controllers\ContentController\PageController)
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**
@ -239,7 +239,7 @@ include.
## Looping Over Lists
The `<% loop %>` tag is used to iterate or loop over a collection of items such as [api:DataList] or a [api:ArrayList]
The `<% loop %>` tag is used to iterate or loop over a collection of items such as [DataList](api:SilverStripe\ORM\DataList) or a [ArrayList](api:SilverStripe\ORM\ArrayList)
collection.
:::ss
@ -264,8 +264,8 @@ object that is being looped over.
### Altering the list
`<% loop %>` statements iterate over a [api:DataList] instance. As the template has access to the list object,
templates can call [api:DataList] methods.
`<% loop %>` statements iterate over a [DataList](api:SilverStripe\ORM\DataList) instance. As the template has access to the list object,
templates can call [DataList](api:SilverStripe\ORM\DataList) methods.
Sorting the list by a given field.
@ -408,7 +408,7 @@ In the `<% loop %>` section, we saw an example of two **scopes**. Outside the `<
the scope of the top level `Page`. But inside the loop, we were in the scope of an item in the list (i.e the `Child`)
The scope determines where the value comes from when you refer to a variable. Typically the outer scope of a `Page.ss`
layout template is the [api:PageController] that is currently being rendered.
layout template is the [PageController](api:SilverStripe\CMS\Controllers\ContentController\PageController) that is currently being rendered.
When the scope is a `PageController` it will automatically also look up any methods in the corresponding `Page` data
record. In the case of `$Title` the flow looks like
@ -416,7 +416,7 @@ record. In the case of `$Title` the flow looks like
$Title --> [Looks up: Current PageController and parent classes] --> [Looks up: Current Page and parent classes]
The list of variables you could use in your template is the total of all the methods in the current scope object, parent
classes of the current scope object, and any [api:Extension] instances you have.
classes of the current scope object, and any [Extension](api:SilverStripe\Core\Extension) instances you have.
### Navigating Scope
@ -495,7 +495,7 @@ This is functionalty the same as the following:
Notice that the first example is much tidier, as it removes the repeated use of the `$CurrentMember` accessor.
Outside the `<% with %>.`, we are in the page scope. Inside it, we are in the scope of `$CurrentMember` object. We can
refer directly to properties and methods of the [api:Member] object. `$FirstName` inside the scope is equivalent to
refer directly to properties and methods of the [Member](api:SilverStripe\Security\Member) object. `$FirstName` inside the scope is equivalent to
`$CurrentMember.FirstName`.
### Me
@ -529,5 +529,5 @@ for adding notes for other developers but for things you don't want published in
## API Documentation
* [api:SSViewer]
* [api:SS_TemplateManifest]
* [SSViewer](api:SilverStripe\View\SSViewer)
* [SS_TemplateManifest](api:SS_TemplateManifest)

12
docs/en/02_Developer_Guides/01_Templates/02_Common_Variables.md
View File

@ -10,7 +10,7 @@ currently in scope as well as its' subclasses or extensions.
Knowing what methods you can call can be tricky, but the first step is to understand the scope you're in. Scope is
explained in more detail on the [syntax](syntax#scope) page. Many of the methods listed below can be called from any
scope, and you can specify additional static methods to be available globally in templates by implementing the
[api:TemplateGlobalProvider] interface.
[TemplateGlobalProvider](api:SilverStripe\View\TemplateGlobalProvider) interface.
<div class="notice" markdown="1">
Want a quick way of knowing what scope you're in? Try putting `$ClassName` in your template. You should see a string
@ -49,7 +49,7 @@ A `<% base_tag %>` is nearly always required or assumed by SilverStripe to exist
## CurrentMember
Returns the currently logged in [api:Member] instance, if there is one logged in.
Returns the currently logged in [Member](api:SilverStripe\Security\Member) instance, if there is one logged in.
:::ss
<% if $CurrentMember %>
@ -350,7 +350,7 @@ You can add your own forms by implementing new form instances (see the [Forms tu
## API Documentation
* [api:ContentController]: The main controller responsible for handling pages.
* [api:Controller]: Generic controller (not specific to pages.)
* [api:DataObject]: Underlying model class for page objects.
* [api:ViewableData]: Underlying object class for pretty much anything displayable.
* [ContentController](api:SilverStripe\CMS\Controllers\ContentController): The main controller responsible for handling pages.
* [Controller](api:SilverStripe\Control\Controller): Generic controller (not specific to pages.)
* [DataObject](api:SilverStripe\ORM\DataObject): Underlying model class for page objects.
* [ViewableData](api:SilverStripe\View\ViewableData): Underlying object class for pretty much anything displayable.

20
docs/en/02_Developer_Guides/01_Templates/03_Requirements.md
View File

@ -5,7 +5,7 @@ summary: How to include and require other assets in your templates such as javas
The requirements class takes care of including CSS and JavaScript into your applications. This is preferred to hard
coding any references in the `<head>` tag of your template, as it enables a more flexible handling through the
[api:Requirements] class.
[Requirements](api:SilverStripe\View\Requirements) class.
The examples below are using certain folder naming conventions (CSS files in `css/`, JavaScript files in `javascript/`).
SilverStripe core modules like `cms` use a different naming convention (CSS and JavaScript files in `client/src/`).
@ -27,7 +27,7 @@ Requiring assets from the template is restricted compared to the PHP API.
## PHP Requirements API
It is common practice to include most Requirements either in the *init()*-method of your [controller](../controllers/), or
as close to rendering as possible (e.g. in [api:FormField]).
as close to rendering as possible (e.g. in [FormField](api:SilverStripe\Forms\FormField)).
:::php
<?php
@ -140,7 +140,7 @@ files in order to ensure that current files are served in requests.
By default, files will be generated on demand in the format `assets/_combinedfiles/name-<hash>.js`,
where `<hash>` represents the hash of the source files used to generate that content. The default flysystem backend,
as used by the `[api:AssetStore]` backend, is used for this storage, but it can be substituted for any
as used by the `[AssetStore](api:SilverStripe\Assets\Storage\AssetStore)` backend, is used for this storage, but it can be substituted for any
other backend.
You can also use any of the below options in order to tweak this behaviour:
@ -212,15 +212,15 @@ You can also combine CSS files into a media-specific stylesheets as you would wi
the third paramter of the `combine_files` function:
```php
$loader = ThemeResourceLoader::inst();
$themes = SSViewer::get_themes();
$loader = SilverStripe\View\ThemeResourceLoader::inst();
$themes = SilverStripe\View\SSViewer::get_themes();
$printStylesheets = array(
$loader->findThemedCSS('print_HomePage.css', $themes),
$loader->findThemedCSS('print_Page.css', $themes)
);
Requirements::combine_files('print.css', $printStylesheets, 'print');
SilverStripe\View\Requirements::combine_files('print.css', $printStylesheets, 'print');
```
By default, all requirements files are flushed (deleted) when ?flush querystring parameter is set.
@ -237,15 +237,15 @@ You can also add the 'async' and/or 'defer' attributes to combined Javascript fi
`Requirements::javascript` call - use the third paramter of the `combine_files` function:
```php
$loader = ThemeResourceLoader::inst();
$themes = SSViewer::get_themes();
$loader = SilverStripe\View\ThemeResourceLoader::inst();
$themes = SilverStripe\View\SSViewer::get_themes();
$scripts = array(
$loader->findThemedJavascript('some_script.js', $themes),
$loader->findThemedJavascript('some_other_script.js', $themes)
);
Requirements::combine_files('scripts.js', $scripts, array('async' => true, 'defer' => true));
SilverStripe\View\Requirements::combine_files('scripts.js', $scripts, array('async' => true, 'defer' => true));
```
### Minification of CSS and JS files
@ -353,5 +353,5 @@ If the Javascript files are preferred to be placed in the `<head>` tag rather th
## API Documentation
* [api:Requirements]
* [Requirements](api:SilverStripe\View\Requirements)
* [CMS Architecture and Build Tooling](/developer_guides/customising_the_admin_interface/cms_architecture)

14
docs/en/02_Developer_Guides/01_Templates/04_Rendering_Templates.md
View File

@ -5,7 +5,7 @@ summary: Call and render SilverStripe templates manually.
Templates do nothing on their own. Rather, they are used to render a particular object. All of the `<% if %>`,
`<% loop %>` and other variables are methods or parameters that are called on the current object in
[scope](syntax#scope). All that is necessary is that the object is an instance of [api:ViewableData] (or one of its
[scope](syntax#scope). All that is necessary is that the object is an instance of [ViewableData](api:SilverStripe\View\ViewableData) (or one of its
subclasses).
The following will render the given data into a template. Given the template:
@ -16,13 +16,13 @@ The following will render the given data into a template. Given the template:
<strong>$Name</strong> is the $Role on our team.
```
Our application code can render into that view using `renderWith`. This method is called on the [api:ViewableData]
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**
```php
$arrayData = new ArrayData(array(
$arrayData = new SilverStripe/View/ArrayData(array(
'Name' => 'John',
'Role' => 'Head Coach'
));
@ -34,13 +34,13 @@ echo $arrayData->renderWith('Coach_Message');
<div class="info" markdown="1">
Most classes in SilverStripe you want in your template extend `ViewableData` and allow you to call `renderWith`. This
includes [api:Controller], [api:FormField] and [api:DataObject] instances.
includes [Controller](api:SilverStripe\Control\Controller), [FormField](api:SilverStripe\Forms\FormField) and [DataObject](api:SilverStripe\ORM\DataObject) instances.
</div>
```php
$controller->renderWith(array('MyController', 'MyBaseController'));
Security::getCurrentUser()->renderWith('Member_Profile');
SilverStripe\Security\Security::getCurrentUser()->renderWith('Member_Profile');
```
`renderWith` can be used to override the default template process. For instance, to provide an ajax version of a
@ -71,7 +71,9 @@ does, such as `ArrayData` or `ArrayList`.
```php
<?php
use SilverStripe\View\ArrayData;
use SilverStripe\ORM\ArrayList;
use SilverStripe\Control\Director;
use SilverStripe\CMS\Controllers\ContentController;
class PageController extends ContentController

4
docs/en/02_Developer_Guides/01_Templates/05_Template_Inheritance.md
View File

@ -30,11 +30,11 @@ As we've added a new file, make sure you flush your SilverStripe cache by visiti
Template inheritance works on more than email templates. All files within the `templates` directory including `includes`,
`layout` or anything else from core (or add-on's) template directory can be overridden by being located inside your
`mysite/templates` directory. SilverStripe keeps an eye on what templates have been overridden and the location of the
correct template through a [api:SS_TemplateManifest].
correct template through a [SS_TemplateManifest](api:SS_TemplateManifest).
## Template Manifest
The location of each template and the hierarchy of what template to use is stored within a [api:SS_TemplateManifest]
The location of each template and the hierarchy of what template to use is stored within a [SS_TemplateManifest](api:SS_TemplateManifest)
instance. This is a serialized object containing a map of template names, paths and other meta data for each template
and is cached in your applications `TEMP_FOLDER` for performance. For SilverStripe to find the `GenericEmail` template
it does not check all your `template` folders on the fly, it simply asks the `manifest`.

2
docs/en/02_Developer_Guides/01_Templates/08_Translations.md
View File

@ -27,4 +27,4 @@ string wherever `{name}` appears in that string. In this case, it is assigning a
## API Documentation
* [api:i18n]
* [i18n](api:SilverStripe\i18n\i18n)

12
docs/en/02_Developer_Guides/01_Templates/09_Casting.md
View File

@ -3,12 +3,12 @@ summary: Information on casting, security, modifying data before it's displayed
# Formatting and Casting
All objects that are being rendered in a template should be a [api:ViewableData] instance such as `DataObject`,
All objects that are being rendered in a template should be a [ViewableData](api:SilverStripe\View\ViewableData) instance such as `DataObject`,
`DBField` or `Controller`. From these objects, the template can include any method from the object in
[scope](syntax#scope).
For instance, if we provide a [api:HtmlText] instance to the template we can call the `FirstParagraph` method. This will
output the result of the [api:HtmlText::FirstParagraph()] method to the template.
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**
@ -33,8 +33,8 @@ Any public method from the object in scope can be called within the template. If
<!-- <div class="about-us"> -->
<div class="notice" markdown="1">
See the API documentation for [api:HtmlText], [api:StringField], [api:Text] for all the methods you can use to format
your text instances. For other objects such as [api:SS_Datetime] objects see their respective API documentation pages.
See the API documentation for [DBHtmlText](api:SilverStripe\ORM\FieldType\DBHtmlText), [FieldType](api:SilverStripe\ORM\FieldType), [DBText](api:SilverStripe\ORM\FieldType\DBText) for all the methods you can use to format
your text instances. For other objects such as [DBDatetime](api:SilverStripe\ORM\FieldType\DBDatetime) objects see their respective API documentation pages.
</div>
## forTemplate
@ -125,7 +125,7 @@ instructions on configuring your model to declare casting types for fields.
## Escape methods in templates
Within the template, fields can have their encoding customised at a certain level with format methods.
See [api:DBField] for the specific implementation, but they will generally follow the below rules:
See [DBField](api:SilverStripe\ORM\FieldType\DBField) for the specific implementation, but they will generally follow the below rules:
* `$Field` with no format method supplied will correctly cast itself for the HTML template, as defined
by the casting helper for that field. In most cases this is the best method to use for templates.

14
docs/en/02_Developer_Guides/01_Templates/How_Tos/02_Pagination.md
View File

@ -3,8 +3,8 @@ title: How to Create a Paginated List
# How to Create a Paginated List
In order to create a paginated list, create a method on your controller that first creates a `SS_List` that contains
all your record, then wraps it in a [api:PaginatedList] object. The `PaginatedList` object should also passed the
[api:HTTPRequest] object so it can read the current page information from the "?start=" GET var.
all your record, then wraps it in a [PaginatedList](api:SilverStripe\ORM\PaginatedList) object. The `PaginatedList` object should also passed the
[HTTPRequest](api:SilverStripe\Control\HTTPRequest) object so it can read the current page information from the "?start=" GET var.
The `PaginatedList` will automatically set up query limits and read the request for information.
@ -25,8 +25,8 @@ Note that the concept of "pages" used in pagination does not necessarily mean th
it's just a term to describe a sub-collection of the list.
</div>
There are two ways to generate pagination controls: [api:PaginatedList::Pages()] and
[api:PaginatedList::PaginationSummary()]. In this example we will use `PaginationSummary()`.
There are two ways to generate pagination controls: [PaginatedList::Pages()](api:SilverStripe\ORM\PaginatedList::Pages()) and
[PaginatedList::PaginationSummary()](api:SilverStripe\ORM\PaginatedList::PaginationSummary()). In this example we will use `PaginationSummary()`.
The first step is to simply list the objects in the template:
@ -71,8 +71,8 @@ If there is more than one page, this block will render a set of pagination contr
## Paginating Custom Lists
In some situations where you are generating the list yourself, the underlying list will already contain only the items
that you wish to display on the current page. In this situation the automatic limiting done by [api:PaginatedList]
will break the pagination. You can disable automatic limiting using the [api:PaginatedList::setLimitItems()] method
that you wish to display on the current page. In this situation the automatic limiting done by [PaginatedList](api:SilverStripe\ORM\PaginatedList)
will break the pagination. You can disable automatic limiting using the [PaginatedList::setLimitItems()](api:SilverStripe\ORM\PaginatedList::setLimitItems()) method
when using custom lists.
:::php
@ -108,6 +108,6 @@ list.
## API Documentation
* [api:PaginatedList]
* [PaginatedList](api:SilverStripe\ORM\PaginatedList)

2
docs/en/02_Developer_Guides/01_Templates/index.md
View File

@ -7,7 +7,7 @@ core framework, the modules or themes you install, and your own custom templates
SilverStripe templates are simple text files that have `.ss` extension. They can contain any markup language (e.g HTML,
XML, JSON..) and are processed to add features such as `$Var` to output variables and logic controls like
`<% if $Var %>`. In this guide we'll look at the syntax of the custom template engine [api:SSViewer] and how to render
`<% if $Var %>`. In this guide we'll look at the syntax of the custom template engine [SSViewer](api:SilverStripe\View\SSViewer) and how to render
templates from your controllers.
[CHILDREN Exclude=How_Tos]

14
docs/en/02_Developer_Guides/02_Controllers/01_Introduction.md
View File

@ -3,7 +3,7 @@ summary: A brief look at the definition of a Controller, creating actions and ho
# Introduction to Controllers
The following example is for a simple [api:Controller] class. When building off the SilverStripe Framework you will
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**
@ -67,10 +67,10 @@ It is standard in SilverStripe for your controller actions to be `lowercasewithn
Action methods can return one of four main things:
* an array. In this case the values in the array are available in the templates and the controller completes as usual by returning a [api:HTTPResponse] with the body set to the current template.
* an array. In this case the values in the array are available in the templates and the controller completes as usual by returning a [HTTPResponse](api:SilverStripe\Control\HTTPResponse) with the body set to the current template.
* `HTML`. SilverStripe will wrap the `HTML` into a `HTTPResponse` and set the status code to 200.
* an [api:HTTPResponse] containing a manually defined `status code` and `body`.
* an [api: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.
* 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**
@ -159,7 +159,7 @@ Each controller should define a `Link()` method. This should be used to avoid ha
}
<div class="info" markdown="1">
The [api:Controller::join_links()] is optional, but makes `Link()` more flexible by allowing an `$action` argument, and concatenates the path segments with slashes. The action should map to a method on your controller.
The [Controller::join_links()](api:SilverStripe\Control\Controller::join_links()) is optional, but makes `Link()` more flexible by allowing an `$action` argument, and concatenates the path segments with slashes. The action should map to a method on your controller.
</div>
## Related Documentation
@ -169,6 +169,6 @@ The [api:Controller::join_links()] is optional, but makes `Link()` more flexible
## API Documentation
* [api:Controller]
* [api:Director]
* [Controller](api:SilverStripe\Control\Controller)
* [Director](api:SilverStripe\Control\Director)

14
docs/en/02_Developer_Guides/02_Controllers/02_Routing.md
View File

@ -3,7 +3,7 @@ summary: A more in depth look at how to map requests to particular controllers a
# Routing
Routing is the process of mapping URL's to [api:Controllers] and actions. In the introduction we defined a new custom route
Routing is the process of mapping URL's to [Controller](api:SilverStripe\Control\Controller) and actions. In the introduction we defined a new custom route
for our `TeamController` mapping any `teams` URL to our `TeamController`
<div class="info" markdown="1">
@ -97,7 +97,7 @@ echo $this->getRequest()->param('ID');
## URL Patterns
The [api:RequestHandler] class will parse all rules you specify against the following patterns. The most specific rule
The [RequestHandler](api:SilverStripe\Control\RequestHandler) class will parse all rules you specify against the following patterns. The most specific rule
will be the one followed for the response.
<div class="alert">
@ -148,16 +148,16 @@ pattern does not use the Controller class's default pattern of
a *class name* object" with HTTP status 404.
</div>
In the above example the URLs were configured using the [api:Director] rules in the **routes.yml** file. Alternatively
In the above example the URLs were configured using the [Director](api:SilverStripe\Control\Director) rules in the **routes.yml** file. Alternatively
you can specify these in your Controller class via the **$url_handlers** static array. This array is processed by the
[api:RequestHandler] at runtime once the `Controller` has been matched.
[RequestHandler](api:SilverStripe\Control\RequestHandler) at runtime once the `Controller` has been matched.
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**
```
```php
<?php
use SilverStripe\Control\Controller;
@ -214,7 +214,7 @@ Director:
## Links
* [api:Controller] API documentation
* [api:Director] API documentation
* [Controller](api:SilverStripe\Control\Controller) API documentation
* [Director](api:SilverStripe\Control\Director) API documentation
* [Example routes: framework](https://github.com/silverstripe/silverstripe-framework/blob/master/_config/routes.yml)
* [Example routes: cms](https://github.com/silverstripe/silverstripe-cms/blob/master/_config/routes.yml)

2
docs/en/02_Developer_Guides/02_Controllers/03_Access_Control.md
View File

@ -200,4 +200,4 @@ execution. This behavior can be used to implement permission checks.
## API Documentation
* [api:Controller]
* [Controller](api:SilverStripe\Control\Controller)

2
docs/en/02_Developer_Guides/02_Controllers/04_Redirection.md
View File

@ -44,4 +44,4 @@ For more information on `$url_handlers` see the [Routing](routing) documenation.
## API Documentation
* [api:Controller]
* [Controller](api:SilverStripe\Control\Controller)

4
docs/en/02_Developer_Guides/02_Controllers/05_Middlewares.md
View File

@ -5,7 +5,7 @@ summary: Create objects for modifying request and response objects across contro
HTTP Middlewares allow you to put code that will run before or after. These might be used for
authentication, logging, caching, request processing, and many other purposes. Note this interface
replaces the SilverStripe 3 interface, [api:RequestFilter], which still works but is deprecated.
replaces the SilverStripe 3 interface, [RequestFilter](api:SilverStripe\Control\RequestFilter), which still works but is deprecated.
To create a middleware class, implement `SilverStripe\Control\HTTPMiddleware` and define the
`process(HTTPRequest $request, callbale $delegate)` method. You can do anything you like in this
@ -115,4 +115,4 @@ property. The controller which does the work should be registered under the
## API Documentation
* [api:SilverStripe\Control\HTTPMiddleware]
* [HTTPMiddleware](api:SilverStripe\Control\HTTPMiddleware)

10
docs/en/02_Developer_Guides/02_Controllers/index.md
View File

@ -2,8 +2,8 @@ title: Controllers
summary: Controllers form the backbone of your SilverStripe application. They handle routing URLs to your templates.
introduction: In this guide you will learn how to define a Controller class and how they fit into the SilverStripe response and request cycle.
The [api:Controller] class handles the responsibility of delivering the correct outgoing [api:HTTPResponse] for a
given incoming [api:HTTPRequest]. A request is along the lines of a user requesting the homepage and contains
The [Controller](api:SilverStripe\Control\Controller) class handles the responsibility of delivering the correct outgoing [HTTPResponse](api:SilverStripe\Control\HTTPResponse) for a
given incoming [HTTPRequest](api:SilverStripe\Control\HTTPRequest). A request is along the lines of a user requesting the homepage and contains
information like the URL, any parameters and where they've come from. The response on the other hand is the actual
content of the homepage and the HTTP information we want to give back to the user.
@ -18,6 +18,6 @@ performing and navigating around the permission checks on the users actions.
## API Documentation
* [api:Controller]
* [api:HTTPRequest]
* [api:HTTPResponse]
* [Controller](api:SilverStripe\Control\Controller)
* [HTTPRequest](api:SilverStripe\Control\HTTPRequest)
* [HTTPResponse](api:SilverStripe\Control\HTTPResponse)

42
docs/en/02_Developer_Guides/03_Forms/00_Introduction.md
View File

@ -4,7 +4,7 @@ summary: An introduction to creating a Form instance and handling submissions.
# Forms
The HTML `Form` is the most used way to interact with a user. SilverStripe provides classes to generate forms through
the [api:Form] class, [api:FormField] instances to capture data and submissions through [api:FormAction].
the [Form](api:SilverStripe\Forms\Form) class, [FormField](api:SilverStripe\Forms\FormField) instances to capture data and submissions through [FormAction](api:SilverStripe\Forms\FormAction).
<div class="notice" markdown="1">
See the [Forms Tutorial](../../tutorials/forms/) for a step by step process of creating a `Form`
@ -12,7 +12,7 @@ See the [Forms Tutorial](../../tutorials/forms/) for a step by step process of c
## Creating a Form
Creating a [api:Form] has the following signature.
Creating a [Form](api:SilverStripe\Forms\Form) has the following signature.
:::php
$form = new Form(
@ -84,7 +84,7 @@ variable.
When constructing the `Form` instance (`new Form($controller, $name)`) both controller and name are required. The
`$controller` and `$name` are used to allow SilverStripe to calculate the origin of the `Form object`. When a user
submits the `HelloForm` from your `contact-us` page the form submission will go to `contact-us/HelloForm` before any of
the [api:FormActions]. The URL is known as the `$controller` instance will know the 'contact-us' link and we provide
the [FormAction](api:SilverStripe\Forms\FormAction). The URL is known as the `$controller` instance will know the 'contact-us' link and we provide
`HelloForm` as the `$name` of the form. `$name` **needs** to match the method name.
Because the `HelloForm()` method will be the location the user is taken to, it needs to be handled like any other
@ -98,24 +98,24 @@ private static $allowed_actions = array(
<div class="notice" markdown="1">
Form actions (`doSayHello`), on the other hand, should _not_ be included in `$allowed_actions`; these are handled
separately through [api:Form::httpSubmission()].
separately through [Form::httpSubmission()](api:SilverStripe\Forms\Form::httpSubmission()).
</div>
## Adding FormFields
Fields in a [api:Form] are represented as a single [api:FieldList] instance containing subclasses of [api:FormField].
Some common examples are [api:TextField] or [api:DropdownField].
Fields in a [Form](api:SilverStripe\Forms\Form) are represented as a single [FieldList](api:SilverStripe\Forms\FieldList) instance containing subclasses of [FormField](api:SilverStripe\Forms\FormField).
Some common examples are [TextField](api:SilverStripe\Forms\TextField) or [DropdownField](api:SilverStripe\Forms\DropdownField).
```php
TextField::create($name, $title, $value);
SilverStripe\Forms\TextField::create($name, $title, $value);
```
<div class="info" markdown='1'>
A list of the common FormField subclasses is available on the [Common Subclasses](field_types/common_subclasses/) page.
</div>
The fields are added to the [api:FieldList] `fields` property on the `Form` and can be modified at up to the point the
The fields are added to the [FieldList](api:SilverStripe\Forms\FieldList) `fields` property on the `Form` and can be modified at up to the point the
`Form` is rendered.
```php
@ -133,7 +133,7 @@ $form->setFields($fields);
$fields = $form->getFields();
```
A field can be appended to the [api:FieldList].
A field can be appended to the [FieldList](api:SilverStripe\Forms\FieldList).
```php
$fields = $form->Fields();
@ -173,7 +173,7 @@ information on the CMS interface.
## Modifying FormFields
Each [api:FormField] subclass has a number of methods you can call on it to customise its' behavior or HTML markup. The
Each [FormField](api:SilverStripe\Forms\FormField) subclass has a number of methods you can call on it to customise its' behavior or HTML markup. The
default `FormField` object has several methods for doing common operations.
<div class="notice" markdown="1">
@ -191,7 +191,7 @@ $field
### Custom Templates
The [api:Form] HTML markup and each of the [api:FormField] instances are rendered into templates. You can provide custom
The [Form](api:SilverStripe\Forms\Form) HTML markup and each of the [FormField](api:SilverStripe\Forms\FormField) instances are rendered into templates. You can provide custom
templates by using the `setTemplate` method on either the `Form` or `FormField`. For more details on providing custom
templates see [Form Templates](form_templates)
@ -209,14 +209,14 @@ $field->setFieldHolderTemplate('CustomTextField_Holder');
## Adding FormActions
[api:FormAction] objects are displayed at the bottom of the `Form` in the form of a `button` or `input` tag. When a
[FormAction](api:SilverStripe\Forms\FormAction) objects are displayed at the bottom of the `Form` in the form of a `button` or `input` tag. When a
user presses the button, the form is submitted to the corresponding method.
```php
FormAction::create($action, $title);
```
As with [api:FormField], the actions for a `Form` are stored within a [api:FieldList] instance in the `actions` property
As with [FormField](api:SilverStripe\Forms\FormField), the actions for a `Form` are stored within a [FieldList](api:SilverStripe\Forms\FieldList) instance in the `actions` property
on the form.
```php
@ -273,7 +273,7 @@ thrown.
The `$action` method takes two arguments:
* `$data` an array containing the values of the form mapped from `$name => $value`
* `$form` the submitted [api:Form] instance.
* `$form` the submitted [Form](api:SilverStripe\Forms\Form) instance.
```php
<?php
@ -327,14 +327,14 @@ class PageController extends ContentController
## Validation
Form validation is handled by the [api:Validator] class and the `validator` property on the `Form` object. The validator
is provided with a name of each of the [api:FormField]s to validate and each `FormField` instance is responsible for
Form validation is handled by the [Validator](api:SilverStripe\Forms\Validator) class and the `validator` property on the `Form` object. The validator
is provided with a name of each of the [FormField](api:SilverStripe\Forms\FormField)s to validate and each `FormField` instance is responsible for
validating its' own data value.
For more information, see the [Form Validation](validation) documentation.
```php
$validator = new RequiredFields(array(
$validator = new SilverStripe\Forms\RequiredFields(array(
'Name',
'Email'
));
@ -344,7 +344,7 @@ $form = new Form($this, 'MyForm', $fields, $actions, $validator);
## API Documentation
* [api:Form]
* [api:FormField]
* [api:FieldList]
* [api:FormAction]
* [Form](api:SilverStripe\Forms\Form)
* [FormField](api:SilverStripe\Forms\FormField)
* [FieldList](api:SilverStripe\Forms\FieldList)
* [FormAction](api:SilverStripe\Forms\FormAction)

33
docs/en/02_Developer_Guides/03_Forms/01_Validation.md
View File

@ -3,9 +3,9 @@ summary: Validate form data through the server side validation API.
# Form Validation
SilverStripe provides server-side form validation out of the box through the [api:Validator] class and its' child class
[api:RequiredFields]. A single `Validator` instance is set on each `Form`. Validators are implemented as an argument to
the [api:Form] constructor or through the function `setValidator`.
SilverStripe provides server-side form validation out of the box through the [Validator](api:SilverStripe\Forms\Validator) class and its' child class
[RequiredFields](api:SilverStripe\Forms\RequiredFields). A single `Validator` instance is set on each `Form`. Validators are implemented as an argument to
the [Form](api:SilverStripe\Forms\Form) constructor or through the function `setValidator`.
```php
<?php
@ -59,8 +59,8 @@ In this example we will be required to input a value for `Name` and a valid emai
`doSubmitForm` method is called.
<div class="info" markdown="1">
Each individual [api:FormField] instance is responsible for validating the submitted content through the
[api:FormField::validate()] method. By default, this just checks the value exists. Fields like `EmailField` override
Each individual [FormField](api:SilverStripe\Forms\FormField) instance is responsible for validating the submitted content through the
[FormField::validate()](api:SilverStripe\Forms\FormField::validate()) method. By default, this just checks the value exists. Fields like `EmailField` override
`validate` to check for a specific format.
</div>
@ -189,10 +189,10 @@ data may not need to check the validity of the posted content.
You can disable validation on individual using one of two methods:
```php
$actions = new FieldList(
$action = FormAction::create('doSubmitForm', 'Submit')
$actions = new SilverStripe\Forms\FieldList(
$action = SilverStripe\Forms\FormAction::create('doSubmitForm', 'Submit')
);
$form = new Form($controller, 'MyForm', $fields, $actions);
$form = new SilverStripe\Forms\Form($controller, 'MyForm', $fields, $actions);
// Disable actions on the form action themselves
$action->setValidationExempt(true);
@ -214,6 +214,7 @@ Use `setCustomValidationMessage` to provide a custom message.
```php
$field = new TextField(/* .. */);
$field->setCustomValidationMessage('Whoops, looks like you have missed me!');
```
## JavaScript validation
@ -223,7 +224,7 @@ to provide the information required in order to plug in custom libraries like [P
classes added to each input. For Parsley we can structure the form like.
```php
$form = new Form(/* .. */);
$form = new SilverStripe\Forms\Form(/* .. */);
$form->setAttribute('data-parsley-validate', true);
$field = $fields->dataFieldByName('Name');
@ -235,17 +236,17 @@ $field->setAttribute('data-parsley-mincheck', '2');
## Model Validation
An alternative (or additional) approach to validation is to place it directly on the database model. SilverStripe
provides a [api:DataObject::validate()] method to validate data at the model level. See
provides a [DataObject::validate()](api:SilverStripe\ORM\DataObject::validate()) method to validate data at the model level. See
[Data Model Validation](../model/validation).
## Form action validation
At times it's not possible for all validation or recoverable errors to be pre-determined in advance of form
submission, such as those generated by the form [api:Validator] object. Sometimes errors may occur within form
submission, such as those generated by the form [Validator](api:SilverStripe\Forms\Validator) object. Sometimes errors may occur within form
action methods, and it is necessary to display errors on the form after initial validation has been performed.
In this case you may throw a [api:ValidationException] object within your handler, optionally passing it an
error message, or a [api:ValidationResult] object containing the list of errors you wish to display.
In this case you may throw a [ValidationException](api:SilverStripe\ORM\ValidationException) object within your handler, optionally passing it an
error message, or a [ValidationResult](api:SilverStripe\ORM\ValidationResult) object containing the list of errors you wish to display.
E.g.
@ -274,7 +275,7 @@ class MyController extends Controller
In the CMS, we're not creating the forms for editing CMS records. The `Form` instance is generated for us so we cannot
call `setValidator` easily. However, a `DataObject` can provide its' own `Validator` instance through the
`getCMSValidator()` method. The CMS interfaces such as [api:LeftAndMain], [api:ModelAdmin] and [api:GridField] will
`getCMSValidator()` method. The CMS interfaces such as [LeftAndMain](api:SilverStripe\Admin\LeftAndMain), [ModelAdmin](api:SilverStripe\Admin\ModelAdmin) and [GridField](api:SilverStripe\Forms\GridField\GridField) will
respect the provided `Validator` and handle displaying error and success responses to the user.
<div class="info" markdown="1">
@ -314,5 +315,5 @@ class Page extends SiteTree
## API Documentation
* [api:RequiredFields]
* [api:Validator]
* [RequiredFields](api:SilverStripe\Forms\RequiredFields)
* [Validator](api:SilverStripe\Forms\Validator)

10
docs/en/02_Developer_Guides/03_Forms/03_Form_Templates.md
View File

@ -3,7 +3,7 @@ summary: Customize the generated HTML for a FormField or an entire Form.
# Form Templates
Most markup generated in SilverStripe can be replaced by custom templates. Both [api:Form] and [api:FormField] instances
Most markup generated in SilverStripe can be replaced by custom templates. Both [Form](api:SilverStripe\Forms\Form) and [FormField](api:SilverStripe\Forms\FormField) instances
can be rendered out using custom templates using `setTemplate`.
:::php
@ -31,7 +31,7 @@ While you can override all templates using normal view inheritance (i.e defining
the core template structure. It is recommended to use `setTemplate` and unique templates for specific forms.
</div>
For [api:FormField] instances, there are several other templates that are used on top of the main `setTemplate`.
For [FormField](api:SilverStripe\Forms\FormField) instances, there are several other templates that are used on top of the main `setTemplate`.
:::php
$field = new TextField();
@ -56,7 +56,7 @@ For [api:FormField] instances, there are several other templates that are used o
// field is embedded within another field. For example, if the field is
// part of a `FieldGroup` or `CompositeField` alongside other fields.
All templates are rendered within the scope of the [api:FormField]. To understand more about Scope within Templates as
All templates are rendered within the scope of the [FormField](api:SilverStripe\Forms\FormField). To understand more about Scope within Templates as
well as the available syntax, see the [Templates](../templates) documentation.
## Related Documentation
@ -65,5 +65,5 @@ well as the available syntax, see the [Templates](../templates) documentation.
## API Documentation
* [api:Form]
* [api:FormField]
* [Form](api:SilverStripe\Forms\Form)
* [FormField](api:SilverStripe\Forms\FormField)

8
docs/en/02_Developer_Guides/03_Forms/04_Form_Security.md
View File

@ -9,8 +9,8 @@ should be done as safely as possible. Below outlines the things to consider when
## Cross-Site Request Forgery (CSRF)
SilverStripe protect users against [Cross-Site Request Forgery](https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)
(known as `CSRF`) by adding a SecurityID [api:HiddenField] to each [api:Form] instance. The `SecurityID` contains a
random string generated by [api:SecurityToken] to identify the particular user request vs a third-party forging fake
(known as `CSRF`) by adding a SecurityID [HiddenField](api:SilverStripe\Forms\HiddenField) to each [Form](api:SilverStripe\Forms\Form) instance. The `SecurityID` contains a
random string generated by [SecurityToken](api:SilverStripe\Security\SecurityToken) to identify the particular user request vs a third-party forging fake
requests.
<div class="info" markdown="1">
@ -26,7 +26,7 @@ The `SecurityToken` automatically added looks something like:
// 'c443076989a7f24cf6b35fe1360be8683a753e2c'
This token value is passed through the rendered Form HTML as a [api:HiddenField].
This token value is passed through the rendered Form HTML as a [HiddenField](api:SilverStripe\Forms\HiddenField).
:::html
<input type="hidden" name="SecurityID" value="c443076989a7f24cf6b35fe1360be8683a753e2c" class="hidden" />
@ -73,4 +73,4 @@ module if required. The module provides an consistent API for allowing third-par
## API Documentation
* [api:SecurityToken]
* [SecurityToken](api:SilverStripe\Security\SecurityToken)

10
docs/en/02_Developer_Guides/03_Forms/05_Form_Transformations.md
View File

@ -3,25 +3,25 @@ summary: Provide read-only and disabled views of your Form data.
# Read-only and Disabled Forms
[api:Form] and [api:FormField] instances can be turned into a read-only version for things like confirmation pages or
[Form](api:SilverStripe\Forms\Form) and [FormField](api:SilverStripe\Forms\FormField) instances can be turned into a read-only version for things like confirmation pages or
when certain fields cannot be edited due to permissions. Creating the form is done the same way and markup is similar,
`readonly` mode converts the `input`, `select` and `textarea` tags to static HTML elements like `span`.
To make an entire [api:Form] read-only.
To make an entire [Form](api:SilverStripe\Forms\Form) read-only.
:::php
$form = new Form(..);
$form->makeReadonly();
To make all the fields within a [api:FieldList] read-only (i.e to make fields read-only but not buttons).
To make all the fields within a [FieldList](api:SilverStripe\Forms\FieldList) read-only (i.e to make fields read-only but not buttons).
:::php
$fields = new FieldList(..);
$fields = $fields->makeReadonly();
To make a [api:FormField] read-only you need to know the name of the form field or call it direct on the object
To make a [FormField](api:SilverStripe\Forms\FormField) read-only you need to know the name of the form field or call it direct on the object
:::php
$field = new TextField(..);
@ -41,7 +41,7 @@ To make a [api:FormField] read-only you need to know the name of the form field
## Disabled FormFields
Disabling [api:FormField] instances, sets the `disabled` property on the class. This will use the same HTML markup as
Disabling [FormField](api:SilverStripe\Forms\FormField) instances, sets the `disabled` property on the class. This will use the same HTML markup as
a normal form, but set the `disabled` attribute on the `input` tag.
:::php

16
docs/en/02_Developer_Guides/03_Forms/06_Tabbed_Forms.md
View File

@ -3,20 +3,20 @@ summary: Find out how CMS interfaces use jQuery UI tabs to provide nested FormFi
# Tabbed Forms
SilverStripe's [api:FormScaffolder] can automatically generate [api:Form] instances for certain database models. In the
CMS and other scaffolded interfaces, it will output [api:TabSet] and [api:Tab] objects and use jQuery Tabs to split
SilverStripe's [FormScaffolder](api:SilverStripe\Forms\FormScaffolder) can automatically generate [Form](api:SilverStripe\Forms\Form) instances for certain database models. In the
CMS and other scaffolded interfaces, it will output [TabSet](api:SilverStripe\Forms\TabSet) and [Tab](api:SilverStripe\Forms\Tab) objects and use jQuery Tabs to split
parts of the data model.
<div class="notice" markdown="1">
All interfaces within the CMS such as [api:ModelAdmin] and [api:LeftAndMain] use tabbed interfaces by default.
All interfaces within the CMS such as [ModelAdmin](api:SilverStripe\Admin\ModelAdmin) and [LeftAndMain](api:SilverStripe\Admin\LeftAndMain) use tabbed interfaces by default.
</div>
When dealing with tabbed forms, modifying the fields in the form has a few differences. Each [api:Tab] will be given a
name, and normally they all exist under the `Root` [api:TabSet].
When dealing with tabbed forms, modifying the fields in the form has a few differences. Each [Tab](api:SilverStripe\Forms\Tab) will be given a
name, and normally they all exist under the `Root` [TabSet](api:SilverStripe\Forms\TabSet).
<div class="notice" markdown="1">
[api:TabSet] instances can contain child [api:Tab] and further [api:TabSet] instances, however the CMS UI will only
display up to two levels of tabs in the interface. If you want to group data further than that, try [api:ToggleField].
[TabSet](api:SilverStripe\Forms\TabSet) instances can contain child [Tab](api:SilverStripe\Forms\Tab) and further [TabSet](api:SilverStripe\Forms\TabSet) instances, however the CMS UI will only
display up to two levels of tabs in the interface. If you want to group data further than that, try [ToggleField](api:ToggleField).
</div>
## Adding a field to a tab
@ -52,4 +52,4 @@ display up to two levels of tabs in the interface. If you want to group data fur
## API Documentation
* [api:FormScaffolder]
* [FormScaffolder](api:SilverStripe\Forms\FormScaffolder)

80
docs/en/02_Developer_Guides/03_Forms/Field_types/01_Common_Subclasses.md
View File

@ -3,68 +3,68 @@ summary: A table containing a list of the common FormField subclasses.
# Common FormField type subclasses
This is a high level overview of available [api:FormField] subclasses. An automatically generated list is available
This is a high level overview of available [FormField](api:SilverStripe\Forms\FormField) subclasses. An automatically generated list is available
on the SilverStripe API documentation.
## Basic
* [api:CheckboxField]: Single checkbox field.
* [api:DropdownField]: A `<select>` tag. Can optionally save into has-one relationships.
* [api:ReadonlyField]: Read-only field to display a non-editable value with a label.
* [api:TextareaField]: Multi-line text field.
* [api:TextField]: Single-line text field.
* [api:PasswordField]: Masked input field.
* [CheckboxField](api:SilverStripe\Forms\CheckboxField): Single checkbox field.
* [DropdownField](api:SilverStripe\Forms\DropdownField): A `<select>` tag. Can optionally save into has-one relationships.
* [ReadonlyField](api:SilverStripe\Forms\ReadonlyField): Read-only field to display a non-editable value with a label.
* [TextareaField](api:SilverStripe\Forms\TextareaField): Multi-line text field.
* [TextField](api:SilverStripe\Forms\TextField): Single-line text field.
* [PasswordField](api:SilverStripe\Forms\PasswordField): Masked input field.
## Actions
* [api:FormAction]: Button element for forms, both for `<input type="submit">` and `<button>`.
* [api:ResetFormAction]: Action that clears all fields on a form.
* [FormAction](api:SilverStripe\Forms\FormAction): Button element for forms, both for `<input type="submit">` and `<button>`.
* [ResetFormAction](api:ResetFormAction): Action that clears all fields on a form.
## Formatted input
* [api:ConfirmedPasswordField]: Two masked input fields, checks for matching passwords.
* [api:CurrencyField]: Text field, validating its input as a currency. Limited to US-centric formats, including a hardcoded currency symbol and decimal separators.
See [api:MoneyField] for a more flexible implementation.
* [api:DateField]: Represents a date in a single input field, or separated into day, month, and year. Can optionally use a calendar popup.
* [api:DatetimeField]: Combined date- and time field.
* [api:EmailField]: Text input field with validation for correct email format according to RFC 2822.
* [api:GroupedDropdownField]: Grouped dropdown, using <optgroup> tags.
* [api:HtmlEditorField]: A WYSIWYG editor interface.
* [api:MoneyField]: A form field that can save into a [api:Money] database field.
* [api:NumericField]: Text input field with validation for numeric values.
* [api:OptionsetField]: Set of radio buttons designed to emulate a dropdown.
* [api:SelectionGroup]: SelectionGroup represents a number of fields which are selectable by a radio button that appears at the beginning of each item.
* [api:TimeField]: Input field with time-specific, localised validation.
* [ConfirmedPasswordField](api:SilverStripe\Forms\ConfirmedPasswordField): Two masked input fields, checks for matching passwords.
* [CurrencyField](api:SilverStripe\Forms\CurrencyField): Text field, validating its input as a currency. Limited to US-centric formats, including a hardcoded currency symbol and decimal separators.
See [MoneyField](api:SilverStripe\Forms\MoneyField) for a more flexible implementation.
* [DateField](api:SilverStripe\Forms\DateField): Represents a date in a single input field, or separated into day, month, and year. Can optionally use a calendar popup.
* [DatetimeField](api:SilverStripe\Forms\DatetimeField): Combined date- and time field.
* [EmailField](api:SilverStripe\Forms\EmailField): Text input field with validation for correct email format according to RFC 2822.
* [GroupedDropdownField](api:SilverStripe\Forms\GroupedDropdownField): Grouped dropdown, using <optgroup> tags.
* [HtmlEditorField](api:SilverStripe\Forms\HTMLEditor\HtmlEditorField): A WYSIWYG editor interface.
* [DBMoneyField](api:SilverStripe\ORM\FieldType\DBMoneyField): A form field that can save into a [DBMoney](api:SilverStripe\ORM\FieldType\DBMoney) database field.
* [NumericField](api:SilverStripe\Forms\NumericField): Text input field with validation for numeric values.
* [OptionsetField](api:SilverStripe\Forms\OptionsetField): Set of radio buttons designed to emulate a dropdown.
* [SelectionGroup](api:SilverStripe\Forms\SelectionGroup): SelectionGroup represents a number of fields which are selectable by a radio button that appears at the beginning of each item.
* [TimeField](api:SilverStripe\Forms\TimeField): Input field with time-specific, localised validation.
## Structure
* [api:CompositeField]: Base class for all fields that contain other fields. Uses `<div>` in template, but
* [CompositeField](api:SilverStripe\Forms\CompositeField): Base class for all fields that contain other fields. Uses `<div>` in template, but
doesn't necessarily have any visible styling.
* [api:FieldGroup] attached in CMS-context.
* [api:FieldList]: Basic container for sequential fields, or nested fields through CompositeField.
* [api:TabSet]: Collection of fields which is rendered as separate tabs. Can be nested.
* [api:Tab]: A single tab inside a `TabSet`.
* [api:ToggleCompositeField]: Allows visibility of a group of fields to be toggled.
* [FieldGroup](api:SilverStripe\Forms\FieldGroup) attached in CMS-context.
* [FieldList](api:SilverStripe\Forms\FieldList): Basic container for sequential fields, or nested fields through CompositeField.
* [TabSet](api:SilverStripe\Forms\TabSet): Collection of fields which is rendered as separate tabs. Can be nested.
* [Tab](api:SilverStripe\Forms\Tab): A single tab inside a `TabSet`.
* [ToggleCompositeField](api:SilverStripe\Forms\ToggleCompositeField): Allows visibility of a group of fields to be toggled.
## Files
* [api:FileField]: Simple file upload dialog.
* [FileField](api:SilverStripe\Forms\FileField): Simple file upload dialog.
## Relations
* [api:CheckboxSetField]: Displays a set of checkboxes as a logical group.
* [api:TableField]: In-place editing of tabular data.
* [api:TreeDropdownField]: Dropdown-like field that allows you to select an item from a hierarchical AJAX-expandable tree.
* [api:TreeMultiselectField]: Represents many-many joins using a tree selector shown in a dropdown-like element
* [api:GridField]: Displays a [api:SS_List] in a tabular format. Versatile base class which can be configured to allow editing, sorting, etc.
* [api:ListboxField]: Multi-line listbox field, through `<select multiple>`.
* [CheckboxSetField](api:SilverStripe\Forms\CheckboxSetField): Displays a set of checkboxes as a logical group.
* [TableField](api:TableField): In-place editing of tabular data.
* [TreeDropdownField](api:SilverStripe\Forms\TreeDropdownField): Dropdown-like field that allows you to select an item from a hierarchical AJAX-expandable tree.
* [TreeMultiselectField](api:SilverStripe\Forms\TreeMultiselectField): Represents many-many joins using a tree selector shown in a dropdown-like element
* [GridField](api:SilverStripe\Forms\GridField\GridField): Displays a [SS_List](api:SilverStripe\ORM\SS_List) in a tabular format. Versatile base class which can be configured to allow editing, sorting, etc.
* [ListboxField](api:SilverStripe\Forms\ListboxField): Multi-line listbox field, through `<select multiple>`.
## Utility
* [api:DatalessField] - Base class for fields which add some HTML to the form but don't submit any data or
* [DatalessField](api:SilverStripe\Forms\DatalessField) - Base class for fields which add some HTML to the form but don't submit any data or
save it to the database
* [api:HeaderField]: Renders a simple HTML header element.
* [api:HiddenField] - Renders a hidden input field.
* [api:LabelField]: Simple label tag. This can be used to add extra text in your forms.
* [api:LiteralField]: Renders arbitrary HTML into a form.
* [HeaderField](api:SilverStripe\Forms\HeaderField): Renders a simple HTML header element.
* [HiddenField](api:SilverStripe\Forms\HiddenField) - Renders a hidden input field.
* [LabelField](api:SilverStripe\Forms\LabelField): Simple label tag. This can be used to add extra text in your forms.
* [LiteralField](api:SilverStripe\Forms\LiteralField): Renders arbitrary HTML into a form.

6
docs/en/02_Developer_Guides/03_Forms/Field_types/02_DateField.md
View File

@ -37,7 +37,7 @@ The following example will add a simple DateField to your Page, allowing you to
## Custom Date Format
A custom date format for a [api:DateField] can be provided through `setDateFormat`.
A custom date format for a [DateField](api:SilverStripe\Forms\DateField) can be provided through `setDateFormat`.
This is only necessary if you want to opt-out of the built-in browser localisation via `type=date`.
:::php
@ -81,9 +81,9 @@ field description as an example.
$dateField->setAttribute('placeholder', $dateField->getDateFormat());
<div class="notice" markdown="1">
Fields scaffolded through [api:DataObject::scaffoldCMSFields()] automatically have a description attached to them.
Fields scaffolded through [DataObject::scaffoldCMSFields()](api:SilverStripe\ORM\DataObject::scaffoldCMSFields()) automatically have a description attached to them.
</div>
## API Documentation
* [api:DateField]
* [DateField](api:SilverStripe\Forms\DateField)

50
docs/en/02_Developer_Guides/03_Forms/Field_types/03_HTMLEditorField.md
View File

@ -10,8 +10,8 @@ On top of the base functionality, we use our own insertion dialogs to ensure you
files. In addition to the markup managed by TinyMCE, we use [shortcodes](/developer_guides/extending/shortcodes) to store
information about inserted images or media elements.
The framework comes with a [api:HTMLEditorField] form field class which encapsulates most of the required
functionality. It is usually added through the [api:DataObject::getCMSFields()] method:
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**
@ -33,14 +33,14 @@ functionality. It is usually added through the [api:DataObject::getCMSFields()]
### Specify which configuration to use
By default, a config named 'cms' is used in any new [api:HTMLEditorField].
By default, a config named 'cms' is used in any new [HTMLEditorField](api:SilverStripe\Forms\HTMLEditor\HTMLEditorField).
If you have created your own [api:HtmlEditorConfig] and would like to use it,
you can call `HtmlEditorConfig::set_active('myConfig')` and all subsequently created [api:HTMLEditorField]
If you have created your own [HtmlEditorConfig](api:SilverStripe\Forms\HTMLEditor\HtmlEditorConfig) and would like to use it,
you can call `HtmlEditorConfig::set_active('myConfig')` and all subsequently created [HTMLEditorField](api:SilverStripe\Forms\HTMLEditor\HTMLEditorField)
will use the configuration with the name 'myConfig'.
You can also specify which [api:HtmlEditorConfig] to use on a per field basis via the construct argument.
This is particularly useful if you need different configurations for multiple [api:HTMLEditorField] on the same page or form.
You can also specify which [HtmlEditorConfig](api:SilverStripe\Forms\HTMLEditor\HtmlEditorConfig) to use on a per field basis via the construct argument.
This is particularly useful if you need different configurations for multiple [HTMLEditorField](api:SilverStripe\Forms\HTMLEditor\HTMLEditorField) on the same page or form.
:::php
class MyObject extends DataObject {
@ -62,10 +62,10 @@ In the above example, the 'Content' field will use the default 'cms' config whil
## Configuration
To keep the JavaScript editor configuration manageable and extensible, we've wrapped it in a PHP class called
[api:HtmlEditorConfig]. The class comes with its own defaults, which are extended through the [Configuration API](../../configuration)
[HtmlEditorConfig](api:SilverStripe\Forms\HTMLEditor\HtmlEditorConfig). The class comes with its own defaults, which are extended through the [Configuration API](../../configuration)
in the framework (and the `cms` module in case you've got that installed).
There can be multiple configs, which should always be created / accessed using [api:HtmlEditorConfig::get()]. You can
There can be multiple configs, which should always be created / accessed using [HtmlEditorConfig::get()](api:SilverStripe\Forms\HTMLEditor\HtmlEditorConfig::get()). You can
then set the currently active config using `set_active()`.
<div class="info" markdown="1">
@ -81,7 +81,7 @@ order is alphabetical, so if you set a TinyMCE option in the `aardvark/_config.p
In its simplest form, the configuration of the editor includes adding and removing buttons and plugins.
You can add plugins to the editor using the Framework's [api:HtmlEditorConfig::enablePlugins()] method. This will
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**
@ -108,7 +108,7 @@ Buttons can also be removed:
HtmlEditorConfig::get('cms')->removeButtons('tablecontrols', 'blockquote', 'hr');
<div class="notice" markdown="1">
Internally [api:HtmlEditorConfig] uses the TinyMCE's `theme_advanced_buttons` option to configure these. See the
Internally [HtmlEditorConfig](api:SilverStripe\Forms\HTMLEditor\HtmlEditorConfig) uses the TinyMCE's `theme_advanced_buttons` option to configure these. See the
[TinyMCE documentation of this option](http://www.tinymce.com/wiki.php/Configuration:theme_advanced_buttons_1_n)
for more details.
</div>
@ -145,7 +145,7 @@ The default setting for the CMS's `extended_valid_elements` we are overriding he
## Writing custom plugins
It is also possible to add custom plugins to TinyMCE, for example toolbar buttons.
You can enable them through [api:HtmlEditorConfig::enablePlugins()]:
You can enable them through [HtmlEditorConfig::enablePlugins()](api:SilverStripe\Forms\HTMLEditor\HtmlEditorConfig::enablePlugins()):
**mysite/_config.php**
:::php
@ -155,12 +155,12 @@ You can learn how to [create a plugin](http://www.tinymce.com/wiki.php/Creating_
## Image and media insertion
The [api:HtmlEditorField] API also handles inserting images and media files into the managed HTML content. It can be
used both for referencing files on the webserver filesystem (through the [api:File] and [api:Image] APIs), as well
The [HtmlEditorField](api:SilverStripe\Forms\HTMLEditor\HtmlEditorField) API also handles inserting images and media files into the managed HTML content. It can be
used both for referencing files on the webserver filesystem (through the [File](api:SilverStripe\Assets\File) and [Image](api:SilverStripe\Assets\Image) APIs), as well
as hotlinking files from the web.
We use [shortcodes](/developer_guides/extending/shortcodes) to store information about inserted images or media elements. The
[api:ShortcodeParser] API post-processes the HTML content on rendering, and replaces the shortcodes accordingly. It also
[ShortcodeParser](api:SilverStripe\View\Parsers\ShortcodeParser) API post-processes the HTML content on rendering, and replaces the shortcodes accordingly. It also
takes care of care of placing the shortcode replacements relative to its surrounding markup (e.g. left/right alignment).
## oEmbed: Embedding media through external services
@ -169,7 +169,7 @@ The ["oEmbed" standard](http://www.oembed.com/) is implemented by many media ser
representation of files just by referencing a website URL. For example, a content author can insert a playable youtube
video just by knowing its URL, as opposed to dealing with manual HTML code.
oEmbed powers the "Insert from web" feature available through [api:HtmlEditorField]. Internally, it makes HTTP
oEmbed powers the "Insert from web" feature available through [HtmlEditorField](api:SilverStripe\Forms\HTMLEditor\HtmlEditorField). Internally, it makes HTTP
queries to a list of external services if it finds a matching URL. These services are described in the
`Oembed.providers` configuration. Since these requests are performed on page rendering, they typically have a long
cache time (multiple days).
@ -185,8 +185,8 @@ To disable oEmbed usage, set the `Oembed.enabled` configuration property to "fal
HtmlEditorField can have whitelists set on both the scheme (default http & https) and domains allowed when
inserting files for use with oembed.
This is performed through the config variables `HtmlEditorField_Toolbar::$fileurl_scheme_whitelist` and
`HtmlEditorField_Toolbar::$fileurl_domain_whitelist`.
This is performed through the config variables [RemoteFileFormFactory::$fileurl_scheme_whitelist](api:SilverStripe\AssetAdmin\Forms\RemoteFileFormFactory::$fileurl_scheme_whitelist) and
[RemoteFileFormFactory::$fileurl_domain_whitelist](api:SilverStripe\AssetAdmin\Forms\RemoteFileFormFactory::$fileurl_domain_whitelist).
Setting these configuration variables to empty arrays will disable the whitelist. Setting them to an array of
lower case strings will require the scheme or domain respectively to exactly match one of those strings (no
@ -207,7 +207,7 @@ By default, TinyMCE and SilverStripe will generate valid HTML5 markup, but it wi
`<article>` or `<figure>`. If you plan to use those, add them to the
[valid_elements](http://www.tinymce.com/wiki.php/Configuration:valid_elements) configuration setting.
Also, the [api:HTMLValue] API underpinning the HTML processing parses the markup into a temporary object tree
Also, the [HTMLValue](api:SilverStripe\View\Parsers\HTMLValue) API underpinning the HTML processing parses the markup into a temporary object tree
which can be traversed and modified before saving. The built-in parser only supports HTML4 and XHTML syntax. In order
to successfully process HTML5 tags, please use the
['silverstripe/html5' module](https://github.com/silverstripe/silverstripe-html5).
@ -233,28 +233,28 @@ Example: Remove field for "image captions"
:::php
// File: mysite/_config.php
HtmlEditorField_Toolbar::add_extension('MyToolbarExtension');
ModalController::add_extension('MyToolbarExtension');
Adding functionality is a bit more advanced, you'll most likely
need to add some fields to the PHP forms, as well as write some
JavaScript to ensure the values from those fields make it into the content
elements (and back out in case an existing element gets edited).
There's lots of extension points in the [api:HtmlEditorField_Toolbar] class
There's lots of extension points in the [ModalController](api:SilverStripe\Admin\ModalController) class
to get you started.
### Security groups with their own editor configuration
Different groups of authors can be assigned their own config,
e.g. a more restricted rule set for content reviewers (see the "Security" )
The config is available on each user record through [api:Member::getHtmlEditorConfigForCMS()].
The group assignment is done through the "Security" interface for each [api:Group] record.
The config is available on each user record through [Member::getHtmlEditorConfigForCMS()](api:SilverStripe\Security\Member::getHtmlEditorConfigForCMS()).
The group assignment is done through the "Security" interface for each [Group](api:SilverStripe\Security\Group) record.
Note: The dropdown is only available if more than one config exists.
### Using the editor outside of the CMS
Each interface can have multiple fields of this type, each with their own toolbar to set formatting
and insert HTML elements. They do share one common set of dialogs for inserting links and other media though,
encapsulated in the [api:HtmlEditorField_Toolbar] class.
encapsulated in the [ModalController](api:SilverStripe\Admin\ModalController) class.
In the CMS, those dialogs are automatically instantiate, but in your own interfaces outside
of the CMS you have to take care of instantiate yourself:
@ -281,7 +281,7 @@ WYSIWYG editors are complex beasts, so replacing it completely is a difficult ta
The framework provides a wrapper implementation for the basic required functionality,
mainly around selecting and inserting content into the editor view.
Have a look in `HtmlEditorField.js` and the `ss.editorWrapper` object to get you started
on your own editor wrapper. Note that the [api:HtmlEditorConfig] is currently hardwired to support TinyMCE,
on your own editor wrapper. Note that the [HtmlEditorConfig](api:SilverStripe\Forms\HTMLEditor\HtmlEditorConfig) is currently hardwired to support TinyMCE,
so its up to you to either convert existing configuration as applicable,
or start your own configuration.

64
docs/en/02_Developer_Guides/03_Forms/Field_types/04_GridField.md
View File

@ -3,7 +3,7 @@ summary: How to use the GridField class for managing tabular data.
# GridField
[api:GridField] is SilverStripe's implementation of data grids. The main purpose of the `FormField` is to display
[GridField](api:SilverStripe\Forms\GridField\GridField) is SilverStripe's implementation of data grids. The main purpose of the `FormField` is to display
tabular data in a format that is easy to view and modify. It can be thought of as a HTML table with some tricks.
:::php
@ -16,12 +16,12 @@ GridField can only be used with `$list` data sets that are of the type `SS_List`
</div>
<div class="notice" markdown="1">
[api:GridField] powers the automated data UI of [api:ModelAdmin]. For more information about `ModelAdmin` see the
[GridField](api:SilverStripe\Forms\GridField\GridField) powers the automated data UI of [ModelAdmin](api:SilverStripe\Admin\ModelAdmin). For more information about `ModelAdmin` see the
[Customizing the CMS](/developer_guides/customising_the_admin_interface) guide.
</div>
Each `GridField` is built from a number of components grouped into the [api:GridFieldConfig]. Without any components,
a `GridField` has almost no functionality. The `GridFieldConfig` instance and the attached [api:GridFieldComponent] are
Each `GridField` is built from a number of components grouped into the [GridFieldConfig](api:SilverStripe\Forms\GridField\GridFieldConfig). Without any components,
a `GridField` has almost no functionality. The `GridFieldConfig` instance and the attached [GridFieldComponent](api:SilverStripe\Forms\GridField\GridFieldComponent) are
responsible for all the user interactions including formatting data to be readable, modifying data and performing any
actions such as deleting records.
@ -44,14 +44,14 @@ actions such as deleting records.
}
This will display a bare bones `GridField` instance under `Pages` tab in the CMS. As we have not specified the
`GridField` configuration, the default configuration is an instance of [api:GridFieldConfig_Base] which provides:
`GridField` configuration, the default configuration is an instance of [GridFieldConfig_Base](api:SilverStripe\Forms\GridField\GridFieldConfig_Base) which provides:
* [api:GridFieldToolbarHeader]
* [api:GridFieldSortableHeader]
* [api:GridFieldFilterHeader]
* [api:GridFieldDataColumns]
* [api:GridFieldPageCount]
* [api:GridFieldPaginator]
* [GridFieldToolbarHeader](api:SilverStripe\Forms\GridField\GridFieldToolbarHeader)
* [GridFieldSortableHeader](api:SilverStripe\Forms\GridField\GridFieldSortableHeader)
* [GridFieldFilterHeader](api:SilverStripe\Forms\GridField\GridFieldFilterHeader)
* [GridFieldDataColumns](api:SilverStripe\Forms\GridField\GridFieldDataColumns)
* [GridFieldPageCount](api:SilverStripe\Forms\GridField\GridFieldPageCount)
* [GridFieldPaginator](api:SilverStripe\Forms\GridField\GridFieldPaginator)
The configuration of those `GridFieldComponent` instances and the addition or subtraction of components is done through
the `getConfig()` method on `GridField`.
@ -131,17 +131,17 @@ Fetch a component to modify it later on.
Here is a list of components for use bundled with the core framework. Many more components are provided by third-party
modules and extensions.
- [api:GridFieldToolbarHeader]
- [api:GridFieldSortableHeader]
- [api:GridFieldFilterHeader]
- [api:GridFieldDataColumns]
- [api:GridFieldDeleteAction]
- [api:GridFieldViewButton]
- [api:GridFieldEditButton]
- [api:GridFieldExportButton]
- [api:GridFieldPrintButton]
- [api:GridFieldPaginator]
- [api:GridFieldDetailForm]
- [GridFieldToolbarHeader](api:SilverStripe\Forms\GridField\GridFieldToolbarHeader)
- [GridFieldSortableHeader](api:SilverStripe\Forms\GridField\GridFieldSortableHeader)
- [GridFieldFilterHeader](api:SilverStripe\Forms\GridField\GridFieldFilterHeader)
- [GridFieldDataColumns](api:SilverStripe\Forms\GridField\GridFieldDataColumns)
- [GridFieldDeleteAction](api:SilverStripe\Forms\GridField\GridFieldDeleteAction)
- [GridFieldViewButton](api:SilverStripe\Forms\GridField\GridFieldViewButton)
- [GridFieldEditButton](api:SilverStripe\Forms\GridField\GridFieldEditButton)
- [GridFieldExportButton](api:SilverStripe\Forms\GridField\GridFieldExportButton)
- [GridFieldPrintButton](api:SilverStripe\Forms\GridField\GridFieldPrintButton)
- [GridFieldPaginator](api:SilverStripe\Forms\GridField\GridFieldPaginator)
- [GridFieldDetailForm](api:SilverStripe\Forms\GridField\GridFieldDetailForm)
## Bundled GridFieldConfig
@ -233,7 +233,7 @@ database.
The `GridFieldDetailForm` component drives the record viewing and editing form. It takes its' fields from
`DataObject->getCMSFields()` method but can be customised to accept different fields via the
[api:GridFieldDetailForm::setFields()] method.
[GridFieldDetailForm::setFields()](api:SilverStripe\Forms\GridField\GridFieldDetailForm::setFields()) method.
:::php
$form = $gridField->getConfig()->getComponentByType('GridFieldDetailForm');
@ -244,7 +244,7 @@ The `GridFieldDetailForm` component drives the record viewing and editing form.
### many_many_extraFields
The component also has the ability to load and save data stored on join tables when two records are related via a
"many_many" relationship, as defined through [api:DataObject::$many_many_extraFields]. While loading and saving works
"many_many" relationship, as defined through [DataObject::$many_many_extraFields](api:SilverStripe\ORM\DataObject::$many_many_extraFields). While loading and saving works
transparently, you need to add the necessary fields manually, they're not included in the `getCMSFields()` scaffolding.
These extra fields act like usual form fields, but need to be "namespaced" in order for the `GridField` logic to detect
@ -316,10 +316,10 @@ The goal is for multiple components to share the same space, for example a heade
- `header`/`footer`: Renders in a `<thead>`/`<tfoot>`, should contain table markup
- `before`/`after`: Renders before/after the actual `<table>`
- `buttons-before-left`/`buttons-before-right`/`buttons-after-left`/`buttons-after-right`:
Renders in a shared row before the table. Requires [api:GridFieldButtonRow].
Renders in a shared row before the table. Requires [GridFieldButtonRow](api:SilverStripe\Forms\GridField\GridFieldButtonRow).
These built-ins can be used by passing the fragment names into the constructor of various components. Note that some
[api:GridFieldConfig] classes will already have rows added to them. The following example will add a print button at the
[GridFieldConfig](api:SilverStripe\Forms\GridField\GridFieldConfig) classes will already have rows added to them. The following example will add a print button at the
bottom right of the table.
:::php
@ -351,7 +351,7 @@ processed placeholders as opposed to native template syntax.
</div>
Now you can add other components into this area by returning them as an array from your
[api:GridFieldComponent::getHTMLFragments()] implementation:
[GridFieldComponent::getHTMLFragments()](api:SilverStripe\Forms\GridField\GridFieldComponent::getHTMLFragments()) implementation:
:::php
<?php
@ -365,7 +365,7 @@ Now you can add other components into this area by returning them as an array fr
}
}
Your new area can also be used by existing components, e.g. the [api:GridFieldPrintButton]
Your new area can also be used by existing components, e.g. the [GridFieldPrintButton](api:SilverStripe\Forms\GridField\GridFieldPrintButton)
:::php
new GridFieldPrintButton('my-component-area');
@ -377,7 +377,7 @@ functionality. See [How to Create a GridFieldComponent](../how_tos/create_a_grid
## Creating a Custom GridField_ActionProvider
[api:GridField_ActionProvider] provides row level actions such as deleting a record. See
[GridField_ActionProvider](api:SilverStripe\Forms\GridField\GridField_ActionProvider) provides row level actions such as deleting a record. See
[How to Create a GridField_ActionProvider](../how_tos/create_a_gridfield_actionprovider).
## Saving the GridField State
@ -389,6 +389,6 @@ The `GridState_Component` sets and gets data from the `GridState`.
## API Documentation
* [api:GridField]
* [api:GridFieldConfig]
* [api:GridFieldComponent]
* [GridField](api:SilverStripe\Forms\GridField\GridField)
* [GridFieldConfig](api:SilverStripe\Forms\GridField\GridFieldConfig)
* [GridFieldComponent](api:SilverStripe\Forms\GridField\GridFieldComponent)

2
docs/en/02_Developer_Guides/03_Forms/How_Tos/01_Encapsulate_Forms.md
View File

@ -147,5 +147,5 @@ Form actions can also be defined within your `Form` subclass to keep the entire
## API Documentation
* [api:Form]
* [Form](api:SilverStripe\Forms\Form)

6
docs/en/02_Developer_Guides/03_Forms/How_Tos/02_Lightweight_Form.md
View File

@ -2,10 +2,10 @@ title: How to Create Lightweight Form
# How to Create Lightweight Form
Out of the box, SilverStripe provides a robust and reusable set of HTML markup for [api:FormFields], however this can
Out of the box, SilverStripe provides a robust and reusable set of HTML markup for [FormField](api:SilverStripe\Forms\FormField), however this can
sometimes produce markup which is unnecessarily bloated.
For example, a basic search form. We want to use the [api:Form] API to handle the form but we may want to provide a
For example, a basic search form. We want to use the [Form](api:SilverStripe\Forms\Form) API to handle the form but we may want to provide a
totally custom template to meet our needs. To do this, we'll provide the class with a unique template through
`setTemplate`.
@ -43,7 +43,7 @@ totally custom template to meet our needs. To do this, we'll provide the class w
</form>
`SearchForm.ss` will be executed within the scope of the `Form` object so has access to any of the methods and
properties on [api:Form] such as `$Fields` and `$Actions`.
properties on [Form](api:SilverStripe\Forms\Form) such as `$Fields` and `$Actions`.
<div class="notice">
To understand more about Scope or the syntax for custom templates, read the [Templates](../../templates) guide.

6
docs/en/02_Developer_Guides/03_Forms/How_Tos/04_Create_a_GridField_ActionProvider.md
View File

@ -3,7 +3,7 @@
In a [GridField](/developer_guides/forms/field_types/gridfield) instance each table row can have a
number of actions located the end of the row such as edit or delete actions.
Each action is represented as a instance of a specific class
(e.g [api:GridFieldEditButton]) which has been added to the `GridFieldConfig`
(e.g [GridFieldEditButton](api:SilverStripe\Forms\GridField\GridFieldEditButton)) which has been added to the `GridFieldConfig`
for that `GridField`
As a developer, you can create your own custom actions to be located alongside
@ -78,7 +78,7 @@ below:
## Add the GridFieldCustomAction to the current `GridFieldConfig`
While we're working on the code, to add this new action to the `GridField`, add
a new instance of the class to the [api:GridFieldConfig] object. The `GridField`
a new instance of the class to the [GridFieldConfig](api:SilverStripe\Forms\GridField\GridFieldConfig) object. The `GridField`
[Reference](/developer_guides/forms/field_types/gridfield) documentation has more information about
manipulating the `GridFieldConfig` instance if required.
@ -99,7 +99,7 @@ Now let's go back and dive through the `GridFieldCustomAction` class in more
detail.
First thing to note is that our new class implements two interfaces,
[api:GridField_ColumnProvider] and [api:GridField_ActionProvider].
[GridField_ColumnProvider](api:SilverStripe\Forms\GridField\GridField_ColumnProvider) and [GridField_ActionProvider](api:SilverStripe\Forms\GridField\GridField_ActionProvider).
Each interface allows our class to define particular behaviors and is a core
concept of the modular `GridFieldConfig` system.

6
docs/en/02_Developer_Guides/03_Forms/How_Tos/05_Simple_Contact_Form.md
View File

@ -34,14 +34,14 @@ There's quite a bit in this function, so we'll step through one piece at a time.
new TextareaField('Message')
);
First we create all the fields we want in the contact form, and put them inside a FieldList. You can find a list of form fields available on the [api:FormField] page.
First we create all the fields we want in the contact form, and put them inside a FieldList. You can find a list of form fields available on the [FormField](api:SilverStripe\Forms\FormField) page.
:::php
$actions = FieldList(
new FormAction('submit', 'Submit')
);
We then create a [api:FieldList] of the form actions, or the buttons that submit the form. Here we add a single form action, with the name 'submit', and the label 'Submit'. We'll use the name of the form action later.
We then create a [FieldList](api:SilverStripe\Forms\FieldList) of the form actions, or the buttons that submit the form. Here we add a single form action, with the name 'submit', and the label 'Submit'. We'll use the name of the form action later.
:::php
return new Form($this, 'Form', $fields, $actions);
@ -104,7 +104,7 @@ The final thing we do is return a 'thank you for your feedback' message to the u
All forms have some basic validation built in – email fields will only let the user enter email addresses, number fields will only accept numbers, and so on. Sometimes you need more complicated validation, so you can define your own validation by extending the Validator class.
The framework comes with a predefined validator called [api:RequiredFields], which performs the common task of making sure particular fields are filled out. Below is the code to add validation to a contact form:
The framework comes with a predefined validator called [RequiredFields](api:SilverStripe\Forms\RequiredFields), which performs the common task of making sure particular fields are filled out. Below is the code to add validation to a contact form:
:::php
public function Form() {

6
docs/en/02_Developer_Guides/03_Forms/index.md
View File

@ -2,7 +2,7 @@ title: Forms
summary: Capture user information through Forms. This guide will work through how to create SilverStripe forms, adding and modifying fields and how to handle form submissions.
introduction: This guide will work through how to create SilverStripe forms, adding and modifying fields and how to handle form submissions.
The [api:Form] class provides a way to create interactive forms in your web application with very little effort.
The [Form](api:SilverStripe\Forms\Form) class provides a way to create interactive forms in your web application with very little effort.
SilverStripe handles generating the correct semantic HTML markup for the form and each of the fields, as well as the
framework for dealing with submissions and validation.
@ -18,5 +18,5 @@ framework for dealing with submissions and validation.
## API Documentation
* [api:Form]
* [api:FormField]
* [Form](api:SilverStripe\Forms\Form)
* [FormField](api:SilverStripe\Forms\FormField)

6
docs/en/02_Developer_Guides/04_Configuration/00_Configuration.md
View File

@ -3,7 +3,7 @@ summary: SilverStripe's YAML based Configuration API for setting runtime configu
# Configuration API
SilverStripe comes with a comprehensive code based configuration system through the [api:Config] class. It primarily
SilverStripe comes with a comprehensive code based configuration system through the [Config](api:SilverStripe\Core\Config\Config) class. It primarily
relies on declarative [YAML](http://en.wikipedia.org/wiki/YAML) files, and falls back to procedural PHP code, as well
as PHP static variables. This is provided by the [silverstripe/config](https://github.com/silverstripe/silverstripe-config)
library.
@ -47,7 +47,7 @@ be marked `private static` and follow the `lower_case_with_underscores` structur
## Accessing and Setting Configuration Properties
This can be done by calling the static method [api:Config::inst()], like so:
This can be done by calling the static method [Config::inst()](api:SilverStripe\Core\Config\Config::inst()), like so:
:::php
$config = Config::inst()->get('MyClass', 'property');
@ -334,4 +334,4 @@ That is, the fragment will be included if all Only rules match, except if all Ex
## API Documentation
* [api:Config]
* [Config](api:SilverStripe\Core\Config\Config)

4
docs/en/02_Developer_Guides/04_Configuration/01_SiteConfig.md
View File

@ -30,7 +30,7 @@ To access variables in the PHP:
## Extending SiteConfig
To extend the options available in the panel, define your own fields via a [api:DataExtension].
To extend the options available in the panel, define your own fields via a [DataExtension](api:SilverStripe\ORM\DataExtension).
**mysite/code/extensions/CustomSiteConfig.php**
@ -69,4 +69,4 @@ provide the users a place to configure settings then the `SiteConfig` panel is t
## API Documentation
* [api:SiteConfig]
* [SiteConfig](api:SilverStripe\SiteConfig\SiteConfig)

26
docs/en/02_Developer_Guides/05_Extending/01_Extensions.md
View File

@ -3,12 +3,12 @@ summary: Extensions and DataExtensions let you modify and augment objects transp
# Extensions and DataExtensions
An [api:Extension] allows for adding additional functionality to a [api:Object] or modifying existing functionality
without the hassle of creating a subclass. Developers can add Extensions to any [api:Object] subclass within core, modules
An [Extension](api:SilverStripe\Core\Extension) allows for adding additional functionality to a [Object](api:Object) or modifying existing functionality
without the hassle of creating a subclass. Developers can add Extensions to any [Object](api:Object) subclass within core, modules
or even their own code to make it more reusable.
Extensions are defined as subclasses of either [api:DataExtension] for extending a [api:DataObject] subclass or
the [api:Extension] class for non DataObject subclasses (such as [api:Controllers])
Extensions are defined as subclasses of either [DataExtension](api:SilverStripe\ORM\DataExtension) for extending a [DataObject](api:SilverStripe\ORM\DataObject) subclass or
the [Extension](api:SilverStripe\Core\Extension) class for non DataObject subclasses (such as [Controller](api:SilverStripe\Control\Controller))
<div class="info" markdown="1">
For performance reasons a few classes are excluded from receiving extensions, including `Object`, `ViewableData`
@ -54,7 +54,7 @@ Alternatively, we can add extensions through PHP code (in the `_config.php` file
This class now defines a `MyMemberExtension` that applies to all `Member` instances on the website. It will have
transformed the original `Member` class in two ways:
* Added a new [api:SS_Datetime] for the users date of birth, and;
* Added a new [DBDatetime](api:SilverStripe\ORM\FieldType\DBDatetime) for the users date of birth, and;
* Added a `SayHi` method to output `Hi <User>`
From within the extension we can add more functions, database fields, relations or other properties and have them added
@ -98,7 +98,7 @@ $has_one etc.
## Adding Methods
Methods that have a unique name will be called as part of the `__call` method on [api:Object]. In the previous example
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**
@ -119,7 +119,7 @@ we added a `SayHi` method which is unique to our extension.
If the `Extension` needs to modify an existing method it's a little trickier. It requires that the method you want to
customise has provided an *Extension Hook* in the place where you want to modify the data. An *Extension Hook* is done
through the [api:Object::extend()] method.
through the [Object::extend()](api:Object::extend()) method.
**framework/security/Member.php**
@ -199,7 +199,7 @@ you need to provide extension hooks at the beginning of the method use `before{.
## Owner
In your [api:Extension] class you can only refer to the source object through the `owner` property on the class as
In your [Extension](api:SilverStripe\Core\Extension) class you can only refer to the source object through the `owner` property on the class as
`$this` will refer to your `Extension` instance.
:::php
@ -215,8 +215,8 @@ In your [api:Extension] class you can only refer to the source object through th
## Checking to see if an Object has an Extension
To see what extensions are currently enabled on an object, use [api:Object::getExtensionInstances()] and
[api:Object::hasExtension()]
To see what extensions are currently enabled on an object, use [Object::getExtensionInstances()](api:Object::getExtensionInstances()) and
[Object::hasExtension()](api:Object::hasExtension())
:::php
@ -281,9 +281,9 @@ This method is preferred to disabling, enabling, and calling field extensions ma
## Related Documentaion
* [Injector](injector/)
* [api:Object::useCustomClass]
* [Object::useCustomClass](api:Object::useCustomClass)
## API Documentation
* [api:Extension]
* [api:DataExtension]
* [Extension](api:SilverStripe\Core\Extension)
* [DataExtension](api:SilverStripe\ORM\DataExtension)

10
docs/en/02_Developer_Guides/05_Extending/04_Shortcodes.md
View File

@ -3,7 +3,7 @@ summary: Flexible content embedding
# Shortcodes
The [api:ShortcodeParser] API is simple parser that allows you to map specifically formatted content to a callback to
The [ShortcodeParser](api:SilverStripe\View\Parsers\ShortcodeParser) API is simple parser that allows you to map specifically formatted content to a callback to
transform them into something else. You might know this concept from forum software which don't allow you to insert
direct HTML, instead resorting to a custom syntax.
@ -31,9 +31,9 @@ Here's some syntax variations:
#
[my_shortcode,myparameter="value"]Enclosed Content[/my_shortcode]
Shortcodes are automatically parsed on any database field which is declared as [api:HTMLValue] or [api:HTMLText],
Shortcodes are automatically parsed on any database field which is declared as [HTMLValue](api:SilverStripe\View\Parsers\HTMLValue) or [DBHTMLText](api:SilverStripe\ORM\FieldType\DBHTMLText),
when rendered into a template. This means you can use shortcodes on common fields like `SiteTree.Content`, and any
other [api:DataObject::$db] definitions of these types.
other [DataObject::$db](api:SilverStripe\ORM\DataObject::$db) definitions of these types.
Other fields can be manually parsed with shortcodes through the `parse` method.
@ -104,7 +104,7 @@ Links to internal `File` database records work exactly the same, but with the `[
### Images
Images inserted through the "Insert Media" form (WYSIWYG editor) need to retain a relationship with
the underlying `[api:Image]` database record. The `[image]` shortcode saves this database reference
the underlying `[Image](api:SilverStripe\Assets\Image)` database record. The `[image]` shortcode saves this database reference
instead of hard-linking to the filesystem path of a given image.
[image id="99" alt="My text"]
@ -229,4 +229,4 @@ The parser will raise an error if it can not find a matching opening tag for any
## API Documentation
* [api:ShortcodeParser]
* [ShortcodeParser](api:SilverStripe\View\Parsers\ShortcodeParser)

8
docs/en/02_Developer_Guides/05_Extending/05_Injector.md
View File

@ -3,7 +3,7 @@ summary: Introduction to using Dependency Injection within SilverStripe.
# Injector
The [api:Injector] class is the central manager of inter-class dependencies in SilverStripe. It offers developers the
The [Injector](api:SilverStripe\Core\Injector\Injector) class is the central manager of inter-class dependencies in SilverStripe. It offers developers the
ability to declare the dependencies a class type has, or to change the nature of the dependencies defined by other
developers.
@ -139,7 +139,7 @@ Note: undefined variables will be replaced with null.
## Factories
Some services require non-trivial construction which means they must be created by a factory class. To do this, create
a factory class which implements the [api:SilverStripe\Framework\Injector\Factory] interface. You can then specify
a factory class which implements the [Factory](api:SilverStripe\Framework\Injector\Factory) interface. You can then specify
the `factory` key in the service definition, and the factory service will be used.
An example using the `MyFactory` service to create instances of the `MyService` service is shown below:
@ -281,5 +281,5 @@ This is useful when writing test cases, as certain services may be necessary to
## API Documentation
* [api:Injector]
* [api:Factory]
* [Injector](api:SilverStripe\Core\Injector\Injector)
* [Factory](api:SilverStripe\Core\Injector\Factory)

12
docs/en/02_Developer_Guides/05_Extending/06_Aspects.md
View File

@ -88,7 +88,7 @@ object that's made use of above.
password: pass
database: write_database
This means that whenever something asks the [api:Injector] for the `WriteMySQLDatabase` object, it'll receive an object
This means that whenever something asks the [Injector](api:SilverStripe\Core\Injector\Injector) for the `WriteMySQLDatabase` object, it'll receive an object
of type `MySQLDatabase`, configured to point at the 'write_database'.
Next, this should be bound into an instance of the `Aspect` class
@ -115,7 +115,7 @@ Next, we need to define the database connection that will be used for all non-wr
password: pass
database: read_database
The final piece that ties everything together is the [api:AopProxyService] instance that will be used as the replacement
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**
@ -191,7 +191,7 @@ code instead of the actual return value of the called method.
## API Documentation
* [api:AopProxyService]
* [api:BeforeCallAspect]
* [api:AfterCallAspect]
* [api:Injector]
* [AopProxyService](api:SilverStripe\Core\Injector\AopProxyService)
* [BeforeCallAspect](api:SilverStripe\Core\Injector\BeforeCallAspect)
* [AfterCallAspect](api:SilverStripe\Core\Injector\AfterCallAspect)
* [Injector](api:SilverStripe\Core\Injector\Injector)

8
docs/en/02_Developer_Guides/06_Testing/00_Unit_Testing.md
View File

@ -46,9 +46,9 @@ Test case classes should end with `Test` (e.g `PageTest`) and test methods must
Ensure you [import](http://php.net/manual/en/language.namespaces.importing.php#example-252) any classes you need for the test, including `SilverStripe\Dev\SapphireTest` or `SilverStripe\Dev\FunctionalTest`.
</div>
A SilverStripe unit test is created by extending one of two classes, [api:SapphireTest] or [api:FunctionalTest].
A SilverStripe unit test is created by extending one of two classes, [SapphireTest](api:SilverStripe\Dev\SapphireTest) or [FunctionalTest](api:SilverStripe\Dev\FunctionalTest).
[api:SapphireTest] is used to test your model logic (such as a `DataObject`), and [api:FunctionalTest] is used when
[SapphireTest](api:SilverStripe\Dev\SapphireTest) is used to test your model logic (such as a `DataObject`), and [FunctionalTest](api:SilverStripe\Dev\FunctionalTest) is used when
you want to test a `Controller`, `Form` or anything that requires a web page.
<div class="info" markdown="1">
@ -206,5 +206,5 @@ It's important to remember that the `parent::setUp();` functions will need to be
## API Documentation
* [api:SapphireTest]
* [api:FunctionalTest]
* [SapphireTest](api:SilverStripe\Dev\SapphireTest)
* [FunctionalTest](api:SilverStripe\Dev\FunctionalTest)

12
docs/en/02_Developer_Guides/06_Testing/01_Functional_Testing.md
View File

@ -3,16 +3,16 @@ summary: Test controllers, forms and HTTP responses.
# Functional Testing
[api:FunctionalTest] test your applications `Controller` logic and anything else which requires a web request. The
[FunctionalTest](api:SilverStripe\Dev\FunctionalTest) test your applications `Controller` logic and anything else which requires a web request. The
core idea of these tests is the same as `SapphireTest` unit tests but `FunctionalTest` adds several methods for
creating [api:HTTPRequest], receiving [api:HTTPResponse] objects and modifying the current user session.
creating [HTTPRequest](api:SilverStripe\Control\HTTPRequest), receiving [HTTPResponse](api:SilverStripe\Control\HTTPResponse) objects and modifying the current user session.
## Get
:::php
$page = $this->get($url);
Performs a GET request on $url and retrieves the [api:HTTPResponse]. This also changes the current page to the value
Performs a GET request on $url and retrieves the [HTTPResponse](api:SilverStripe\Control\HTTPResponse). This also changes the current page to the value
of the response.
## Post
@ -20,7 +20,7 @@ of the response.
:::php
$page = $this->post($url);
Performs a POST request on $url and retrieves the [api:HTTPResponse]. This also changes the current page to the value
Performs a POST request on $url and retrieves the [HTTPResponse](api:SilverStripe\Control\HTTPResponse). This also changes the current page to the value
of the response.
## Submit
@ -28,7 +28,7 @@ of the response.
:::php
$submit = $this->submitForm($formID, $button = null, $data = array());
Submits the given form (`#ContactForm`) on the current page and returns the [api:HTTPResponse].
Submits the given form (`#ContactForm`) on the current page and returns the [HTTPResponse](api:SilverStripe\Control\HTTPResponse).
## LogInAs
@ -103,4 +103,4 @@ assertion fails if one of the expectedMatches fails to appear.
## API Documentation
* [api:FunctionalTest]
* [FunctionalTest](api:SilverStripe\Dev\FunctionalTest)

10
docs/en/02_Developer_Guides/06_Testing/04_Fixtures.md
View File

@ -6,7 +6,7 @@ summary: Populate test databases with fake seed data.
To test functionality correctly, we must use consistent data. If we are testing our code with the same data each
time, we can trust our tests to yield reliable results and to identify when the logic changes. Each test run in
SilverStripe starts with a fresh database containing no records. `Fixtures` provide a way to describe the initial data
to load into the database. The [api:SapphireTest] class takes care of populating a test database with data from
to load into the database. The [SapphireTest](api:SilverStripe\Dev\SapphireTest) class takes care of populating a test database with data from
fixtures - all we have to do is define them.
Fixtures are defined in `YAML`. `YAML` is a markup language which is deliberately simple and easy to read, so it is
@ -151,7 +151,7 @@ As of SilverStripe 4 you will need to use fully qualfied class names in your YAM
Players: =>MyProject\Model\Player.john
<div class="notice" markdown="1">
If your tests are failing and your database has table names that follow the fully qualified class names, you've probably forgotten to implement `private static $table_name = 'Player';` on your namespaced class. This property was introduced in SilverStripe 4 to reduce data migration work. See [api:DataObject] for an example.
If your tests are failing and your database has table names that follow the fully qualified class names, you've probably forgotten to implement `private static $table_name = 'Player';` on your namespaced class. This property was introduced in SilverStripe 4 to reduce data migration work. See [DataObject](api:SilverStripe\ORM\DataObject) for an example.
</div>
### Defining many_many_extraFields
@ -219,7 +219,7 @@ To provide the value for the `many_many_extraField` use the YAML list syntax.
While manually defined fixtures provide full flexibility, they offer very little in terms of structure and convention.
Alternatively, you can use the [api:FixtureFactory] class, which allows you to set default values, callbacks on object
Alternatively, you can use the [FixtureFactory](api:SilverStripe\Dev\FixtureFactory) class, which allows you to set default values, callbacks on object
creation, and dynamic/lazy value setting.
<div class="hint" markdown='1'>
@ -340,6 +340,6 @@ equal the class names they manage.
## API Documentation
* [api:FixtureFactory]
* [api:FixtureBlueprint]
* [FixtureFactory](api:SilverStripe\Dev\FixtureFactory)
* [FixtureBlueprint](api:SilverStripe\Dev\FixtureBlueprint)

8
docs/en/02_Developer_Guides/06_Testing/How_Tos/00_Write_a_SapphireTest.md
View File

@ -2,7 +2,7 @@ title: How to write a SapphireTest
# How to write a SapphireTest
Here is an example of a test which extends [api:SapphireTest] to test the URL generation of the page. It also showcases
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**
@ -63,7 +63,7 @@ The test database is rebuilt every time one of these methods is run.
Inside our test method is the `objFromFixture` method that will generate an object for us based on data from our fixture
file. To identify to the object, we provide a class name and an identifier. The identifier is specified in the YAML file
but not saved in the database anywhere, `objFromFixture` looks the [api:DataObject] up in memory rather than using the
but not saved in the database anywhere, `objFromFixture` looks the [DataObject](api:SilverStripe\ORM\DataObject) up in memory rather than using the
database. This means that you can use it to test the functions responsible for looking up content in the database.
The final part of our test is an assertion command, `assertEquals`. An assertion command allows us to test for something
@ -81,5 +81,5 @@ For more information on PHPUnit's assertions see the [PHPUnit manual](http://www
## API Documentation
* [api:SapphireTest]
* [api:FunctionalTest]
* [SapphireTest](api:SilverStripe\Dev\SapphireTest)
* [FunctionalTest](api:SilverStripe\Dev\FunctionalTest)

8
docs/en/02_Developer_Guides/06_Testing/How_Tos/01_Write_a_FunctionalTest.md
View File

@ -2,9 +2,9 @@ title: How to write a FunctionalTest
# How to Write a FunctionalTest
[api:FunctionalTest] test your applications `Controller` instances and anything else which requires a web request. The
core of these tests are the same as `SapphireTest` unit tests but add several methods for creating [api:HTTPRequest]
and receiving [api:HTTPResponse] objects. In this How To, we'll see how to write a test to query a page, check the
[FunctionalTest](api:SilverStripe\Dev\FunctionalTest) test your applications `Controller` instances and anything else which requires a web request. The
core of these tests are the same as `SapphireTest` unit tests but add several methods for creating [HTTPRequest](api:SilverStripe\Control\HTTPRequest)
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**
@ -53,4 +53,4 @@ response and modify the session within a test.
## API Documentation
* [api:FunctionalTest]
* [FunctionalTest](api:SilverStripe\Dev\FunctionalTest)

6
docs/en/02_Developer_Guides/06_Testing/How_Tos/02_FixtureFactories.md
View File

@ -2,7 +2,7 @@ title: How to use a FixtureFactory
# How to use a FixtureFactory
The [api:FixtureFactory] is used to manually create data structures for use with tests. For more information on fixtures
The [FixtureFactory](api:SilverStripe\Dev\FixtureFactory) is used to manually create data structures for use with tests. For more information on fixtures
see the [Fixtures](../fixtures) documentation.
In this how to we'll use a `FixtureFactory` and a custom blue print for giving us a shortcut for creating new objects
@ -46,5 +46,5 @@ with information that we need.
## API Documentation
* [api:FixtureFactory]
* [api:FixtureBlueprint]
* [FixtureFactory](api:SilverStripe\Dev\FixtureFactory)
* [FixtureBlueprint](api:SilverStripe\Dev\FixtureBlueprint)

8
docs/en/02_Developer_Guides/06_Testing/How_Tos/03_Testing_Email.md
View File

@ -2,8 +2,8 @@ title: How to test emails within unit tests
# Testing Email within Unit Tests
SilverStripe's test system has built-in support for testing emails sent using the [api:Email] class. If you are
running a [api:SapphireTest] test, then it holds off actually sending the email, and instead lets you assert that an
SilverStripe's test system has built-in support for testing emails sent using the [Email](api:SilverStripe\Control\Email\Email) class. If you are
running a [SapphireTest](api:SilverStripe\Dev\SapphireTest) test, then it holds off actually sending the email, and instead lets you assert that an
email was sent using this method.
:::php
@ -15,7 +15,7 @@ email was sent using this method.
$e->send();
}
To test that `MyMethod` sends the correct email, use the [api:SapphireTest::assertEmailSent()] method.
To test that `MyMethod` sends the correct email, use the [SapphireTest::assertEmailSent()](api:SilverStripe\Dev\SapphireTest::assertEmailSent()) method.
:::php
$this->assertEmailSent($to, $from, $subject, $body);
@ -36,5 +36,5 @@ Each of the arguments (`$to`, `$from`, `$subject` and `$body`) can be either one
## API Documentation
* [api:Email]
* [Email](api:SilverStripe\Control\Email\Email)

2
docs/en/02_Developer_Guides/06_Testing/index.md
View File

@ -85,7 +85,7 @@ should have the appropriate permissions to create new databases on your server,
## Writing Tests
Tests are written by creating subclasses of [api:SapphireTest]. You should put tests for your site in the
Tests are written by creating subclasses of [SapphireTest](api:SilverStripe\Dev\SapphireTest). You should put tests for your site in the
`mysite/tests` directory. If you are writing tests for a module, put them in the `(modulename)/tests` directory.
Generally speaking, there should be one test class for each application class. The name of the test class should be the

2
docs/en/02_Developer_Guides/07_Debugging/00_Environment_Types.md
View File

@ -35,7 +35,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 [api:BasicAuth] integration if you
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:
:::yml

2
docs/en/02_Developer_Guides/07_Debugging/02_URL_Variable_Tools.md
View File

@ -27,7 +27,7 @@ Append the option and corresponding value to your URL in your browser's address
| isDev | | 1 | | Put the site into [development mode](../), enabling debugging messages to the browser on a live server. For security, you'll be asked to log in with an administrator log-in. Will persist for the current browser session. |
| isTest | | 1 | | See above. |
| debug | | 1 | | Show a collection of debugging information about the director / controller operation |
| debug_request | | 1 | | Show all steps of the request from initial [api:HTTPRequest] to [api:Controller] to Template Rendering |
| debug_request | | 1 | | Show all steps of the request from initial [HTTPRequest](api:SilverStripe\Control\HTTPRequest) to [Controller](api:SilverStripe\Control\Controller) to Template Rendering |
## Classes and Objects

8
docs/en/02_Developer_Guides/07_Debugging/index.md
View File

@ -15,7 +15,7 @@ bottle-necks and identify slow moving parts of your application chain.
## Debugging Utilities
The [api:Debug] class contains a number of static utility methods for more advanced debugging.
The [Debug](api:SilverStripe\Dev\Debug) class contains a number of static utility methods for more advanced debugging.
:::php
Debug::show($myVariable);
@ -29,6 +29,6 @@ The [api:Debug] class contains a number of static utility methods for more advan
## API Documentation
* [api:SS_Log]
* [api:Backtrace]
* [api:Debug]
* [SS_Log](api:SS_Log)
* [Backtrace](api:SilverStripe\Dev\Backtrace)
* [Debug](api:SilverStripe\Dev\Debug)

4
docs/en/02_Developer_Guides/08_Performance/00_Partial_Caching.md
View File

@ -35,7 +35,7 @@ Here are some more complex examples:
<% end_cached %>
An additional global key is incorporated in the cache lookup. The default value for this is
`$CurrentReadingMode, $CurrentUser.ID`. This ensures that the current [api:Versioned] state and user ID are used.
`$CurrentReadingMode, $CurrentUser.ID`. This ensures that the current [Versioned](api:SilverStripe\Versioned\Versioned) state and user ID are used.
This may be configured by changing the config value of `SSViewer.global_key`. It is also necessary to flush the
template caching when modifying this config, as this key is cached within the template itself.
@ -53,7 +53,7 @@ user does not influence your template content, you can update this key as below;
Often you want to invalidate a cache when any object in a set of objects change, or when the objects in a relationship
change. To do this, SilverStripe introduces the concept of Aggregates. These calculate and return SQL aggregates
on sets of [api:DataObject]s - the most useful for us being the `max` aggregate.
on sets of [DataObject](api:SilverStripe\ORM\DataObject)s - the most useful for us being the `max` aggregate.
For example, if we have a menu, we want that menu to update whenever _any_ page is edited, but would like to cache it
otherwise. By using aggregates, we do that like this:

8
docs/en/02_Developer_Guides/08_Performance/01_Caching.md
View File

@ -8,10 +8,10 @@ By default, the storage mechanism chooses the most performant adapter available
The most common caches are manifests of various resources:
* PHP class locations ([api:ClassManifest])
* Template file locations and compiled templates ([api:SS_TemplateManifest])
* Configuration settings from YAML files ([api:ConfigManifest])
* Language files ([api:i18n])
* PHP class locations ([ClassManifest](api:SilverStripe\Core\Manifest\ClassManifest))
* Template file locations and compiled templates ([SS_TemplateManifest](api:SS_TemplateManifest))
* Configuration settings from YAML files ([ConfigManifest](api:ConfigManifest))
* Language files ([i18n](api:SilverStripe\i18n\i18n))
Flushing the various manifests is performed through a GET
parameter (`flush=1`). Since this action requires more server resources than normal requests,

4
docs/en/02_Developer_Guides/08_Performance/02_HTTP_Cache_Headers.md
View File

@ -29,8 +29,8 @@ clause in `Cache-Control` and `Pragma` will be included.
:::php
HTTP::register_modification_date('2014-10-10');
Used to set the modification date to something more recent than the default. [api:DataObject::__construct] calls
[api:HTTP::register_modification_date(] whenever a record comes from the database ensuring the newest date is present.
Used to set the modification date to something more recent than the default. [DataObject::__construct](api:SilverStripe\ORM\DataObject::__construct) calls
[HTTP::register_modification_date(](api:SilverStripe\Control\HTTP::register_modification_date() whenever a record comes from the database ensuring the newest date is present.
### Vary: cache header

32
docs/en/02_Developer_Guides/09_Security/00_Member.md
View File

@ -4,11 +4,11 @@ title: Members
## Introduction
The [api:Member] class is used to represent user accounts on a SilverStripe site (including newsletter recipients).
The [Member](api:SilverStripe\Security\Member) class is used to represent user accounts on a SilverStripe site (including newsletter recipients).
## Testing For Logged In Users
The [api:Member] class comes with 2 static methods for getting information about the current logged in user.
The [Member](api:SilverStripe\Security\Member) class comes with 2 static methods for getting information about the current logged in user.
**Member::currentUserID()**
@ -39,11 +39,11 @@ Returns the full *Member* Object for the current user, returns *null* if user is
## Subclassing
<div class="warning" markdown="1">
This is the least desirable way of extending the [api:Member] class. It's better to use [api:DataExtension]
This is the least desirable way of extending the [Member](api:SilverStripe\Security\Member) class. It's better to use [DataExtension](api:SilverStripe\ORM\DataExtension)
(see below).
</div>
You can define subclasses of [api:Member] to add extra fields or functionality to the built-in membership system.
You can define subclasses of [Member](api:SilverStripe\Security\Member) to add extra fields or functionality to the built-in membership system.
:::php
class MyMember extends Member {
@ -54,7 +54,7 @@ You can define subclasses of [api:Member] to add extra fields or functionality t
}
To ensure that all new members are created using this class, put a call to [api:Object::useCustomClass()] in
To ensure that all new members are created using this class, put a call to [Object::useCustomClass()](api:Object::useCustomClass()) in
(project)/_config.php:
:::php
@ -65,8 +65,8 @@ Note that if you want to look this class-name up, you can call Object::getCustom
## Overloading getCMSFields()
If you overload the built-in public function getCMSFields(), then you can change the form that is used to view & edit member
details in the newsletter system. This function returns a [api:FieldList] object. You should generally start by calling
parent::getCMSFields() and manipulate the [api:FieldList] from there.
details in the newsletter system. This function returns a [FieldList](api:SilverStripe\Forms\FieldList) object. You should generally start by calling
parent::getCMSFields() and manipulate the [FieldList](api:SilverStripe\Forms\FieldList) from there.
:::php
public function getCMSFields() {
@ -80,11 +80,11 @@ parent::getCMSFields() and manipulate the [api:FieldList] from there.
## Extending Member or DataObject?
Basic rule: Class [api:Member] should just be extended for entities who have some kind of login.
If you have different types of [api:Member]s in the system, you have to make sure that those with login-capabilities have
Basic rule: Class [Member](api:SilverStripe\Security\Member) should just be extended for entities who have some kind of login.
If you have different types of [Member](api:SilverStripe\Security\Member)s in the system, you have to make sure that those with login-capabilities have
unique email-addresses (as this is used for login-credentials).
For persons without login-capabilities (e.g. for an address-database), you shouldn't extend [api:Member] to avoid conflicts
with the Member-database. This enables us to have a different subclass of [api:Member] for an email-address with login-data,
For persons without login-capabilities (e.g. for an address-database), you shouldn't extend [Member](api:SilverStripe\Security\Member) to avoid conflicts
with the Member-database. This enables us to have a different subclass of [Member](api:SilverStripe\Security\Member) for an email-address with login-data,
and another subclass for the same email-address in the address-database.
## Member Role Extension
@ -98,9 +98,9 @@ class. A better way is to use role extensions to add this behaviour. Add the fol
extensions:
- MyMemberExtension
A role extension is simply a subclass of [api:DataExtension] that is designed to be used to add behaviour to [api:Member].
A role extension is simply a subclass of [DataExtension](api:SilverStripe\ORM\DataExtension) that is designed to be used to add behaviour to [Member](api:SilverStripe\Security\Member).
The roles affect the entire class - all members will get the additional behaviour. However, if you want to restrict
things, you should add appropriate [api:Permission::checkMember()] calls to the role's methods.
things, you should add appropriate [Permission::checkMember()](api:SilverStripe\Security\Permission::checkMember()) calls to the role's methods.
:::php
class MyMemberExtension extends DataExtension {
@ -131,8 +131,8 @@ things, you should add appropriate [api:Permission::checkMember()] calls to the
Logins can be "remembered" across multiple devices when user checks the "Remember Me" box. By default, a new login token
will be created and associated with the device used during authentication. When user logs out, all previously saved tokens
for all devices will be revoked, unless `[api:RememberLoginHash::$logout_across_devices] is set to false. For extra security,
single tokens can be enforced by setting `[api:RememberLoginHash::$force_single_token] to true.
for all devices will be revoked, unless `[RememberLoginHash::$logout_across_devices](api:SilverStripe\Security\RememberLoginHash::$logout_across_devices) is set to false. For extra security,
single tokens can be enforced by setting `[RememberLoginHash::$force_single_token](api:SilverStripe\Security\RememberLoginHash::$force_single_token) to true.
## Acting as another user ##
@ -170,4 +170,4 @@ E.g.
## API Documentation
[api:Member]
[Member](api:SilverStripe\Security\Member)

12
docs/en/02_Developer_Guides/09_Security/01_Access_Control.md
View File

@ -35,7 +35,7 @@ privileges from its parent group.
## Permission checking is at class level
SilverStripe provides a security mechanism via the *Permission::check* method (see [api:LeftAndMain] for examples on how
SilverStripe provides a security mechanism via the *Permission::check* method (see [LeftAndMain](api:SilverStripe\Admin\LeftAndMain) for examples on how
the admin screens work).
(next step -- go from *Permission::checkMember*...)
@ -48,14 +48,14 @@ works.
### Loading the admin page: looking at security
If you go to [your site]/admin *Director.php* maps the 'admin' URL request through a [api:Director] rule to the
[api:CMSMain] controller (see [api:CMSMain], with no arguments).
If you go to [your site]/admin *Director.php* maps the 'admin' URL request through a [Director](api:SilverStripe\Control\Director) rule to the
[CMSMain](api:SilverStripe\CMS\Controllers\CMSMain) controller (see [CMSMain](api:SilverStripe\CMS\Controllers\CMSMain), with no arguments).
*CMSMain.init()* calls its parent which, of all things is called [api:LeftAndMain]. It's in [api:LeftAndMain] that the
*CMSMain.init()* calls its parent which, of all things is called [LeftAndMain](api:SilverStripe\Admin\LeftAndMain). It's in [LeftAndMain](api:SilverStripe\Admin\LeftAndMain) that the
important security checks are made by calling *Permission::check*.
[api:Security::permissionFailure()] is the next utility function you can use to redirect to the login form.
[Security::permissionFailure()](api:SilverStripe\Security\Security::permissionFailure()) is the next utility function you can use to redirect to the login form.
### Customizing Access Checks in CMS Classes
see [api:LeftAndMain]
see [LeftAndMain](api:SilverStripe\Admin\LeftAndMain)

7
docs/en/02_Developer_Guides/09_Security/02_Permissions.md
View File

@ -19,11 +19,12 @@ The simple usage, Permission::check("PERM_CODE") will detect if the currently lo
## PermissionProvider
[api:PermissionProvider] is an interface which lets you define a method *providePermissions()*.
[PermissionProvider](api:SilverStripe\Security\PermissionProvider) is an interface which lets you define a method *providePermissions()*.
This method should return a map of permission code names with a human readable explanation of its purpose.
```php
use SilverStripe\Security\PermissionProvider;
use SilverStripe\Security\Security;
class PageController implements PermissionProvider
{
@ -98,7 +99,7 @@ This works much like ADMIN permissions (see above)
You can check if a user has access to the CMS by simply performing a check against `CMS_ACCESS`.
```php
if (Permission::checkMember($member, 'CMS_ACCESS')) {
if (SilverStripe\Security\Permission::checkMember($member, 'CMS_ACCESS')) {
//user can access the CMS
}
```
@ -107,4 +108,4 @@ Internally, this checks that the user has any of the defined `CMS_ACCESS_*` perm
## API Documentation
[api:Permission]
[Permission](api:SilverStripe\Security\Permission)

18
docs/en/02_Developer_Guides/09_Security/03_Authentication.md
View File

@ -3,33 +3,33 @@ summary: Explains SilverStripe's Authentication options and custom authenticator
# Authentication
By default, SilverStripe provides a [api:MemberAuthenticator] class which hooks into its own internal
By default, SilverStripe provides a [MemberAuthenticator](api:SilverStripe\Security\MemberAuthenticator\MemberAuthenticator) class which hooks into its own internal
authentication system.
The main login system uses these controllers to handle the various security requests:
[api:Security] - Which is the controller which handles most front-end security requests, including logging in, logging out, resetting password, or changing password. This class also provides an interface to allow configured [api:Authenticator] classes to each display a custom login form.
[Security](api:SilverStripe\Security\Security) - Which is the controller which handles most front-end security requests, including logging in, logging out, resetting password, or changing password. This class also provides an interface to allow configured [Authenticator](api:SilverStripe\Security\Authenticator) classes to each display a custom login form.
[api:CMSSecurity] - Which is the controller which handles security requests within the CMS, and allows users to re-login without leaving the CMS.
[CMSSecurity](api:SilverStripe\Security\CMSSecurity) - Which is the controller which handles security requests within the CMS, and allows users to re-login without leaving the CMS.
## Member Authentication
The default member authentication system is implemented in the following classes:
[api:MemberAuthenticator] - Which is the default member authentication implementation. This uses the email and password stored internally for each member to authenticate them.
[MemberAuthenticator](api:SilverStripe\Security\MemberAuthenticator) - Which is the default member authentication implementation. This uses the email and password stored internally for each member to authenticate them.
[api:MemberLoginForm] - Is the default form used by `MemberAuthenticator`, and is displayed on the public site at the url `Security/login` by default.
[MemberLoginForm](api:SilverStripe\Security\MemberAuthenticator\MemberLoginForm) - Is the default form used by `MemberAuthenticator`, and is displayed on the public site at the url `Security/login` by default.
[api:CMSMemberLoginForm] - Is the secondary form used by `MemberAuthenticator`, and will be displayed to the user within the CMS any time their session expires or they are logged out via an action. This form is presented via a popup dialog, and can be used to re-authenticate that user automatically without them having to lose their workspace. E.g. if editing a form, the user can login and continue to publish their content.
[CMSMemberLoginForm](api:SilverStripe\Security\MemberAuthenticator\CMSMemberLoginForm) - Is the secondary form used by `MemberAuthenticator`, and will be displayed to the user within the CMS any time their session expires or they are logged out via an action. This form is presented via a popup dialog, and can be used to re-authenticate that user automatically without them having to lose their workspace. E.g. if editing a form, the user can login and continue to publish their content.
## Custom Authentication
Additional authentication methods (oauth, etc) can be implemented by creating custom implementations of each of the
following base classes:
[api:Authenticator] - The base class for authentication systems. This class also acts as the factory to generate various login forms for parts of the system. If an authenticator supports in-cms reauthentication then it will be necessary to override the `supports_cms` and `get_cms_login_form` methods.
[Authenticator](api:SilverStripe\Security\Authenticator) - The base class for authentication systems. This class also acts as the factory to generate various login forms for parts of the system. If an authenticator supports in-cms reauthentication then it will be necessary to override the `supports_cms` and `get_cms_login_form` methods.
[api:LoginForm] - which is the base class for a login form which links to a specific authenticator. At the very least, it will be necessary to implement a form class which provides a default login interface. If in-cms re-authentication is desired, then a specialised subclass of this method may be necessary. For example, this form could be extended to require confirmation of username as well as password.
[LoginForm](api:SilverStripe\Security\LoginForm) - which is the base class for a login form which links to a specific authenticator. At the very least, it will be necessary to implement a form class which provides a default login interface. If in-cms re-authentication is desired, then a specialised subclass of this method may be necessary. For example, this form could be extended to require confirmation of username as well as password.
## Default Admin
@ -43,6 +43,6 @@ It is advisable to configure this user in your `.env` file inside of the web roo
SS_DEFAULT_ADMIN_USERNAME="admin"
SS_DEFAULT_ADMIN_PASSWORD="password"
When a user logs in with these credentials, then a [api:Member] with the Email 'admin' will be generated in
When a user logs in with these credentials, then a [Member](api:SilverStripe\Security\Member) with the Email 'admin' will be generated in
the database, but without any password information. This means that the password can be reset or changed by simply
updating the `.env` file.

24
docs/en/02_Developer_Guides/09_Security/04_Secure_Coding.md
View File

@ -58,10 +58,10 @@ Parameterised updates and inserts are also supported, but the syntax is a little
SilverStripe internally will use parameterised queries in SQL statements wherever possible.
If necessary Silverstripe performs any required escaping through database-specific methods (see [api:Database::addslashes()]).
For [api:MySQLDatabase], this will be `[mysql_real_escape_string()](http://de3.php.net/mysql_real_escape_string)`.
If necessary Silverstripe performs any required escaping through database-specific methods (see [Database::addslashes()](api:SilverStripe\ORM\Connect\Database::addslashes())).
For [MySQLDatabase](api:SilverStripe\ORM\Connect\MySQLDatabase), this will be `[mysql_real_escape_string()](http://de3.php.net/mysql_real_escape_string)`.
* Most [api:DataList] accessors (see escaping note in method documentation)
* Most [DataList](api:SilverStripe\ORM\DataList) accessors (see escaping note in method documentation)
* DataObject::get_by_id()
* DataObject::update()
* DataObject::castedUpdate()
@ -213,8 +213,8 @@ We recommend configuring [shortcodes](/developer_guides/extending/shortcodes) th
### Escaping model properties
[api:SSViewer] (the SilverStripe template engine) automatically takes care of escaping HTML tags from specific
object-properties by [casting](/developer_guides/model/data_types_and_casting) its string value into a [api:DBField] object.
[SSViewer](api:SilverStripe\View\SSViewer) (the SilverStripe template engine) automatically takes care of escaping HTML tags from specific
object-properties by [casting](/developer_guides/model/data_types_and_casting) its string value into a [DBField](api:SilverStripe\ORM\FieldType\DBField) object.
PHP:
@ -297,7 +297,7 @@ presentation from business logic.
When using *customise()* or *renderWith()* calls in your controller, or otherwise forcing a custom context for your
template, you'll need to take care of casting and escaping yourself in PHP.
The [api:Convert] class has utilities for this, mainly *Convert::raw2xml()* and *Convert::raw2att()* (which is
The [Convert](api:SilverStripe\Core\Convert) class has utilities for this, mainly *Convert::raw2xml()* and *Convert::raw2att()* (which is
also used by *XML* and *ATT* in template code).
PHP:
@ -372,14 +372,14 @@ SilverStripe has built-in countermeasures against [CSRF](http://shiflett.org/art
will automatically contain a `SecurityID` parameter which is generated as a secure hash on the server, connected to the
currently active session of the user. If this form is submitted without this parameter, or if the parameter doesn't
match the hash stored in the users session, the request is discarded.
You can disable this behaviour through [api:Form::disableSecurityToken()].
You can disable this behaviour through [Form::disableSecurityToken()](api:SilverStripe\Forms\Form::disableSecurityToken()).
It is also recommended to limit form submissions to the intended HTTP verb (mostly `GET` or `POST`)
through [api:Form::setStrictFormMethodCheck()].
through [Form::setStrictFormMethodCheck()](api:SilverStripe\Forms\Form::setStrictFormMethodCheck()).
Sometimes you need to handle state-changing HTTP submissions which aren't handled through
SilverStripe's form system. In this case, you can also check the current HTTP request
for a valid token through [api:SecurityToken::checkRequest()].
for a valid token through [SecurityToken::checkRequest()](api:SilverStripe\Security\SecurityToken::checkRequest()).
## Casting user input
@ -481,15 +481,15 @@ list of allowed extensions by adding these to the `File.allowed_extensions` conf
## Passwords
SilverStripe stores passwords with a strong hashing algorithm (blowfish) by default
(see [api:PasswordEncryptor]). It adds randomness to these hashes via
(see [PasswordEncryptor](api:SilverStripe\Security\PasswordEncryptor)). It adds randomness to these hashes via
salt values generated with the strongest entropy generators available on the platform
(see [api:RandomGenerator]). This prevents brute force attacks with
(see [RandomGenerator](api:SilverStripe\Security\RandomGenerator)). This prevents brute force attacks with
[Rainbow tables](http://en.wikipedia.org/wiki/Rainbow_table).
Strong passwords are a crucial part of any system security.
So in addition to storing the password in a secure fashion,
you can also enforce specific password policies by configuring
a [api:PasswordValidator]:
a [PasswordValidator](api:SilverStripe\Security\PasswordValidator):
:::php
$validator = new PasswordValidator();

6
docs/en/02_Developer_Guides/10_Email/index.md
View File

@ -2,7 +2,7 @@ summary: Send HTML and plain text email from your SilverStripe application.
# Email
Creating and sending email in SilverStripe is done through the [api:Email] and [api:Mailer] classes. This document
Creating and sending email in SilverStripe is done through the [Email](api:SilverStripe\Control\Email\Email) and [Mailer](api:SilverStripe\Control\Email\Mailer) classes. This document
covers how to create an `Email` instance, customise it with a HTML template, then send it through a custom `Mailer`.
## Configuration
@ -86,7 +86,7 @@ to specify your own own plaintext version/template you can use `$email->setPlain
the plain email:
```php
$email = new Email();
$email = new SilverStripe\Control\Email\Email();
$email->setPlainTemplate('MyPlanTemplate');
$this->send();
```
@ -160,4 +160,4 @@ For further information on SwiftMailer, consult their docs: http://swiftmailer.o
## API Documentation
* [api:Email]
* [Email](api:SilverStripe\Control\Email\Email)

14
docs/en/02_Developer_Guides/11_Integration/00_CSV_Import.md
View File

@ -9,7 +9,7 @@ be customised to fit your data.
## The CsvBulkLoader class
The [api:CsvBulkLoader] class facilitate complex CSV-imports by defining column-mappings and custom converters.
The [CsvBulkLoader](api:SilverStripe\Dev\CsvBulkLoader) class facilitate complex CSV-imports by defining column-mappings and custom converters.
It uses PHP's built-in `fgetcsv()` function to process CSV input, and accepts a file handle as an input.
Feature overview:
@ -26,7 +26,7 @@ Feature overview:
You can use the CsvBulkLoader without subclassing or other customizations, if the column names
in your CSV file match `$db` properties in your dataobject. E.g. a simple import for the
[api:Member] class could have this data in a file:
[Member](api:SilverStripe\Security\Member) class could have this data in a file:
FirstName,LastName,Email
Donald,Duck,donald@disney.com
@ -38,12 +38,12 @@ The loader would be triggered through the `load()` method:
$loader = new CsvBulkLoader('Member');
$result = $loader->load('<my-file-path>');
By the way, you can import [api:Member] and [api:Group] data through `http://localhost/admin/security`
By the way, you can import [Member](api:SilverStripe\Security\Member) and [Group](api:SilverStripe\Security\Group) data through `http://localhost/admin/security`
interface out of the box.
## Import through ModelAdmin
The simplest way to use [api:CsvBulkLoader] is through a [api:ModelAdmin] interface - you get an upload form out of the box.
The simplest way to use [CsvBulkLoader](api:SilverStripe\Dev\CsvBulkLoader) is through a [ModelAdmin](api:SilverStripe\Admin\ModelAdmin) interface - you get an upload form out of the box.
:::php
<?php
@ -109,7 +109,7 @@ You'll need to add a route to your controller to make it accessible via URL
}
}
Note: This interface is not secured, consider using [api:Permission::check()] to limit the controller to users
Note: This interface is not secured, consider using [Permission::check()](api:SilverStripe\Security\Permission::check()) to limit the controller to users
with certain access rights.
## Column mapping and relation import
@ -213,5 +213,5 @@ Building off of the ModelAdmin example up top, use a custom loader instead of th
## Related
* [api:CsvParser]
* [api:ModelAdmin]
* [CsvParser](api:SilverStripe\Dev\CsvParser)
* [ModelAdmin](api:SilverStripe\Admin\ModelAdmin)

8
docs/en/02_Developer_Guides/11_Integration/01_RestfulService.md
View File

@ -2,7 +2,7 @@ summary: Consume external data through their RESTFul interfaces.
# Restful Service
[api:RestfulService] is used to enable connections to remote web services through PHP's `curl` command. It provides an
[RestfulService](api:RestfulService) is used to enable connections to remote web services through PHP's `curl` command. It provides an
interface and utility functions for generating a valid request and parsing the response returned from the web service.
<div class="alert" markdown="1">
@ -134,7 +134,7 @@ To get the value of entry node with the namespace media, use:
### Handling Errors
If the web service returned an error (for example, API key not available or inadequate parameters),
[api:RestfulService] can delegate the error handling to it's descendant class. To handle the errors, subclass
[RestfulService](api:RestfulService) can delegate the error handling to it's descendant class. To handle the errors, subclass
`RestfulService and define a function called errorCatch.
:::php
@ -187,7 +187,7 @@ To set global cURL settings you can update the `RestfulService` config via the C
Here is an example to increase the HTTP Timeout globally. Insert this in your `_config.php` file:
```php
Config::inst()->update('RestfulService', 'default_curl_options', array(
SilverStripe\Core\Config\Config::inst()->update('RestfulService', 'default_curl_options', array(
CURLOPT_DNS_CACHE_TIMEOUT => 3600,
CURLOPT_CONNECTTIMEOUT => 10,
));
@ -220,4 +220,4 @@ $service->request('service.json', 'GET', null, null, $curlOptions);
## API Documentation
* [api:RestfulService]
* [RestfulService](api:RestfulService)

16
docs/en/02_Developer_Guides/11_Integration/02_RSSFeed.md
View File

@ -3,15 +3,15 @@ summary: Output records from your database as an RSS Feed.
# RSS Feed
Generating RSS / Atom-feeds is a matter of rendering a [api:SS_List] instance through the [api:RSSFeed] class.
Generating RSS / Atom-feeds is a matter of rendering a [SS_List](api:SilverStripe\ORM\SS_List) instance through the [RSSFeed](api:SilverStripe\Control\RSS\RSSFeed) class.
The [api:RSSFeed] class doesn't limit you to generating article based feeds, it is just as easy to create a feed of
your current staff members, comments or any other custom [api:DataObject] subclasses you have defined. The only
The [RSSFeed](api:SilverStripe\Control\RSS\RSSFeed) class doesn't limit you to generating article based feeds, it is just as easy to create a feed of
your current staff members, comments or any other custom [DataObject](api:SilverStripe\ORM\DataObject) subclasses you have defined. The only
logical limitation here is that every item in the RSS-feed should be accessible through a URL on your website, so it's
advisable to just create feeds from subclasses of [api:SiteTree].
advisable to just create feeds from subclasses of [SiteTree](api:SilverStripe\CMS\Model\SiteTree).
<div class="warning" markdown="1">
If you wish to generate an RSS feed that contains a [api:DataObject], ensure you define a `AbsoluteLink` method on
If you wish to generate an RSS feed that contains a [DataObject](api:SilverStripe\ORM\DataObject), ensure you define a `AbsoluteLink` method on
the object.
</div>
@ -47,7 +47,7 @@ will normally go in your `Controllers` `init` method.
### Showing the 10 most recently updated pages
You can use [api:RSSFeed] to easily create a feed showing your latest Page updates. The following example adds a page
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**
@ -87,7 +87,7 @@ You can use [api:RSSFeed] to easily create a feed showing your latest Page updat
### Rendering DataObjects in a RSSFeed
DataObjects can be rendered in the feed as well, however, since they aren't explicitly [api:SiteTree] subclasses we
DataObjects can be rendered in the feed as well, however, since they aren't explicitly [SiteTree](api:SilverStripe\CMS\Model\SiteTree) subclasses we
need to include a function `AbsoluteLink` to allow the RSS feed to link through to the item.
<div class="info">
@ -193,4 +193,4 @@ As we've added a new template (PlayersRss.ss) make sure you clear your SilverStr
## API Documentation
* [api:RSSFeed]
* [RSSFeed](api:SilverStripe\Control\RSS\RSSFeed)

2
docs/en/02_Developer_Guides/11_Integration/How_Tos/Import_CSV_through_a_Controller.md
View File

@ -64,6 +64,6 @@ form (which is used for `MyDataObject` instances). You can access it through
}
<div class="alert" markdown="1">
This interface is not secured, consider using [api:Permission::check()] to limit the controller to users with certain
This interface is not secured, consider using [Permission::check()](api:SilverStripe\Security\Permission::check()) to limit the controller to users with certain
access rights.
</div>

4
docs/en/02_Developer_Guides/11_Integration/How_Tos/custom_csvbulkloader.md
View File

@ -99,5 +99,5 @@ Our final import looks like this.
## Related
* [api:CsvParser]
* [api:ModelAdmin]
* [CsvParser](api:SilverStripe\Dev\CsvParser)
* [ModelAdmin](api:SilverStripe\Admin\ModelAdmin)

6
docs/en/02_Developer_Guides/11_Integration/How_Tos/embed_rss.md
View File

@ -2,7 +2,7 @@ title: Embed an RSS Feed
# Embed an RSS Feed
[api:RestfulService] can be used to easily embed an RSS feed from a site. In this How to we'll embed the latest
[RestfulService](api:RestfulService) can be used to easily embed an RSS feed from a site. In this How to we'll embed the latest
weather information from the Yahoo Weather API.
First, we write the code to query the API feed.
@ -39,7 +39,7 @@ First, we write the code to query the API feed.
return $output;
}
This will provide our `Page` template with a new `WellingtonWeather` variable (an [api:ArrayList]). Each item has a
This will provide our `Page` template with a new `WellingtonWeather` variable (an [ArrayList](api:SilverStripe\ORM\ArrayList)). Each item has a
single field `Description`.
**mysite/templates/Page.ss**
@ -54,4 +54,4 @@ single field `Description`.
## Related
* [RestfulService Documentation](../restfulservice)
* [api:RestfulService]
* [RestfulService](api:RestfulService)

16
docs/en/02_Developer_Guides/12_Search/01_Searchcontext.md
View File

@ -3,15 +3,15 @@ summary: Configure the search form within ModelAdmin using the SearchContext cla
# SearchContext
[api:SearchContext] manages searching of properties on one or more [api:DataObject] types, based on a given set of
input parameters. [api:SearchContext] is intentionally decoupled from any controller-logic, it just receives a set of
[SearchContext](api:SilverStripe\ORM\Search\SearchContext) manages searching of properties on one or more [DataObject](api:SilverStripe\ORM\DataObject) types, based on a given set of
input parameters. [SearchContext](api:SilverStripe\ORM\Search\SearchContext) is intentionally decoupled from any controller-logic, it just receives a set of
search parameters and an object class it acts on.
The default output of a [api:SearchContext] is either a [api:SQLSelect] object for further refinement, or a
[api:DataObject] instance.
The default output of a [SearchContext](api:SilverStripe\ORM\Search\SearchContext) is either a [SQLSelect](api:SilverStripe\ORM\Queries\SQLSelect) object for further refinement, or a
[DataObject](api:SilverStripe\ORM\DataObject) instance.
<div class="notice" markdown="1">
[api:SearchContext] is mainly used by [ModelAdmin](/developer_guides/customising_the_admin_interface/modeladmin).
[SearchContext](api:SilverStripe\ORM\Search\SearchContext) is mainly used by [ModelAdmin](/developer_guides/customising_the_admin_interface/modeladmin).
</div>
## Usage
@ -204,7 +204,7 @@ Results.PaginationSummary(4) defines how many pages the search will show in the
## Available SearchFilters
See [api:SearchFilter] API Documentation
See [SearchFilter](api:SilverStripe\ORM\Filters\SearchFilter) API Documentation
## Related Documentation
@ -214,6 +214,6 @@ See [api:SearchFilter] API Documentation
## API Documentation
* [api:SearchContext]
* [api:DataObject]
* [SearchContext](api:SilverStripe\ORM\Search\SearchContext)
* [DataObject](api:SilverStripe\ORM\DataObject)

14
docs/en/02_Developer_Guides/12_Search/02_FulltextSearch.md
View File

@ -4,7 +4,7 @@ summary: Fulltext search allows sophisticated searching on text content.
# FulltextSearchable
Fulltext search allows advanced search criteria for searching words within a text based data column. While basic
Fulltext search can be achieved using the built-in [api:MySQLDatabase] class a more powerful wrapper for Fulltext
Fulltext search can be achieved using the built-in [MySQLDatabase](api:SilverStripe\ORM\Connect\MySQLDatabase) class a more powerful wrapper for Fulltext
search is provided through a module.
<div class="notice" markdown="1">
@ -15,7 +15,7 @@ a high level wrapper for running advanced search services such as Solr, Lucene o
## Adding Fulltext Support to MySQLDatabase
The [api:MySQLDatabase] class defaults to creating tables using the InnoDB storage engine. As Fulltext search in MySQL
The [MySQLDatabase](api:SilverStripe\ORM\Connect\MySQLDatabase) class defaults to creating tables using the InnoDB storage engine. As Fulltext search in MySQL
requires the MyISAM storage engine, any DataObject you wish to use with Fulltext search must be changed to use MyISAM
storage engine.
@ -31,18 +31,18 @@ You can do so by adding this static variable to your class definition:
);
}
The [api:FulltextSearchable] extension will add the correct `Fulltext` indexes to the data model.
The [FulltextSearchable](api:SilverStripe\ORM\Search\FulltextSearchable) extension will add the correct `Fulltext` indexes to the data model.
<div class="alert" markdown="1">
The [api:SearchForm] and [api:FulltextSearchable] API's are currently hard coded to be specific to `Page` and `File`
The [SearchForm](api:SilverStripe\CMS\Search\SearchForm) and [FulltextSearchable](api:SilverStripe\ORM\Search\FulltextSearchable) API's are currently hard coded to be specific to `Page` and `File`
records and cannot easily be adapted to include custom `DataObject` instances. To include your custom objects in the
default site search, have a look at those extensions and modify as required.
</div>
### Fulltext Filter
SilverStripe provides a [api:FulltextFilter] which you can use to perform custom fulltext searches on
[api:DataList]s.
SilverStripe provides a [FulltextFilter](api:SilverStripe\ORM\Filters\FulltextFilter) which you can use to perform custom fulltext searches on
[DataList](api:SilverStripe\ORM\DataList)s.
Example DataObject:
@ -77,4 +77,4 @@ field instead of the index.
## API Documentation
* [api:FulltextSearchable]
* [FulltextSearchable](api:SilverStripe\ORM\Search\FulltextSearchable)

6
docs/en/02_Developer_Guides/13_i18n/index.md
View File

@ -24,7 +24,7 @@ The i18n class is enabled by default.
### Setting the locale
To set the locale you just need to call [api:i18n::set_locale()] passing, as a parameter, the name of the locale that
To set the locale you just need to call [i18n::set_locale()](api:SilverStripe\i18n\i18n::set_locale()) passing, as a parameter, the name of the locale that
you want to set.
:::php
@ -45,7 +45,7 @@ operations such as decimal separators in database queries.
### Getting the locale
As you set the locale you can also get the current value, just by calling [api:i18n::get_locale()].
As you set the locale you can also get the current value, just by calling [i18n::get_locale()](api:SilverStripe\i18n\i18n::get_locale()).
### Declaring the content language in HTML {#declaring_the_content_language_in_html}
@ -132,7 +132,7 @@ Please refer to [W3C: Introduction to IDN and IRI](http://www.w3.org/Internation
### i18n in Form Fields
Date and time related form fields are automatically localised ([api:DateField], [api:TimeField], [api:DatetimeField]).
Date and time related form fields are automatically localised ([DateField](api:SilverStripe\Forms\DateField), [TimeField](api:SilverStripe\Forms\TimeField), [DatetimeField](api:SilverStripe\Forms\DatetimeField)).
Since they use HTML5 `type=date` and `type=time` fields by default, these fields will present dates
in a localised format chosen by the browser and operating system.

8
docs/en/02_Developer_Guides/14_Files/01_File_Management.md
View File

@ -8,7 +8,7 @@ Asset storage is provided out of the box via a [Flysystem](http://flysystem.thep
However, any class that implements the `AssetStore` interface could be substituted to provide storage backends
via other mechanisms.
Internally, files are stored as `[api:DBFile]` records on the rows of parent objects. These records are composite fields
Internally, files are stored as `[DBFile](api:SilverStripe\Assets\Storage\DBFile)` records on the rows of parent objects. These records are composite fields
which contain sufficient information useful to the configured asset backend in order to store, manage, and
publish files. By default this composite field behind this field stores the following details:
@ -98,7 +98,7 @@ The default asset store supports each of these.
## Getting content from a `DBFile`
When placed into a template (e.g. `$MyFileField`) then `[api:DBFile]` will automatically generate the appropriate
When placed into a template (e.g. `$MyFileField`) then `[DBFile](api:SilverStripe\Assets\Storage\DBFile)` will automatically generate the appropriate
template for the file mime type. For images, this will embed an image tag. For documents a download link will be presented.
As with storage, there are also different ways of loading the content (or properties) of the file:
@ -127,7 +127,7 @@ Each record has the following database fields:
| `ClassName` | The class name of the file (e.g. File, Image or Folder). |
| `Name` | The 'basename' of the file, or the folder name. For example 'my-image.jpg', or 'images' for a folder. |
| `Title` | The optional, human-readable title of the file for display only (doesn't apply to folders). |
| `File` | The `[api:DBFile]` field (see above) which stores the underlying asset content. |
| `File` | The `[DBFile](api:SilverStripe\Assets\Storage\DBFile)` field (see above) which stores the underlying asset content. |
| `ShowInSearch` | Whether the file should be shown in search results, defaults to '1'. See ["Tutorial 4 - Site Search"](/tutorials/site_search) for enabling search. |
| `ParentID` | The ID of the parent Folder that this File/Folder is in. A ParentID of '0' indicates that this is a top level record. |
| `OwnerID` | The ID of the Member that 'owns' the File/Folder (not related to filesystem permissions). |
@ -155,6 +155,6 @@ You may also notice the 'Sync files' button (highlighted below). This button all
Files can be managed through forms in one way:
* [api:FileField]: provides a simple HTML input with a type of "file".
* [FileField](api:SilverStripe\Forms\FileField): provides a simple HTML input with a type of "file".
_NOTE_: Modules are also available to handle Files.

22
docs/en/02_Developer_Guides/14_Files/02_Images.md
View File

@ -2,22 +2,22 @@ summary: Learn how to crop and resize images in templates and PHP code
# Image
Image files can be stored either through the `[api:Image]` dataobject, or though [api:DBFile] fields.
Image files can be stored either through the `[Image](api:SilverStripe\Assets\Image)` dataobject, or though [DBFile](api:SilverStripe\Assets\Storage\DBFile) fields.
In either case, the same image resizing and manipulation functionality is available though the common
[api:ImageManipulation] trait.
[ImageManipulation](api:SilverStripe\Assets\ImageManipulation) trait.
## Usage
### Managing images through form fields
Images can be uploaded like any other file, through [api:FileField].
Images can be uploaded like any other file, through [FileField](api:SilverStripe\Forms\FileField).
Allows upload of images through limiting file extensions with `setAllowedExtensions()`.
### Inserting images into the WYSIWYG editor
Images can be inserted into `[api:HTMLValue]` database fields
Images can be inserted into `[HTMLValue](api:SilverStripe\View\Parsers\HTMLValue)` database fields
through the built-in WYSIWYG editor. In order to retain a relationship
to the underlying `[api:Image]` records, images are saved as [shortcodes](/developer-guides/extending/shortcodes).
to the underlying `[Image](api:SilverStripe\Assets\Image)` records, images are saved as [shortcodes](/developer-guides/extending/shortcodes).
The shortcode (`[image id="<id>" alt="My text" ...]`) will be converted
into an `<img>` tag on your website automatically.
@ -91,7 +91,7 @@ The image manipulation functions can be used in your code with the same names, e
Some of the MetaData functions need to be prefixed with 'get', example `getHeight()`, `getOrientation()` etc.
Please refer to the [api:ImageManipulation] API documentation for specific functions.
Please refer to the [ImageManipulation](api:SilverStripe\Assets\ImageManipulation) API documentation for specific functions.
### Creating custom image functions
@ -137,7 +137,7 @@ You can also create your own functions by decorating the `Image` class.
### Form Upload
For usage on a website form, see [api:FileField].
For usage on a website form, see [FileField](api:SilverStripe\Assets\FileField).
### Image Quality
@ -197,7 +197,7 @@ SilverStripe\Core\Injector\Injector:
## API Documentation
* [api:File]
* [api:Image]
* [api:DBFile]
* [api:ImageManipulation]
* [File](api:SilverStripe\Assets\File)
* [Image](api:SilverStripe\Assets\Image)
* [DBFile](api:SilverStripe\Assets\Storage\DBFile)
* [ImageManipulation](api:SilverStripe\Assets\ImageManipulation)

2
docs/en/02_Developer_Guides/14_Files/03_File_Security.md
View File

@ -173,7 +173,7 @@ The urls for these two files, however, do not reflect the physical structure dir
* `http://www.mysite.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,
which will be passed to the `[api:ProtectedFileController]` controller, which will serve
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.
When the file `NewCompanyLogo.gif` is made public, the url will not change, but the file location

8
docs/en/02_Developer_Guides/14_Files/index.md
View File

@ -6,7 +6,7 @@ introduction: Upload, manage and manipulate files and images.
## API Documentation
* [api:File]
* [api:Image]
* [api:DBFile]
* [api:Folder]
* [File](api:SilverStripe\Assets\File)
* [Image](api:SilverStripe\Assets\Image)
* [DBFile](api:SilverStripe\Assets\Storage\DBFile)
* [Folder](api:SilverStripe\Assets\Folder)

40
docs/en/02_Developer_Guides/15_Customising_the_Admin_Interface/01_ModelAdmin.md
View File

@ -3,14 +3,14 @@ summary: Create admin UI's for managing your data records.
# ModelAdmin
[api:ModelAdmin] provides a simple way to utilize the SilverStripe Admin UI with your own data models. It can create
searchables list and edit views of [api:DataObject] subclasses, and even provides import and export of your data.
[ModelAdmin](api:SilverStripe\Admin\ModelAdmin) provides a simple way to utilize the SilverStripe Admin UI with your own data models. It can create
searchables list and edit views of [DataObject](api:SilverStripe\ORM\DataObject) subclasses, and even provides import and export of your data.
It uses the framework's knowledge about the model to provide sensible defaults, allowing you to get started in a couple
of lines of code, while still providing a solid base for customization.
<div class="info" markdown="1">
The interface is mainly powered by the [api:GridField] class ([documentation](../forms/field_types/gridfield)), which can
The interface is mainly powered by the [GridField](api:SilverStripe\Forms\GridField\GridField) class ([documentation](../forms/field_types/gridfield)), which can
also be used in other areas of your application.
</div>
@ -90,7 +90,7 @@ Each new `ModelAdmin` subclass creates its' own [permission code](../security),
For more information on the security and permission system see the [Security Documentation](../security)
</div>
The [api:DataObject] API has more granular permission control, which is enforced in [api:ModelAdmin] by default.
The [DataObject](api:SilverStripe\ORM\DataObject) API has more granular permission control, which is enforced in [ModelAdmin](api:SilverStripe\Admin\ModelAdmin) by default.
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.
@ -119,12 +119,12 @@ permissions by default. For most cases, less restrictive checks make sense, e.g.
## Searching Records
[api:ModelAdmin] uses the [SearchContext](../search/searchcontext) class to provide a search form, as well as get the
searched results. Every [api:DataObject] can have its own context, based on the fields which should be searchable. The
[ModelAdmin](api:SilverStripe\Admin\ModelAdmin) uses the [SearchContext](../search/searchcontext) class to provide a search form, as well as get the
searched results. Every [DataObject](api:SilverStripe\ORM\DataObject) can have its own context, based on the fields which should be searchable. The
class makes a guess at how those fields should be searched, e.g. showing a checkbox for any boolean fields in your
`$db` definition.
To remove, add or modify searchable fields, define a new [api:DataObject::$searchable_fields] static on your model
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**
@ -147,8 +147,8 @@ class (see [SearchContext](../search/searchcontext) docs for details).
## Displaying Results
The results are shown in a tabular listing, powered by the [GridField](../forms/field_types/gridfield), more specifically
the [api:GridFieldDataColumns] component. This component looks for a [api:DataObject::$summary_fields] static on your
model class, where you can add or remove columns. To change the title, use [api:DataObject::$field_labels].
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**
@ -167,8 +167,8 @@ model class, where you can add or remove columns. To change the title, use [api:
);
}
The results list are retrieved from [api:SearchContext::getResults()], based on the parameters passed through the search
form. If no search parameters are given, the results will show every record. Results are a [api:DataList] instance, so
The results list are retrieved from [SearchContext::getResults()](api:SilverStripe\ORM\Search\SearchContext::getResults()), based on the parameters passed through the search
form. If no search parameters are given, the results will show every record. Results are a [DataList](api:SilverStripe\ORM\DataList) instance, so
can be customized by additional SQL filters, joins.
For example, we might want to exclude all products without prices in our sample `MyAdmin` implementation.
@ -225,7 +225,7 @@ checkbox which limits search results to expensive products (over $100).
}
}
To alter how the results are displayed (via [api:GridField]), you can also overload the `getEditForm()` method. For
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**
@ -288,17 +288,17 @@ to only one specific `GridField`:
## Data Import
The `ModelAdmin` class provides import of CSV files through the [api:CsvBulkLoader] API. which has support for column
The `ModelAdmin` class provides import of CSV files through the [CsvBulkLoader](api:SilverStripe\Dev\CsvBulkLoader) API. which has support for column
mapping, updating existing records, and identifying relationships - so its a powerful tool to get your data into a
SilverStripe database.
By default, each model management interface allows uploading a CSV file with all columns auto detected. To override
with a more specific importer implementation, use the [api:ModelAdmin::$model_importers] static.
with a more specific importer implementation, use the [ModelAdmin::$model_importers](api:SilverStripe\Admin\ModelAdmin::$model_importers) static.
## Data Export
Export is available as a CSV format through a button at the end of a results list. You can also export search results.
This is handled through the [api:GridFieldExportButton] component.
This is handled through the [GridFieldExportButton](api:SilverStripe\Forms\GridField\GridFieldExportButton) component.
To customize the exported columns, create a new method called `getExportFields` in your `ModelAdmin`:
@ -326,8 +326,8 @@ To customize the exported columns, create a new method called `getExportFields`
## API Documentation
* [api:ModelAdmin]
* [api:LeftAndMain]
* [api:GridField]
* [api:DataList]
* [api:CsvBulkLoader]
* [ModelAdmin](api:SilverStripe\Admin\ModelAdmin)
* [LeftAndMain](api:SilverStripe\Admin\LeftAndMain)
* [GridField](api:SilverStripe\Forms\GridField\GridField)
* [DataList](api:SilverStripe\ORM\DataList)
* [CsvBulkLoader](api:SilverStripe\Dev\CsvBulkLoader)

52
docs/en/02_Developer_Guides/15_Customising_the_Admin_Interface/02_CMS_Architecture.md
View File

@ -3,8 +3,8 @@
## Introduction
A lot can be achieved in SilverStripe by adding properties and form fields
to your own page types (via [api:SiteTree::getCMSFields()]), as well as creating
your own data management interfaces through [api:ModelAdmin]. But sometimes
to your own page types (via [SiteTree::getCMSFields()](api:SilverStripe\CMS\Model\SiteTree::getCMSFields())), as well as creating
your own data management interfaces through [ModelAdmin](api:SilverStripe\Admin\ModelAdmin). But sometimes
you'll want to go deeper and tailor the underlying interface to your needs as well.
For example, to build a personalized CMS dashboard, or content "slots" where authors
can drag their content into. At its core, SilverStripe is a web application
@ -52,7 +52,7 @@ coding conventions.
## The Admin URL
The CMS interface can be accessed by default through the `admin/` URL. You can change this by setting your own [Director routing rule](director#routing-rules) to the `[api:AdminRootController]` and clear the old rule like in the example below.
The CMS interface can be accessed by default through the `admin/` URL. You can change this by setting your own [Director routing rule](director#routing-rules) to the `[AdminRootController](api:SilverStripe\Admin\AdminRootController)` and clear the old rule like in the example below.
:::yml
---
@ -85,18 +85,18 @@ And in JavaScript, this is avaible through the `ss` namespace
### Multiple Admin URL and overrides
You can also create your own classes that extend the `[api:AdminRootController]` to create multiple or custom admin areas, with a `Director.rules` for each one.
You can also create your own classes that extend the `[AdminRootController](api:SilverStripe\Admin\AdminRootController)` to create multiple or custom admin areas, with a `Director.rules` for each one.
## Templates and Controllers
The CMS backend is handled through the [api:LeftAndMain] controller class,
The CMS backend is handled through the [LeftAndMain](api:SilverStripe\Admin\LeftAndMain) controller class,
which contains base functionality like displaying and saving a record.
This is extended through various subclasses, e.g. to add a group hierarchy ([api:SecurityAdmin]),
a search interface ([api:ModelAdmin]) or an "Add Page" form ([api:CMSPageAddController]).
This is extended through various subclasses, e.g. to add a group hierarchy ([SecurityAdmin](api:SilverStripe\Admin\SecurityAdmin)),
a search interface ([ModelAdmin](api:SilverStripe\Admin\ModelAdmin)) or an "Add Page" form ([CMSPageAddController](api:SilverStripe\CMS\Controllers\CMSPageAddController)).
The controller structure is too complex to document here, a good starting point
for following the execution path in code are [api:LeftAndMain::getRecord()] and [api:LeftAndMain::getEditForm()].
If you have the `cms` module installed, have a look at [api:CMSMain::getEditForm()] for a good
for following the execution path in code are [LeftAndMain::getRecord()](api:SilverStripe\Admin\LeftAndMain::getRecord()) and [LeftAndMain::getEditForm()](api:SilverStripe\Admin\LeftAndMain::getEditForm()).
If you have the `cms` module installed, have a look at [CMSMain::getEditForm()](api:SilverStripe\CMS\Controllers\CMSMain::getEditForm()) for a good
example on how to extend the base functionality (e.g. by adding page versioning hints to the form).
CMS templates are inherited based on their controllers, similar to subclasses of
@ -110,13 +110,13 @@ which is in charge of rendering the main content area apart from the CMS menu.
Depending on the complexity of your layout, you'll also need to overload the
"EditForm" template (e.g. `MyCMSController_EditForm.ss`), e.g. to implement
a tabbed form which only scrolls the main tab areas, while keeping the buttons at the bottom of the frame.
This requires manual assignment of the template to your form instance, see [api:CMSMain::getEditForm()] for details.
This requires manual assignment of the template to your form instance, see [CMSMain::getEditForm()](api:SilverStripe\CMS\Controllers\CMSMain::getEditForm()) for details.
Often its useful to have a "tools" panel in between the menu and your content,
usually occupied by a search form or navigational helper.
In this case, you can either overload the full base template as described above.
To avoid duplicating all this template code, you can also use the special [api:LeftAndMain::Tools()] and
[api:LeftAndMain::EditFormTools()] methods available in `LeftAndMain`.
To avoid duplicating all this template code, you can also use the special [LeftAndMain::Tools()](api:SilverStripe\Admin\LeftAndMain::Tools()) and
[LeftAndMain::EditFormTools()](api:SilverStripe\Admin\LeftAndMain::EditFormTools()) methods available in `LeftAndMain`.
These placeholders are populated by auto-detected templates,
with the naming convention of "<controller classname>_Tools.ss" and "<controller classname>_EditFormTools.ss".
So to add or "subclass" a tools panel, simply create this file and it's automatically picked up.
@ -132,7 +132,7 @@ Refer to [Layout reference](/developer_guides/customising_the_admin_interface/cm
## Forms
SilverStripe constructs forms and its fields within PHP,
mainly through the [getCMSFields()](api:DataObject::getCMSFields()) method.
mainly through the [getCMSFields()](api:SilverStripe\ORM\DataObject::getCMSFields()) method.
This in turn means that the CMS loads these forms as HTML via Ajax calls,
e.g. after saving a record (which requires a form refresh), or switching the section in the CMS.
@ -208,10 +208,10 @@ any particular element.
## JavaScript and CSS dependencies via Requirements and Ajax
The JavaScript logic powering the CMS is divided into many files,
which typically are included via the [api:Requirements] class, by adding
them to [api:LeftAndMain::init()] and its subclassed methods.
which typically are included via the [Requirements](api:SilverStripe\View\Requirements) class, by adding
them to [LeftAndMain::init()](api:SilverStripe\Admin\LeftAndMain::init()) and its subclassed methods.
This class also takes care of minification and combination of the files,
which is crucial for the CMS performance (see [api:Requirements::combine_files()]).
which is crucial for the CMS performance (see [Requirements::combine_files()](api:SilverStripe\View\Requirements::combine_files())).
Due to the procedural and selector-driven style of UI programming in jQuery.entwine,
it can be difficult to find the piece of code responsible for a certain behaviour.
@ -231,7 +231,7 @@ and [jQuery.delegate](http://api.jquery.com/delegate/), so takes care of dynamic
Most interfaces will require their own JavaScript and CSS files, so the Ajax loading has
to ensure they're loaded unless already present. A custom-built library called
`jQuery.ondemand` (located in `framework/thirdparty`) takes care of this transparently -
so as a developer just declare your dependencies through the [api:Requirements] API.
so as a developer just declare your dependencies through the [Requirements](api:SilverStripe\View\Requirements) API.
## Client-side routing
@ -335,10 +335,10 @@ we often want to update these sections independently from their neighbouring con
In order for this to work, the CMS templates declare certain sections as "PJAX fragments"
through a `data-pjax-fragment` attribute. These names correlate to specific
rendering logic in the PHP controllers, through the [api:PjaxResponseNegotiator] class.
rendering logic in the PHP controllers, through the [PjaxResponseNegotiator](api:SilverStripe\Control\PjaxResponseNegotiator) class.
Through a custom `X-Pjax` HTTP header, the client can declare which view they're expecting,
through identifiers like `CurrentForm` or `Content` (see [api:LeftAndMain::getResponseNegotiator()]).
through identifiers like `CurrentForm` or `Content` (see [LeftAndMain::getResponseNegotiator()](api:SilverStripe\Admin\LeftAndMain::getResponseNegotiator())).
These identifiers are passed to `loadPanel()` via the `pjax` data option.
The HTTP response is a JSON object literal, with template replacements keyed by their Pjax fragment.
Through PHP callbacks, we ensure that only the required template parts are actually executed and rendered.
@ -516,11 +516,11 @@ when using an input of type button, submit or reset, support is limited to plain
## Menu
The navigation menu in the CMS is created through the [api:CMSMenu] API,
The navigation menu in the CMS is created through the [CMSMenu](api:SilverStripe\Admin\CMSMenu) API,
which auto-detects all subclasses of `LeftAndMain`. This means that your custom
`ModelAdmin` subclasses will already appear in there without any explicit definition.
To modify existing menu entries or create new ones, see [api:CMSMenu::add_menu_item()]
and [api:CMSMenu::remove_menu_item()].
To modify existing menu entries or create new ones, see [CMSMenu::add_menu_item()](api:SilverStripe\Admin\CMSMenu::add_menu_item())
and [CMSMenu::remove_menu_item()](api:SilverStripe\Admin\CMSMenu::remove_menu_item()).
New content panels are typically loaded via Ajax, which might change
the current menu context. For example, a link to edit a file might be clicked
@ -536,7 +536,7 @@ which is picked up by the menu:
return 'my response';
}
This is usually handled by the existing [api:LeftAndMain] logic,
This is usually handled by the existing [LeftAndMain](api:SilverStripe\Admin\LeftAndMain) logic,
so you don't need to worry about it. The same concept applies for
'X-Title' (change the window title) and 'X-ControllerURL' (change the URL recorded in browser history).
Note: You can see any additional HTTP headers through the web developer tools in your browser of choice.
@ -551,13 +551,13 @@ For more information, see the [Howto: Customise the CMS tree](/developer_guides/
Note that a similar tree logic is also used for the
form fields to select one or more entries from those hierarchies
([api:TreeDropdownField] and [api:TreeMultiselectField]).
([TreeDropdownField](api:SilverStripe\Forms\TreeDropdownField) and [TreeMultiselectField](api:SilverStripe\Forms\TreeMultiselectField)).
## Tabs
We're using [jQuery UI tabs](http://jqueryui.com/), but in a customised fashion.
HTML with tabs can be created either directly through HTML templates in the CMS,
or indirectly through a [api:TabSet] form field. Since tabsets are useable
or indirectly through a [TabSet](api:SilverStripe\Forms\TabSet) form field. Since tabsets are useable
outside of the CMS as well, the baseline application of tabs happens via
a small wrapper around `jQuery.tabs()` stored in `TabSet.js`.
@ -654,6 +654,6 @@ through the `PjaxResponseNegotiator` class (see above).
* [Howto: Extend the CMS Interface](/developer_guides/customising_the_admin_interface/how_tos/extend_cms_interface)
* [Howto: Customise the CMS tree](/developer_guides/customising_the_admin_interface/how_tos/customise_cms_tree)
* [ModelAdmin API](api:ModelAdmin)
* [ModelAdmin API](api:SilverStripe\Admin\ModelAdmin)
* [Reference: Layout](/developer_guides/customising_the_admin_interface/cms_layout)
* [Rich Text Editing](/developer_guides/forms/field_types/htmleditorfield)

2
docs/en/02_Developer_Guides/15_Customising_the_Admin_Interface/05_Typography.md
View File

@ -30,4 +30,4 @@ After you have defined the `editor.css` make sure you clear your SilverStripe ca
## API Documentation
* [api:HtmlEditorConfig]
* [HtmlEditorConfig](api:SilverStripe\Forms\HTMLEditor\HtmlEditorConfig)

4
docs/en/02_Developer_Guides/15_Customising_the_Admin_Interface/06_Javascript_Development.md
View File

@ -368,7 +368,7 @@ attributes, or the jQuery.metadata plugin). For returning status messages, pleas
Only return evaluated JavaScript snippets if unavoidable. Most of the time you can just pass data around, and let the
clientside react to changes appropriately without telling it directly through JavaScript in AJAX responses. Don't use
the [api:Form] SilverStripe class, which is built solely around
the [Form](api:SilverStripe\Forms\Form) SilverStripe class, which is built solely around
this inflexible concept.
Example: Autocomplete input field loading page matches through AJAX
@ -439,7 +439,7 @@ JavaScript:
Although they are the minority of cases, there are times when a simple HTML fragment isn't enough. For example, if you
have server side code that needs to trigger the update of a couple of elements in the CMS left-hand tree, it would be
inefficient to send back the HTML of entire tree. SilverStripe can serialize to and from JSON (see the [api:Convert] class), and jQuery deals very well with it through
inefficient to send back the HTML of entire tree. SilverStripe can serialize to and from JSON (see the [Convert](api:SilverStripe\Core\Convert) class), and jQuery deals very well with it through
[jQuery.getJSON()](http://docs.jquery.com/Ajax/jQuery.getJSON#urldatacallback), as long as the HTTP content-type is
properly set.

8
docs/en/02_Developer_Guides/15_Customising_the_Admin_Interface/How_Tos/Customise_CMS_Menu.md
View File

@ -2,10 +2,10 @@
## Adding an administration panel
Every time you add a new extension of the [api:LeftAndMain] class to the CMS,
SilverStripe will automatically create a new [api:CMSMenuItem] for it
Every time you add a new extension of the [LeftAndMain](api:SilverStripe\Admin\LeftAndMain) class to the CMS,
SilverStripe will automatically create a new [CMSMenuItem](api:SilverStripe\Admin\CMSMenuItem) for it
The most popular extension of LeftAndMain is a [api:ModelAdmin] class, so
The most popular extension of LeftAndMain is a [ModelAdmin](api:SilverStripe\Admin\ModelAdmin) class, so
for a more detailed introduction to creating new `ModelAdmin` interfaces, read
the [ModelAdmin reference](../modeladmin).
@ -51,7 +51,7 @@ On top of your administration windows, the menu can also have external links
(e.g. to external reference). In this example, we're going to add a link to
Google to the menu.
First, we need to define a [api:LeftAndMainExtension] which will contain our
First, we need to define a [LeftAndMainExtension](api:SilverStripe\Admin\LeftAndMainExtension) which will contain our
button configuration.
:::php

12
docs/en/02_Developer_Guides/15_Customising_the_Admin_Interface/How_Tos/Customise_CMS_Tree.md
View File

@ -7,10 +7,10 @@ by the [jstree](http://jstree.com) library. It is configured through
`framework/admin/javascript/src/LeftAndMain.Tree.js`, as well as some
HTML5 metadata generated on its container (see the `data-hints` attribute).
The tree is rendered through [api:LeftAndMain::getSiteTreeFor()],
The tree is rendered through [LeftAndMain::getSiteTreeFor()](api:SilverStripe\Admin\LeftAndMain::getSiteTreeFor()),
which recursively collects all nodes based on various filtering criteria.
The node strictly just has to implement the [api:Hierarchy] extension,
but in the CMS usually is a [api:SiteTree] object.
The node strictly just has to implement the [Hierarchy](api:SilverStripe\ORM\Hierarchy\Hierarchy) extension,
but in the CMS usually is a [SiteTree](api:SilverStripe\CMS\Model\SiteTree) object.
## Add status lozenges to tree nodes
@ -43,13 +43,13 @@ code like this:
By applying the proper style sheet, the snippet html above could produce the look of:
![Page Node Screenshot](../../../_images/tree_node.png "Page Node")
SiteTree is a [api:DataObject] which is versioned by [api:Versioned] extension.
SiteTree is a [DataObject](api:SilverStripe\ORM\DataObject) which is versioned by [Versioned](api:SilverStripe\Versioned\Versioned) extension.
Each node can optionally have publication status flags, e.g. "Removed from draft".
Each flag has a unique identifier, which is also used as a CSS class for easier styling.
Developers can easily add a new flag, delete or alter an existing flag on how it is looked
or changing the flag label. The customization of these lozenges could be done either through
inherited subclass or [api:DataExtension]. It is just really about how we change the return
inherited subclass or [DataExtension](api:SilverStripe\ORM\DataExtension). It is just really about how we change the return
value of function `SiteTree->getTreeTitle()` by two easily extendable methods
`SiteTree->getStatusClass()` and `SiteTree->getStatusFlags()`.
@ -74,7 +74,7 @@ __Example: using a subclass__
}
}
The above subclass of [api:SiteTree] will add a new flag for indicating its
The above subclass of [SiteTree](api:SilverStripe\CMS\Model\SiteTree) will add a new flag for indicating its
__'Scheduled To Publish'__ status. The look of the page node will be changed
from ![Normal Page Node](../../../_images/page_node_normal.png) to ![Scheduled Page Node](../../../_images/page_node_scheduled.png). The getStatusFlags has an `updateStatusFlags()`
extension point, so the flags can be modified through `DataExtension` rather than

2
docs/en/02_Developer_Guides/15_Customising_the_Admin_Interface/How_Tos/Customise_Site_Reports.md
View File

@ -71,4 +71,4 @@ More useful reports can be created by changing the `DataList` returned in the `s
* More examples
## API documentation
[api:ReportAdmin]
[ReportAdmin](api:SilverStripe\Reports\ReportAdmin)

2
docs/en/02_Developer_Guides/15_Customising_the_Admin_Interface/How_Tos/Extending_An_Existing_ModelAdmin.md
View File

@ -1,7 +1,7 @@
## Extending existing ModelAdmin
Sometimes you'll work with ModelAdmins from other modules. To customise these interfaces, you can always subclass. But there's
also another tool at your disposal: The [api:Extension] API.
also another tool at your disposal: The [Extension](api:SilverStripe\Core\Extension) API.
:::php
class MyAdminExtension extends Extension {

2
docs/en/02_Developer_Guides/15_Customising_the_Admin_Interface/index.md
View File

@ -3,7 +3,7 @@ summary: Extend the admin view to provide custom behavior or new features for CM
introduction: The Admin interface can be extended to provide additional functionality to users and custom interfaces for managing data.
The Admin interface is bundled within the SilverStripe Framework but is most commonly used in conjunction with the `cms`
module. The main class for displaying the interface is a specialized [api:Controller] called [api:LeftAndMain], named
module. The main class for displaying the interface is a specialized [Controller](api:SilverStripe\Control\Controller) called [LeftAndMain](api:SilverStripe\Admin\LeftAndMain), named
as it is designed around a left hand navigation and a main edit form.
Starting with SilverStripe 4, the user interface logic is transitioned from

8
docs/en/02_Developer_Guides/16_Execution_Pipeline/01_Flushable.md
View File

@ -6,17 +6,17 @@ summary: Allows a class to define it's own flush functionality.
## Introduction
Allows a class to define it's own flush functionality, which is triggered when `flush=1` is requested in the URL.
[api:FlushMiddleware] is run before a request is made, calling `flush()` statically on all
implementors of [api:Flushable].
[FlushMiddleware](api:SilverStripe\Control\Middleware\FlushMiddleware) is run before a request is made, calling `flush()` statically on all
implementors of [Flushable](api:SilverStripe\Core\Flushable).
## Usage
To use this API, you need to make your class implement [api:Flushable], and define a `flush()` static function,
To use this API, you need to make your class implement [Flushable](api:SilverStripe\Core\Flushable), and define a `flush()` static function,
this defines the actions that need to be executed on a flush request.
### Using with Cache
This example uses [api:Cache] in some custom code, and the same cache is cleaned on flush:
This example uses [Cache](api:Cache) in some custom code, and the same cache is cleaned on flush:
:::php
<?php

20
docs/en/02_Developer_Guides/16_Execution_Pipeline/02_Manifests.md
View File

@ -11,23 +11,23 @@ Others store aggregate information like nested configuration graphs.
## Storage
By default, manifests are serialised and cached via a cache generated by the [api:ManifestCacheFactory].
By default, manifests are serialised and cached via a cache generated by the [ManifestCacheFactory](api:SilverStripe\Core\Cache\ManifestCacheFactory).
This can be customised via `SS_MANIFESTCACHE` environment variable to point to either another
[api:CacheFactory] or [CacheInterface](https://github.com/php-fig/cache/blob/master/src/CacheItemInterface.php)
[CacheFactory](api:SilverStripe\Core\Cache\CacheFactory) or [CacheInterface](https://github.com/php-fig/cache/blob/master/src/CacheItemInterface.php)
implementor.
## Traversing the Filesystem
Since manifests usually extract their information from files in the webroot,
they require a powerful traversal tool: [api:FileFinder].
they require a powerful traversal tool: [FileFinder](api:SilverStripe\Assets\FileFinder).
The class provides filtering abilities for files and folders, as well as
callbacks for recursive traversal. Each manifest has its own implementation,
for example [api:ManifestFileFinder], adding more domain specific filtering
for example [ManifestFileFinder](api:SilverStripe\Core\Manifest\ManifestFileFinder), adding more domain specific filtering
like including themes, or excluding testss.
## PHP Class Manifest
The [api:ClassManifest] builds a manifest of all classes, interfaces and some
The [ClassManifest](api:SilverStripe\Core\Manifest\ClassManifest) builds a manifest of all classes, interfaces and some
additional items present in a directory, and caches it.
It finds the following information:
@ -37,15 +37,15 @@ It finds the following information:
* All implementors of an interface
* All module configuration files
The gathered information can be accessed through [api:ClassLoader::inst()],
as well as [api:ClassInfo]. Some useful commands of the `ClassInfo` API:
The gathered information can be accessed through [ClassLoader::inst()](api:SilverStripe\Core\Manifest\ClassLoader::inst()),
as well as [ClassInfo](api:SilverStripe\Core\ClassInfo). Some useful commands of the `ClassInfo` API:
* `ClassInfo::subclassesFor($class)`: Returns a list of classes that inherit from the given class
* `ClassInfo::ancestry($class)`: Returns the passed class name along with all its parent class names
* `ClassInfo::implementorsOf($interfaceName)`: Returns all classes implementing the passed in interface
In the absence of a generic module API, it is also the primary way to identify
which modules are installed, through [api:ClassManifest::getModules()].
which modules are installed, through [ClassManifest::getModules()](api:SilverStripe\Core\Manifest\ClassManifest::getModules()).
A module is defined as a toplevel folder in the webroot which contains
either a `_config.php` file, or a `_config/` folder. Modules can be specifically
excluded from manifests by creating a blank `_manifest_exclude` file in the module folder.
@ -55,14 +55,14 @@ a `tests/` folder, unless tests are executed.
## Template Manifest
The [api:SS_TemplateManifest] class builds a manifest of all templates present in a directory,
The [SS_TemplateManifest](api:SS_TemplateManifest) class builds a manifest of all templates present in a directory,
in both modules and themes. Templates in `tests/` folders are automatically excluded.
The chapter on [template inheritance](../templates/template_inheritance) provides more details
on its operation.
## Config Manifest
The [api:ConfigManifest] loads builds a manifest of configuration items,
The [ConfigManifest](api:ConfigManifest) loads builds a manifest of configuration items,
for both PHP and YAML. It also takes care of ordering and merging configuration fragments.
The chapter on [configuration](../configuration) has more details.

16
docs/en/02_Developer_Guides/16_Execution_Pipeline/03_App_Object_and_Kernel.md
View File

@ -3,7 +3,7 @@ summary: Provides bootstrapping and entrypoint to the SilverStripe application
# Kernel
The [api:Kernel] object provides a container for the various manifests, services, and components
The [Kernel](api:SilverStripe\Core\Kernel) object provides a container for the various manifests, services, and components
which a SilverStripe application must have available in order for requests to be executed.
This can be accessed in user code via Injector
@ -16,18 +16,18 @@ This can be accessed in user code via Injector
Services accessible from this kernel include:
* getContainer() -> Current [api:Injector] service
* getThemeResourceLoader() -> [api:ThemeResourceLoader] Service for loading of discovered templates.
* getContainer() -> Current [Injector](api:SilverStripe\Core\Injector\Injector) service
* getThemeResourceLoader() -> [ThemeResourceLoader](api:SilverStripe\View\ThemeResourceLoader) Service for loading of discovered templates.
Also used to contain nested theme sets such as the `$default` set for all root module /templates folders.
* getEnvironment() -> String value for the current environment. One of 'dev', 'live' or 'test'
Several meta-services are also available from Kernel (which are themselves containers for
other core services) but are not commonly accessed directly:
* getClassLoader() -> [api:ClassLoader] service which handles the class manifest
* getModuleLoader() -> [api:ModuleLoadel] service which handles module registration
* getConfigLoader() -> [api:ConfigLoader] Service which assists with nesting of [api:Config] instances
* getInjectorLoader() -> [api:InjectorLoader] Service which assists with nesting of [api:Injector] instances
* getClassLoader() -> [ClassLoader](api:SilverStripe\Core\Manifest\ClassLoader) service which handles the class manifest
* getModuleLoader() -> [Manifest](api:SilverStripe\Core\Manifest) service which handles module registration
* getConfigLoader() -> [ConfigLoader](api:SilverStripe\Core\Config\ConfigLoader) Service which assists with nesting of [Config](api:SilverStripe\Core\Config\Config) instances
* getInjectorLoader() -> [InjectorLoader](api:SilverStripe\Core\Injector\InjectorLoader) Service which assists with nesting of [Injector](api:SilverStripe\Core\Injector\Injector) instances
## Kernel nesting
@ -60,7 +60,7 @@ The role of the application is to:
## HTTPApplication
The HTTPApplication provides a specialised application implementation for handling HTTP Requests.
This class provides basic support for HTTP Middleware, such as [api:ErrorControlChainMiddleware].
This class provides basic support for HTTP Middleware, such as [ErrorControlChainMiddleware](api:SilverStripe\Core\Startup\ErrorControlChainMiddleware).
`main.php` contains the default application implementation.

14
docs/en/02_Developer_Guides/16_Execution_Pipeline/index.md
View File

@ -86,13 +86,13 @@ tasks silently in the background.
[configuration file](/getting_started/environment_management) in the webroot.
* Sets constants based on the filesystem structure (e.g. `BASE_URL`, `BASE_PATH` and `TEMP_FOLDER`)
All requests go through `framework/main.php`, which sets up the core [api:Kernel] and [api:HTTPApplication]
All requests go through `framework/main.php`, which sets up the core [Kernel](api:SilverStripe\Core\Kernel) and [HTTPApplication](api:SilverStripe\Control\HTTPApplication)
objects. See [/developer_guides/execution_pipeline/app_object_and_kernel] for details on this.
The main process follows:
* Include `autoload.php`
* Construct [api:HTTPRequest] object from environment.
* Construct [HTTPRequest](api:SilverStripe\Control\HTTPRequest) object from environment.
* Construct a `Kernel` instance
* Construct a `HTTPApplication` instance
* Add any necessary middleware to this application
@ -107,19 +107,19 @@ before handing control off to SilverStripe's own `main.php`.
## Routing and Request Handling
The `main.php` script relies on [api:Director] to work out which [controller](../controllers/) should handle this request. It parses the URL, matching it to one of a number of patterns,
The `main.php` script relies on [Director](api:SilverStripe\Control\Director) to work out which [controller](../controllers/) should handle this request. It parses the URL, matching it to one of a number of patterns,
and determines the controller, action and any argument to be used ([Routing](../controllers/routing)).
* Creates a [api:HTTPRequest] object containing all request and environment information
* Creates a [HTTPRequest](api:SilverStripe\Control\HTTPRequest) object containing all request and environment information
* The [session](../cookies_and_sessions/sessions) holds an abstraction of PHP session
* Instantiates a [controller](../controllers/) object
* The [api:Injector] is first referenced, and asks the registered
* The [Injector](api:SilverStripe\Core\Injector\Injector) is first referenced, and asks the registered
[RequestFilter](../controllers/requestfilters)
to pre-process the request object (see below)
* The `Controller` executes the actual business logic and populates an [api:HTTPResponse]
* The `Controller` executes the actual business logic and populates an [HTTPResponse](api:SilverStripe\Control\HTTPResponse)
* The `Controller` can optionally hand off control to further nested controllers
* The `Controller` optionally renders a response body through `SSViewer` [templates](../templates)
* The [api:RequestProcessor] is called to post-process the request to allow
* The [RequestProcessor](api:SilverStripe\Control\RequestProcessor) is called to post-process the request to allow
further filtering before content is sent to the end user
* The response is output to the client

16
docs/en/02_Developer_Guides/18_Cookies_And_Sessions/01_Cookies.md
View File

@ -7,7 +7,7 @@ summary: A set of static methods for manipulating PHP cookies.
Cookies are a mechanism for storing data in the remote browser and thus tracking or identifying return users.
SilverStripe uses cookies for remembering users preferences. Application code can modify a users cookies through
the [api:Cookie] class. This class mostly follows the PHP API.
the [Cookie](api:SilverStripe\Control\Cookie) class. This class mostly follows the PHP API.
### set
@ -40,11 +40,11 @@ Clears a given cookie.
## Cookie_Backend
The [api:Cookie] class manipulates and sets cookies using a [api:Cookie_Backend]. The backend is in charge of the logic
that fetches, sets and expires cookies. By default we use a [api:CookieJar] backend which uses PHP's
The [Cookie](api:SilverStripe\Control\Cookie) class manipulates and sets cookies using a [Cookie_Backend](api:SilverStripe\Control\Cookie_Backend). The backend is in charge of the logic
that fetches, sets and expires cookies. By default we use a [CookieJar](api:SilverStripe\Control\CookieJar) backend which uses PHP's
[setcookie](http://www.php.net/manual/en/function.setcookie.php) function.
The [api:CookieJar] keeps track of cookies that have been set by the current process as well as those that were received
The [CookieJar](api:SilverStripe\Control\CookieJar) keeps track of cookies that have been set by the current process as well as those that were received
from the browser.
:::php
@ -94,7 +94,7 @@ If you need to implement your own Cookie_Backend you can use the injector system
Cookie_Backend:
class: MyCookieJar
To be a valid backend your class must implement the [api:Cookie_Backend] interface.
To be a valid backend your class must implement the [Cookie_Backend](api:SilverStripe\Control\Cookie_Backend) interface.
## Advanced Usage
@ -125,6 +125,6 @@ One can also access all of the cookies in one go using the `Cookie_Backend`
## API Documentation
* [api:Cookie]
* [api:CookieJar]
* [api:CookieBackend]
* [Cookie](api:SilverStripe\Control\Cookie)
* [CookieJar](api:SilverStripe\Control\CookieJar)
* [Cookie_Backend](api:SilverStripe\Control\Cookie_Backend)

2
docs/en/02_Developer_Guides/18_Cookies_And_Sessions/02_Sessions.md
View File

@ -76,4 +76,4 @@ This uses the session_name `SECSESSID` for `https` connections instead of the de
## API Documentation
* [api:Session]
* [Session](api:SilverStripe\Control\Session)

4
docs/en/02_Developer_Guides/18_Cookies_And_Sessions/index.md
View File

@ -6,5 +6,5 @@ introduction: Both the Cookie and Session classes can be used to preserve certai
## API Documentation
* [api:Cookie]
* [api:Session]
* [Cookie](api:SilverStripe\Control\Cookie)
* [Session](api:SilverStripe\Control\Session)

8
docs/en/04_Changelogs/2.4.3.md
View File

@ -145,7 +145,7 @@ Affected classes and methods:
### Usage of Controller::join_links() to concatenate links now mandatory
The `[api:Controller::join_links()]` method
The `[Controller::join_links()](api:SilverStripe\Control\Controller::join_links())` method
to create links within SilverStripe controllers is now mandatory. This method ensures that links with existing GET
parameters don't break through string concatenation.
@ -177,9 +177,9 @@ Full controller example:
Using this method is particularly important for any custom
`[api:TableListField]` or
`[api:ComplexTableField]` subclasses and any
`[api:LeftAndMain]` subclass for the CMS UI. These classes in
`[TableListField](api:TableListField)` or
`[ComplexTableField](api:ComplexTableField)` subclasses and any
`[LeftAndMain](api:SilverStripe\Admin\LeftAndMain)` subclass for the CMS UI. These classes in
particular were refactored to secure destructive links against Cross Site Request Forgery (CSRF). This is achieved via a
mandatory "SecurityID" GET parameter appended to the base link.

14
docs/en/04_Changelogs/3.0.0.md
View File

@ -431,9 +431,9 @@ Note: This property is optional (defaults to an empty string), but its usage is
### New ModelAdmin interface, removed sub-controllers [modeladmin]
ModelAdmin has been substanially rewritten to natively support the `[api:GridField]` API
for more flexible data presentation (replacing `[api:ComplexTableField]`),
and the `[api:DataList]` API for more expressive querying.
ModelAdmin has been substanially rewritten to natively support the `[GridField](api:SilverStripe\Forms\GridField\GridField)` API
for more flexible data presentation (replacing `[ComplexTableField](api:ComplexTableField)`),
and the `[DataList](api:SilverStripe\ORM\DataList)` API for more expressive querying.
If you have overwritten any methods in the class, customised templates,
or implemented your own `$collection_controller_class`/`$record_controller_class` controllers,
@ -451,7 +451,7 @@ extensions to the CMS interface.
The "compass" module is only required if core stylesheets are modified,
not when simply using the CMS or developing other CMS functionality.
If you want to extend the CMS stylesheets for your own projects without SCSS,
please create a new CSS file and link it into the CMS via `[api:LeftAndMain::require_css()]`.
please create a new CSS file and link it into the CMS via `[LeftAndMain::require_css()](api:SilverStripe\Admin\LeftAndMain::require_css())`.
### Built-in Javascript validation removed {#js-validation}
@ -463,11 +463,11 @@ any longer (the method is deprecated).
### FormField consistently adds classes to HTML elements [formfield-classes]###
The [api:FormField] API has been refactored to use SilverStripe templates
The [FormField](api:SilverStripe\Forms\FormField) API has been refactored to use SilverStripe templates
for constructing the field HTML, as well as new accessors for HTML attributes.
This change makes the HTML a bit more predictable, but it also means that
you need to check any code (CSS, JavaScript, etc) relying on the old inconsistencies.
Particularly, CSS class names applied through [api:FormField->addExtraClass()]
Particularly, CSS class names applied through [FormField->addExtraClass()](api:SilverStripe\Forms\FormField->addExtraClass())
and the "type" class are now consistently added to the container `<div>`
as well as the HTML form element itself.
@ -484,7 +484,7 @@ as well as the HTML form element itself.
### FormField constructor argument changes [formfield-constructor]###
In order to enforce a consistent parameter order in core [api:FormField] subclasses,
In order to enforce a consistent parameter order in core [FormField](api:SilverStripe\Forms\FormField) subclasses,
its no longer possible to set the following optional attributes via constructor arguments:
`$form`, `$maxLength`, `$rightTitle`, `$rows`/`$cols` (for `TextareaField` and `HtmlEditorField`)
and `$folderName` (for `FileField` and `SimpleImageField`).

4
docs/en/04_Changelogs/3.1.0.md
View File

@ -397,7 +397,7 @@ the following configuration: `RestfulService::set_default_curl_option(CURLOPT_SS
### Deprecation API {#deprecation}
The `[api:Deprecation]` API generates deprecation notices to help you future-proof your code.
The `[Deprecation](api:SilverStripe\Dev\Deprecation)` API generates deprecation notices to help you future-proof your code.
Calls to ceprecated methods will only produce errors if the API was deprecated in the
release equal to or earlier than the "notification version" (currently set to "3.1.0").
@ -437,7 +437,7 @@ you can enable those warnings and future-proof your code already.
methods like `encodeMultipart()`. Use the `Email` API, or the `Mailer` class where applicable.
* Removed non-functional `$inlineImages` option for sending emails
* Removed support for keyed arrays in `SelectionGroup`, use new `SelectionGroup_Item` object
to populate the list instead (see [API docs](api:SelectionGroup)).
to populate the list instead (see [API docs](api:SilverStripe\Forms\SelectionGroup)).
* `FormField->setDescription()` now renders in a `<span class="description">` by default, rather
than a `title` attribute * Removed `Form->Name()`: Use getName()
* Removed `FormField->setContainerFieldSet()`: Use setContainerFieldList()

8
docs/en/04_Changelogs/3.1.5.md
View File

@ -7,12 +7,12 @@
user login name between sessions, and disable browser auto-completion on the username field.
Note that users of certain browsers who have previously autofilled and saved login credentials
will need to clear their password autofill history before this setting is properly respected.
* Test cases that rely on updating and restoring `[api:Injector]` services may now take advantage
* Test cases that rely on updating and restoring `[Injector](api:SilverStripe\Core\Injector\Injector)` services may now take advantage
of the new `Injector::nest()` and `Injector::unnest()` methods to sandbox their alterations.
* If errors could potentially be raised by any `[api:RequestHandler]` class such as a `[api:Form]` or
`[api:Controller]`, you may now add the new `[api:ErrorPageControllerExtension]` to this class to
* If errors could potentially be raised by any `[RequestHandler](api:SilverStripe\Control\RequestHandler)` class such as a `[Form](api:SilverStripe\Forms\Form)` or
`[Controller](api:SilverStripe\Control\Controller)`, you may now add the new `[ErrorPageControllerExtension](api:SilverStripe\ErrorPage\ErrorPageControllerExtension)` to this class to
transform plain text error messages into `ErrorPage` rendered HTML errors. In the past this
behaviour was limited to subclasses of `[api:ContentController]`. By default this extension is now
behaviour was limited to subclasses of `[ContentController](api:SilverStripe\CMS\Controllers\ContentController)`. By default this extension is now
added to the `Security` controller, and if this is not desirable then it should be removed
explicitly via the Config system.

4
docs/en/04_Changelogs/3.1.7.md
View File

@ -8,11 +8,11 @@
and continue working should their session expire. This occurs through a popup dialog, which asks the user for their
current password to continue working.
If using a custom `[api:Authenticator]` class to replace the default MemberAuthenticator, then by default this feature
If using a custom `[Authenticator](api:SilverStripe\Security\Authenticator)` class to replace the default MemberAuthenticator, then by default this feature
will be disabled. If multiple authenticators are used, only supported ones will be available within the CMS.
In order to create a CMS supported version the `Authenticator::supports_cms` and `Authenticator::get_cms_login_form`
methods should be overridden. See `[api:MemberAuthenticator]` for an example implementation.
methods should be overridden. See `[MemberAuthenticator](api:SilverStripe\Security\MemberAuthenticator\MemberAuthenticator)` for an example implementation.
Check the documentation at the [Authentication](/developer_guides/security/authentication) topic.

4
docs/en/04_Changelogs/3.2.0.md
View File

@ -185,7 +185,7 @@ The following functionality deprecated in 3.0 has been removed:
### Enable PDO
Although this is not a mandatory upgrade step, the new `[api:PDOConnector]` class offers improved database
Although this is not a mandatory upgrade step, the new `[PDOConnector](api:SilverStripe\ORM\Connect\PDOConnector)` class offers improved database
performance and security, and should be integrated into any project using 3.2.
In order to update your connector you can do so in one of two ways, depending on whether or not
@ -273,7 +273,7 @@ Certain file types such as swf, html, htm, xhtml and xml have been removed from
of allowable file uploads. If your application requires the ability to upload these,
you will need to append these to the `File.allowed_extensions` config as necessary.
Also if uploading other file types, it's necessary to ensure that `File.allowed_extensions`
includes that extension, as extensions passed to `[api:UploadField]` will be filtered against
includes that extension, as extensions passed to `[UploadField](api:SilverStripe\AssetAdmin\Forms\UploadField)` will be filtered against
this list.
### Removed format detection in i18n::$date_format and i18n::$time_format

40
docs/en/04_Changelogs/4.0.0.md
View File

@ -415,6 +415,9 @@ You can resolve this in your model by adding an explicit cast to HTML for those
Before:
```php
use SilverStripe\View\ViewableData;
use SilverStripe\Core\Convert;
class MyObject extends ViewableData
{
public function getSomeHTML
@ -428,7 +431,7 @@ class MyObject extends ViewableData
After:
```php
class MyObject extends ViewableData
class MyObject extends SilverStripe\View\ViewableData
{
private static $casting = [
'SomeHTML' => 'HTMLText'
@ -436,7 +439,7 @@ class MyObject extends ViewableData
public function getSomeHTML
{
$title = Convert::raw2xml($this->Title);
$title = SilverStripe\Core\Convert::raw2xml($this->Title);
return "<h1>{$title}</h1>";
}
}
@ -652,8 +655,8 @@ if the asset is an image or not, rather than checking the subclass, as the asset
an image filter applied, rather than an instance of the `Image` dataobject.
In addition, a new file category `image/supported` has been added, which is a subset of the `image` category.
This is the subset of all image types which may be assigned to the `[api:Image]` dataobject, and may have
manipulations applied to it. This should be used as the file type restriction on any `[api:UploadField]` which
This is the subset of all image types which may be assigned to the `[Image](api:SilverStripe\Assets\Image)` dataobject, and may have
manipulations applied to it. This should be used as the file type restriction on any `[UploadField](api:SilverStripe\AssetAdmin\Forms\UploadField)` which
is intended to upload images for manipulation.
```diff
@ -671,7 +674,7 @@ In cases where image-only assets may be assigned to relationships then your data
an `Image` datatype, or refer to `DBFile('image/supported')`.
```php
class MyObject extends DataObject
class MyObject extends SilverStripe\ORM\DataObject
{
private static $has_one = [
"ImageObject" => "Image"
@ -726,7 +729,7 @@ There are other important considerations in working with File dataobjects which
You can disable File versioning by adding the following to your `_config.php`
```php
File::remove_extension('Versioned');
SilverStripe\Assets\File::remove_extension('Versioned');
```
#### Upgrading code performs custom image manipulations
@ -743,7 +746,7 @@ Before:
```php
// in MyImageExtension.php
class MyImageExtension extends DataExtension
class MyImageExtension extends SilverStripe\ORM\DataExtension
{
public function GalleryThumbnail($height)
{
@ -757,14 +760,14 @@ class MyImageExtension extends DataExtension
}
// in _config.php
Image::add_extension('MyImageExtension');
SilverStripe\Assets\Image::add_extension('MyImageExtension');
```
Now image manipulations are implemented with a single method via a callback generator:
```php
// in MyImageExtension.php
class MyImageExtension extends Extension
class MyImageExtension extends SilverStripe\Core\Extension
{
public function GalleryThumbnail($height)
{
@ -842,6 +845,9 @@ that handled saving of content into composite fields can be removed, as it is no
The below describes the minimum amount of effort required to implement a composite DB field.
```php
<?php
use SilverStripe\ORM\FieldType\DBComposite;
class MyAddressField extends DBComposite
{
private static $composite_db = ]
@ -853,7 +859,7 @@ class MyAddressField extends DBComposite
public function scaffoldFormField($title = null)
{
new AddressFormField($this->getName(), $title);
new SilverStripe\Forms\TextField($this->getName(), $title);
}
}
```
@ -903,15 +909,15 @@ class BannerImage extends DataObject
}
```
In order to ensure you are using the correct table for any class a new [api:DataObjectSchema] service
In order to ensure you are using the correct table for any class a new [DataObjectSchema](api:SilverStripe\ORM\DataObjectSchema) service
is available to manage these mappings (see [versioned documentation](/developer_guides/model/data_model_and_orm)).
```php
public function countDuplicates($model, $fieldToCheck)
{
$table = DataObject::getSchema()->tableForField($model, $field);
$query = new SQLSelect();
$table = SilverStripe\ORM\DataObject::getSchema()->tableForField($model, $field);
$query = new SilverStripe\ORM\Queries\SQLSelect();
$query->setFrom("\"{$table}\"");
$query->setWhere(["\"{$table}\".\"{$field}\"" => $model->$fieldToCheck]);
return $query->count();
@ -1034,7 +1040,7 @@ The optional `ss_macron` plugin for inserting Māori diacritical marks
has been removed from core. You can configure the built-in `charmap` plugin instead:
```php
$editor = HtmlEditorConfig::get('cms');
$editor = SilverStripe\Forms\HTMLEditor\HtmlEditorConfig::get('cms');
$editor->enablePlugins('charmap');
$editor->addButtonsToLine(1, 'charmap');
$editor->setOption('charmap_append', [
@ -1067,7 +1073,7 @@ if it only has versioning without staging.
/**
* This model has staging and versioning. Stages will be "Stage" and "Live"
*/
class MyStagedModel extends DataObject
class MyStagedModel extends SilverStripe\ORM\DataObject
{
private staic $extensions = [
"SilverStripe\\ORM\\Versioning\\Versioned('StagedVersioned')"
@ -1132,6 +1138,8 @@ An exception to this is any classes which once had the `SS_` prefix, which will
Before:
```php
use SilverStripe\ORM\DataObject;
class MyObject extends DataObject
{
private static $db = [
@ -1716,7 +1724,7 @@ The below methods have been added or had their functionality updated to `DBDate`
#### <a name="overview-filesystem-api"></a>Filesystem API Additions / Changes
* Image manipulations have been moved into a new `[api:ImageManipulation]` trait.
* Image manipulations have been moved into a new `[ImageManipulation](api:SilverStripe\Assets\ImageManipulation)` trait.
* `CMSFileAddController` removed.
* `UploadField::setAllowedFileCategories('image')` now excludes non-resizeable images. 'unresizeable_image' is
can be used to validate these types.

8
docs/en/04_Changelogs/alpha/4.0.0-alpha1.md
View File

@ -12,7 +12,7 @@
* `DataObject::database_fields` now returns all fields on that table.
* `DataObject::db` now returns composite fields.
* `DataObject::ClassName` field has been refactored into a `DBClassName` type field.
* Image manipulations have been moved into a new `[api:ImageManipulation]` trait.
* Image manipulations have been moved into a new `[ImageManipulation](api:SilverStripe\Assets\ImageManipulation)` trait.
* `CMSFileAddController` removed.
* `UploadField::setAllowedFileCategories('image')` now excludes non-resizeable images. 'unresizeable_image' is
can be used to validate these types.
@ -338,8 +338,8 @@ if the asset is an image or not, rather than checking the subclass, as the asset
an image filter applied, rather than an instance of the `Image` dataobject.
In addition, a new file category `image/supported` has been added, which is a subset of the `image` category.
This is the subset of all image types which may be assigned to the `[api:Image]` dataobject, and may have
manipulations applied to it. This should be used as the file type restriction on any `[api:UploadField]` which
This is the subset of all image types which may be assigned to the `[Image](api:SilverStripe\Assets\Image)` dataobject, and may have
manipulations applied to it. This should be used as the file type restriction on any `[UploadField](api:SilverStripe\AssetAdmin\Forms\UploadField)` which
is intended to upload images for manipulation.
Before:
@ -432,7 +432,7 @@ You can disable File versioning by adding the following to your _config.php
:::php
File::remove_extension('Versioned');
SilverStripe\Assets\File::remove_extension('SilverStripe\\Versioned\\Versioned');
### Upgrading code performs custom image manipulations

2
docs/en/04_Changelogs/beta/3.2.0-beta1.md
View File

@ -241,7 +241,7 @@ Certain file types such as swf, html, htm, xhtml and xml have been removed from
of allowable file uploads. If your application requires the ability to upload these,
you will need to append these to the `File.allowed_extensions` config as necessary.
Also if uploading other file types, it's necessary to ensure that `File.allowed_extensions`
includes that extension, as extensions passed to `[api:UploadField]` will be filtered against
includes that extension, as extensions passed to `[UploadField](api:SilverStripe\AssetAdmin\Forms\UploadField)` will be filtered against
this list.
### Removed format detection in i18n::$date_format and i18n::$time_format

8
docs/en/04_Changelogs/rc/3.1.5-rc1.md
View File

@ -7,12 +7,12 @@
user login name between sessions, and disable browser auto-completion on the username field.
Note that users of certain browsers who have previously autofilled and saved login credentials
will need to clear their password autofill history before this setting is properly respected.
* Test cases that rely on updating and restoring `[api:Injector]` services may now take advantage
* Test cases that rely on updating and restoring `[Injector](api:SilverStripe\Core\Injector\Injector)` services may now take advantage
of the new `Injector::nest()` and `Injector::unnest()` methods to sandbox their alterations.
* If errors could potentially be raised by any `[api:RequestHandler]` class such as a `[api:Form]` or
`[api:Controller]`, you may now add the new `[api:ErrorPageControllerExtension]` to this class to
* If errors could potentially be raised by any `[RequestHandler](api:SilverStripe\Control\RequestHandler)` class such as a `[Form](api:SilverStripe\Forms\Form)` or
`[Controller](api:SilverStripe\Control\Controller)`, you may now add the new `[ErrorPageControllerExtension](api:SilverStripe\ErrorPage\ErrorPageControllerExtension)` to this class to
transform plain text error messages into `ErrorPage` rendered HTML errors. In the past this
behaviour was limited to subclasses of `[api:ContentController]`. By default this extension is now
behaviour was limited to subclasses of `[ContentController](api:SilverStripe\CMS\Controllers\ContentController)`. By default this extension is now
added to the `Security` controller, and if this is not desirable then it should be removed
explicitly via the Config system.

4
docs/en/04_Changelogs/rc/3.1.7-rc1.md
View File

@ -8,11 +8,11 @@
and continue working should their session expire. This occurs through a popup dialog, which asks the user for their
current password to continue working.
If using a custom `[api:Authenticator]` class to replace the default MemberAuthenticator, then by default this feature
If using a custom `[Authenticator](api:SilverStripe\Security\Authenticator)` class to replace the default MemberAuthenticator, then by default this feature
will be disabled. If multiple authenticators are used, only supported ones will be available within the CMS.
In order to create a CMS supported version the `Authenticator::supports_cms` and `Authenticator::get_cms_login_form`
methods should be overridden. See `[api:MemberAuthenticator]` for an example implementation.
methods should be overridden. See `[MemberAuthenticator](api:SilverStripe\Security\MemberAuthenticator\MemberAuthenticator)` for an example implementation.
Check the documentation at the [Authentication](/developer_guides/security/authentication) topic.

2
docs/en/05_Contributing/04_Release_Process.md
View File

@ -47,7 +47,7 @@ so we strive for giving ample warning on any upcoming changes through a "depreca
How to deprecate an API:
* Add a `@deprecated` item to the docblock tag, with a `{@link <class>}` item pointing to the new API to use.
* Update the deprecated code to throw a [api:Deprecation::notice()] error.
* Update the deprecated code to throw a [Deprecation::notice()](api:SilverStripe\Dev\Deprecation::notice()) error.
* Both the docblock and error message should contain the **target version** where the functionality is removed.
So, if you're committing the change to a *3.1* minor release, the target version will be *4.0*.
* Deprecations should not be committed to patch releases

2
docs/en/05_Contributing/05_Making_A_SilverStripe_Core_Release.md
View File

@ -190,7 +190,7 @@ and needs to be manually advanced):
create the new temporary release branch (via `--branch-auto`). You can also customise this branch
with `--branch=<branchname>`, but it's best to use the standard.
* `release:translate` All upstream transifex strings will be pulled into the
local master strings, and then the [api:i18nTextCollector] task will be invoked
local master strings, and then the [i18nTextCollector](api:SilverStripe\i18n\TextCollection\i18nTextCollector) task will be invoked
and will merge these strings together, before pushing all new master strings
back up to transifex to make them available for translation. Changes to these
files will also be automatically committed to git.