mirror of
https://github.com/silverstripe/silverstripe-framework
synced 2024-10-22 14:05:37 +02:00
DOCS Update all occurrences of /app/code/ to /app/src/ for correct v4 structure
Linked to #10099, I noticed another occurrence of /app/code/, so I've search and replaced all of them to /app/src/ for the correct v4 structure
This commit is contained in:
Michael Pritchard (HEIW)
parent
5c2b287f9b
commit
5ad7d5169f
@ -14,7 +14,7 @@ about how to store its data in the database and how to format the information co
|
||||
|
||||
In the `Player` example, we have four database columns each with a different data type (Int, Varchar).
|
||||
|
||||
**app/code/Player.php**
|
||||
**app/src/Player.php**
|
||||
|
||||
```php
|
||||
use SilverStripe\ORM\DataObject;
|
||||
@ -107,7 +107,7 @@ output. You can manually create instances of a Data Type and pass it through to
|
||||
In 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`.
|
||||
|
||||
**app/code/Player.php**
|
||||
**app/src/Player.php**
|
||||
|
||||
```php
|
||||
use SilverStripe\ORM\FieldType\DBField;
|
||||
|
||||
@ -831,7 +831,7 @@ In templates, you don't need to worry about this distinction. The `$Content` var
|
||||
default, and previews draft content only if explicitly requested (e.g. by the "preview" feature in the CMS, or by adding ?stage=Stage to the URL). If you want
|
||||
to force a specific stage, we recommend the `Controller->init()` method for this purpose, for example:
|
||||
|
||||
**app/code/MyController.php**
|
||||
**app/src/MyController.php**
|
||||
```php
|
||||
public function init()
|
||||
{
|
||||
|
||||
@ -54,7 +54,7 @@ support the following:
|
||||
* `unique`: Index plus uniqueness constraint on the value
|
||||
* `fulltext`: Fulltext content index
|
||||
|
||||
**app/code/MyTestObject.php**
|
||||
**app/src/MyTestObject.php**
|
||||
|
||||
```php
|
||||
use SilverStripe\ORM\DataObject;
|
||||
|
||||
@ -105,7 +105,7 @@ For more detail around how variables are inserted and formatted into a template
|
||||
|
||||
Variables can come from your database fields, or custom methods you define on your objects.
|
||||
|
||||
**app/code/Page.php**
|
||||
**app/src/Page.php**
|
||||
|
||||
```php
|
||||
public function UsersIpAddress()
|
||||
@ -114,7 +114,7 @@ public function UsersIpAddress()
|
||||
}
|
||||
```
|
||||
|
||||
**app/code/Page.ss**
|
||||
**app/src/Page.ss**
|
||||
|
||||
```html
|
||||
<p>You are coming from $UsersIpAddress.</p>
|
||||
@ -129,7 +129,7 @@ object the methods get called on. For the standard `Page.ss` template the scope
|
||||
class. This object gives you access to all the database fields on [PageController](api:SilverStripe\CMS\Model\SiteTree\PageController), its corresponding [Page](api:SilverStripe\CMS\Model\SiteTree\Page)
|
||||
record and any subclasses of those two.
|
||||
|
||||
**app/code/Layout/Page.ss**
|
||||
**app/src/Layout/Page.ss**
|
||||
|
||||
```ss
|
||||
$Title
|
||||
|
||||
@ -22,7 +22,7 @@ The following will render the given data into a template. Given the template:
|
||||
Our application code can render into that view using `renderWith`. This method is called on the [ViewableData](api:SilverStripe\View\ViewableData)
|
||||
instance with a template name or an array of templates to render.
|
||||
|
||||
**app/code/Page.php**
|
||||
**app/src/Page.php**
|
||||
|
||||
```php
|
||||
$arrayData = new SilverStripe\View\ArrayData([
|
||||
|
||||
@ -13,7 +13,7 @@ All objects that are being rendered in a template should be a [ViewableData](api
|
||||
For instance, if we provide a [DBHtmlText](api:SilverStripe\ORM\FieldType\DBHtmlText) instance to the template we can call the `FirstParagraph` method. This will
|
||||
output the result of the [DBHtmlText::FirstParagraph()](api:SilverStripe\ORM\FieldType\DBHtmlText::FirstParagraph()) method to the template.
|
||||
|
||||
**app/code/Page.ss**
|
||||
**app/src/Page.ss**
|
||||
|
||||
```ss
|
||||
$Content.FirstParagraph
|
||||
@ -47,7 +47,7 @@ your text instances. For other objects such as [DBDatetime](api:SilverStripe\ORM
|
||||
When rendering an object to the template such as `$Me` the `forTemplate` method is called. This method can be used to
|
||||
provide default template for an object.
|
||||
|
||||
**app/code/Page.php**
|
||||
**app/src/Page.php**
|
||||
|
||||
```php
|
||||
use SilverStripe\CMS\Model\SiteTree;
|
||||
|
||||
@ -11,7 +11,7 @@ all your record, then wraps it in a [PaginatedList](api:SilverStripe\ORM\Paginat
|
||||
|
||||
The `PaginatedList` will automatically set up query limits and read the request for information.
|
||||
|
||||
**app/code/Page.php**
|
||||
**app/src/Page.php**
|
||||
|
||||
```php
|
||||
use SilverStripe\ORM\PaginatedList;
|
||||
|
||||
@ -8,7 +8,7 @@ summary: A brief look at the definition of a Controller, creating actions and ho
|
||||
The following example is for a simple [Controller](api:SilverStripe\Control\Controller) class. When building off the Silverstripe CMS you will
|
||||
subclass the base `Controller` class.
|
||||
|
||||
**app/code/controllers/TeamController.php**
|
||||
**app/src/controllers/TeamController.php**
|
||||
|
||||
```php
|
||||
use SilverStripe\Control\Controller;
|
||||
@ -79,7 +79,7 @@ Action methods can return one of four main things:
|
||||
* an [HTTPResponse](api:SilverStripe\Control\HTTPResponse) containing a manually defined `status code` and `body`.
|
||||
* an [HTTPResponse_Exception](api:SilverStripe\Control\HTTPResponse_Exception). A special type of response which indicates an error. By returning the exception, the execution pipeline can adapt and display any error handlers.
|
||||
|
||||
**app/code/controllers/TeamController.php**
|
||||
**app/src/controllers/TeamController.php**
|
||||
|
||||
```php
|
||||
/**
|
||||
@ -165,7 +165,7 @@ For more information about templates, inheritance and how to render into views,
|
||||
Each controller should define a `Link()` method. This should be used to avoid hard coding your routing in views,
|
||||
as well as give other features in Silverstripe CMS the ability to influence link behaviour.
|
||||
|
||||
**app/code/controllers/TeamController.php**
|
||||
**app/src/controllers/TeamController.php**
|
||||
|
||||
```php
|
||||
public function Link($action = null)
|
||||
|
||||
@ -205,7 +205,7 @@ you can specify these in your Controller class via the **$url_handlers** static
|
||||
This is useful when you want to provide custom actions for the mapping of `teams/*`. Say for instance we want to respond
|
||||
`coaches`, and `staff` to the one controller action `payroll`.
|
||||
|
||||
**app/code/controllers/TeamController.php**
|
||||
**app/src/controllers/TeamController.php**
|
||||
|
||||
```php
|
||||
use SilverStripe\Control\Controller;
|
||||
|
||||
@ -9,7 +9,7 @@ icon: reply
|
||||
Controllers can facilitate redirecting users from one place to another using `HTTP` redirection using the `Location`
|
||||
HTTP header.
|
||||
|
||||
**app/code/Page.php**
|
||||
**app/src/Page.php**
|
||||
|
||||
|
||||
```php
|
||||
|
||||
@ -21,7 +21,7 @@ In addition, you should return an `HTTPResponse` object. In normal cases, this s
|
||||
`$response` object returned by `$delegate`, perhaps with some modification. However, sometimes you
|
||||
will deliberately return a different response, e.g. an error response or a redirection.
|
||||
|
||||
**app/code/CustomMiddleware.php**
|
||||
**app/src/CustomMiddleware.php**
|
||||
|
||||
```php
|
||||
use SilverStripe\Control\Middleware\HTTPMiddleware;
|
||||
|
||||
@ -14,7 +14,7 @@ Browsers without support receive an `<input type=text>` based polyfill.
|
||||
|
||||
The following example will add a simple DateField to your Page, allowing you to enter a date manually.
|
||||
|
||||
**app/code/Page.php**
|
||||
**app/src/Page.php**
|
||||
|
||||
|
||||
```php
|
||||
|
||||
@ -16,7 +16,7 @@ information about inserted images or media elements.
|
||||
The framework comes with a [HTMLEditorField](api:SilverStripe\Forms\HTMLEditor\HTMLEditorField) form field class which encapsulates most of the required
|
||||
functionality. It is usually added through the [DataObject::getCMSFields()](api:SilverStripe\ORM\DataObject::getCMSFields()) method:
|
||||
|
||||
**app/code/MyObject.php**
|
||||
**app/src/MyObject.php**
|
||||
|
||||
|
||||
```php
|
||||
@ -338,7 +338,7 @@ Example: Remove field for "image captions"
|
||||
```php
|
||||
use SilverStripe\Core\Extension;
|
||||
|
||||
// File: app/code/MyToolbarExtension.php
|
||||
// File: app/src/MyToolbarExtension.php
|
||||
class MyToolbarExtension extends Extension
|
||||
{
|
||||
public function updateFieldsForImage(&$fields, $url, $file)
|
||||
@ -383,7 +383,7 @@ of the CMS you have to take care of instantiate yourself:
|
||||
use SilverStripe\Admin\ModalController;
|
||||
use SilverStripe\Control\Controller;
|
||||
|
||||
// File: app/code/MyController.php
|
||||
// File: app/src/MyController.php
|
||||
class MyObjectController extends Controller
|
||||
{
|
||||
public function Modals()
|
||||
|
||||
@ -30,7 +30,7 @@ a `GridField` has almost no functionality. The `GridFieldConfig` instance and th
|
||||
responsible for all the user interactions including formatting data to be readable, modifying data and performing any
|
||||
actions such as deleting records.
|
||||
|
||||
**app/code/Page.php**
|
||||
**app/src/Page.php**
|
||||
|
||||
|
||||
```php
|
||||
@ -66,7 +66,7 @@ This will display a bare bones `GridField` instance under `Pages` tab in the CMS
|
||||
The configuration of those `GridFieldComponent` instances and the addition or subtraction of components is done through
|
||||
the `getConfig()` method on `GridField`.
|
||||
|
||||
**app/code/Page.php**
|
||||
**app/src/Page.php**
|
||||
|
||||
|
||||
```php
|
||||
|
||||
@ -11,7 +11,7 @@ to reuse the `Form` across multiple `Controller` classes rather than just one. A
|
||||
code for a `Form` is to create it as a subclass to `Form`. Let's look at a example of a `Form` which is on our
|
||||
`Controller` but would be better written as a subclass.
|
||||
|
||||
**app/code/Page.php**
|
||||
**app/src/Page.php**
|
||||
|
||||
```php
|
||||
use SilverStripe\Forms\FieldList;
|
||||
@ -78,7 +78,7 @@ class PageController extends ContentController
|
||||
Now that is a bit of code to include on our controller and generally makes the file look much more complex than it
|
||||
should be. Good practice would be to move this to a subclass and create a new instance for your particular controller.
|
||||
|
||||
**app/code/forms/SearchForm.php**
|
||||
**app/src/forms/SearchForm.php**
|
||||
|
||||
```php
|
||||
use SilverStripe\Forms\FieldList;
|
||||
@ -150,7 +150,7 @@ class SearchForm extends Form
|
||||
|
||||
Our controller will now just have to create a new instance of this form object. Keeping the file light and easy to read.
|
||||
|
||||
**app/code/Page.php**
|
||||
**app/src/Page.php**
|
||||
|
||||
|
||||
```php
|
||||
|
||||
@ -13,7 +13,7 @@ For example, a basic search form. We want to use the [Form](api:SilverStripe\For
|
||||
totally custom template to meet our needs. To do this, we'll provide the class with a unique template through
|
||||
`setTemplate`.
|
||||
|
||||
**app/code/Page.php**
|
||||
**app/src/Page.php**
|
||||
|
||||
|
||||
```php
|
||||
|
||||
@ -28,7 +28,7 @@ Configuration values are static properties on any Silverstripe CMS class. These
|
||||
marked with a `@config` docblock. The API documentation will also list the static properties for the class. They should
|
||||
be marked `private static` and follow the `lower_case_with_underscores` structure.
|
||||
|
||||
**app/code/MyClass.php**
|
||||
**app/src/MyClass.php**
|
||||
|
||||
|
||||
```php
|
||||
@ -65,7 +65,7 @@ $config = $this->config()->get('property');
|
||||
|
||||
You may need to apply the [Configurable](api:SilverStripe\Core\Config\Configurable) trait in order to access the `config()` method.
|
||||
|
||||
**app/code/MyOtherClass.php**
|
||||
**app/src/MyOtherClass.php**
|
||||
|
||||
```php
|
||||
use SilverStripe\Core\Config\Configurable;
|
||||
|
||||
@ -40,7 +40,7 @@ echo $config->Title;
|
||||
|
||||
To extend the options available in the panel, define your own fields via a [DataExtension](api:SilverStripe\ORM\DataExtension).
|
||||
|
||||
**app/code/extensions/CustomSiteConfig.php**
|
||||
**app/src/extensions/CustomSiteConfig.php**
|
||||
|
||||
|
||||
```php
|
||||
|
||||
@ -18,7 +18,7 @@ For performance reasons a few classes are excluded from receiving extensions, in
|
||||
and `RequestHandler`. You can still apply extensions to descendants of these classes.
|
||||
[/info]
|
||||
|
||||
**app/code/extensions/MyMemberExtension.php**
|
||||
**app/src/extensions/MyMemberExtension.php**
|
||||
|
||||
|
||||
```php
|
||||
@ -79,7 +79,7 @@ Extra database fields can be added with a extension in the same manner as if the
|
||||
they're applied to. These will be added to the table of the base object - the extension will actually edit the $db,
|
||||
$has_one etc.
|
||||
|
||||
**app/code/extensions/MyMemberExtension.php**
|
||||
**app/src/extensions/MyMemberExtension.php**
|
||||
|
||||
|
||||
```php
|
||||
@ -124,7 +124,7 @@ we added a `SayHi` method which is unique to our extension.
|
||||
// "Hi Sam"
|
||||
```
|
||||
|
||||
**app/code/Page.php**
|
||||
**app/src/Page.php**
|
||||
|
||||
```php
|
||||
use SilverStripe\Security\Security;
|
||||
@ -160,7 +160,7 @@ variables at that given point. In this case, the core function `getValidator` on
|
||||
`updateValidator` hook for developers to modify the core method. The `MyMemberExtension` would modify the core member's
|
||||
validator by defining the `updateValidator` method.
|
||||
|
||||
**app/code/extensions/MyMemberExtension.php**
|
||||
**app/src/extensions/MyMemberExtension.php**
|
||||
|
||||
|
||||
```php
|
||||
|
||||
@ -51,7 +51,7 @@ ShortcodeParser::get_active()->parse($text);
|
||||
|
||||
First we need to define a callback for the shortcode.
|
||||
|
||||
**app/code/Page.php**
|
||||
**app/src/Page.php**
|
||||
|
||||
|
||||
```php
|
||||
|
||||
@ -171,7 +171,7 @@ SilverStripe\Core\Injector\Injector:
|
||||
factory: MyFactory
|
||||
```
|
||||
|
||||
**app/code/MyFactory.php**
|
||||
**app/src/MyFactory.php**
|
||||
|
||||
|
||||
```php
|
||||
|
||||
@ -46,7 +46,7 @@ This doesn't cover all cases used by Silverstripe CMS so is not a complete solut
|
||||
used.
|
||||
[/notice]
|
||||
|
||||
**app/code/MySQLWriteDbAspect.php**
|
||||
**app/src/MySQLWriteDbAspect.php**
|
||||
|
||||
|
||||
```php
|
||||
|
||||
@ -8,7 +8,7 @@ summary: Test models, database logic and your object methods.
|
||||
A Unit Test is an automated piece of code that invokes a unit of work in the application and then checks the behavior
|
||||
to ensure that it works as it should. A simple example would be to test the result of a PHP method.
|
||||
|
||||
**app/code/Page.php**
|
||||
**app/src/Page.php**
|
||||
|
||||
|
||||
```php
|
||||
|
||||
@ -58,7 +58,7 @@ RSSFeed::linkToFeed($link, $title);
|
||||
You can use [RSSFeed](api:SilverStripe\Control\RSS\RSSFeed) to easily create a feed showing your latest Page updates. The following example adds a page
|
||||
`/home/rss/` which displays an XML file the latest updated pages.
|
||||
|
||||
**app/code/PageController.php**
|
||||
**app/src/PageController.php**
|
||||
|
||||
```php
|
||||
use SilverStripe\Control\RSS\RSSFeed;
|
||||
@ -195,7 +195,7 @@ Say from that last example we want to include the Players Team in the XML feed w
|
||||
|
||||
`setTemplate` can then be used to tell RSSFeed to use that new template.
|
||||
|
||||
**app/code/Page.php**
|
||||
**app/src/Page.php**
|
||||
|
||||
```php
|
||||
use SilverStripe\Control\RSS\RSSFeed;
|
||||
|
||||
@ -19,7 +19,7 @@ containing a list of football players and the team they play for. The file we ha
|
||||
This data needs to be imported into our application. For this, we have two `DataObjects` setup. `Player` contains
|
||||
information about the individual player and a relation set up for managing the `Team`.
|
||||
|
||||
**app/code/Player.php**.
|
||||
**app/src/Player.php**.
|
||||
|
||||
|
||||
```php
|
||||
@ -41,7 +41,7 @@ class Player extends DataObject
|
||||
}
|
||||
```
|
||||
|
||||
**app/code/FootballTeam.php**
|
||||
**app/src/FootballTeam.php**
|
||||
|
||||
|
||||
```php
|
||||
@ -71,7 +71,7 @@ column
|
||||
|
||||
Our final import looks like this.
|
||||
|
||||
**app/code/PlayerCsvBulkLoader.php**
|
||||
**app/src/PlayerCsvBulkLoader.php**
|
||||
|
||||
|
||||
```php
|
||||
|
||||
@ -19,7 +19,7 @@ also be used in other areas of your application.
|
||||
Let's assume we want to manage a simple product listing as a sample data model: A product can have a name, price, and
|
||||
a category.
|
||||
|
||||
**app/code/Product.php**
|
||||
**app/src/Product.php**
|
||||
|
||||
|
||||
```php
|
||||
@ -40,7 +40,7 @@ class Product extends DataObject
|
||||
}
|
||||
```
|
||||
|
||||
**app/code/Category.php**
|
||||
**app/src/Category.php**
|
||||
|
||||
|
||||
```php
|
||||
@ -64,7 +64,7 @@ DataObject's you want to scaffold an interface for. The class can manage multipl
|
||||
|
||||
We'll name it `MyAdmin`, but the class name can be anything you want.
|
||||
|
||||
**app/code/MyAdmin.php**
|
||||
**app/src/MyAdmin.php**
|
||||
|
||||
|
||||
```php
|
||||
@ -155,7 +155,7 @@ The [DataObject](api:SilverStripe\ORM\DataObject) API has more granular permissi
|
||||
Available checks are `canEdit()`, `canCreate()`, `canView()` and `canDelete()`. Models check for administrator
|
||||
permissions by default. For most cases, less restrictive checks make sense, e.g. checking for general CMS access rights.
|
||||
|
||||
**app/code/Category.php**
|
||||
**app/src/Category.php**
|
||||
|
||||
|
||||
```php
|
||||
@ -208,7 +208,7 @@ class makes a guess at how those fields should be searched, e.g. showing a check
|
||||
To remove, add or modify searchable fields, define a new [DataObject::$searchable_fields](api:SilverStripe\ORM\DataObject::$searchable_fields) static on your model
|
||||
class (see [SearchContext](../search/searchcontext) docs for details).
|
||||
|
||||
**app/code/Product.php**
|
||||
**app/src/Product.php**
|
||||
|
||||
|
||||
```php
|
||||
@ -234,7 +234,7 @@ The results are shown in a tabular listing, powered by the [GridField](../forms/
|
||||
the [GridFieldDataColumns](api:SilverStripe\Forms\GridField\GridFieldDataColumns) component. This component looks for a [DataObject::$summary_fields](api:SilverStripe\ORM\DataObject::$summary_fields) static on your
|
||||
model class, where you can add or remove columns. To change the title, use [DataObject::$field_labels](api:SilverStripe\ORM\DataObject::$field_labels).
|
||||
|
||||
**app/code/Product.php**
|
||||
**app/src/Product.php**
|
||||
|
||||
|
||||
```php
|
||||
@ -259,7 +259,7 @@ can be customized by additional SQL filters, joins.
|
||||
|
||||
For example, we might want to exclude all products without prices in our sample `MyAdmin` implementation.
|
||||
|
||||
**app/code/MyAdmin.php**
|
||||
**app/src/MyAdmin.php**
|
||||
|
||||
|
||||
```php
|
||||
@ -285,7 +285,7 @@ class MyAdmin extends ModelAdmin
|
||||
You can also customize the search behavior directly on your `ModelAdmin` instance. For example, we might want to have a
|
||||
checkbox which limits search results to expensive products (over $100).
|
||||
|
||||
**app/code/MyAdmin.php**
|
||||
**app/src/MyAdmin.php**
|
||||
|
||||
```php
|
||||
<?php
|
||||
@ -339,7 +339,7 @@ example, to add a new component.
|
||||
|
||||
### Overriding the methods on ModelAdmin
|
||||
|
||||
**app/code/MyAdmin.php**
|
||||
**app/src/MyAdmin.php**
|
||||
|
||||
|
||||
```php
|
||||
@ -372,7 +372,7 @@ class MyAdmin extends ModelAdmin
|
||||
The above example will add the component to all `GridField`s (of all managed models). Alternatively we can also add it
|
||||
to only one specific `GridField`:
|
||||
|
||||
**app/code/MyAdmin.php**
|
||||
**app/src/MyAdmin.php**
|
||||
|
||||
|
||||
```php
|
||||
@ -409,7 +409,7 @@ class MyAdmin extends ModelAdmin
|
||||
|
||||
You can use an Extension to achieve the same results. Extensions have the advantage of being reusable in many contexts.
|
||||
|
||||
**app/code/ModelAdminExtension.php**
|
||||
**app/src/ModelAdminExtension.php**
|
||||
|
||||
|
||||
```php
|
||||
@ -442,7 +442,7 @@ MyAdmin:
|
||||
|
||||
If you're developing against a version of Silverstripe CMS prior to 4.6, your only option is to override `getEditForm()`. This requires a bit more work to access the GridField and GridFieldConfig instances.
|
||||
|
||||
**app/code/MyAdmin.php**
|
||||
**app/src/MyAdmin.php**
|
||||
|
||||
```php
|
||||
<?php
|
||||
|
||||
@ -418,7 +418,7 @@ in a single Ajax request.
|
||||
```php
|
||||
use SilverStripe\Admin\LeftAndMain;
|
||||
|
||||
// app/code/MyAdmin.php
|
||||
// app/src/MyAdmin.php
|
||||
class MyAdmin extends LeftAndMain
|
||||
{
|
||||
private static $url_segment = 'myadmin';
|
||||
|
||||
@ -21,7 +21,7 @@ Here's a brief example on how to add sorting and a new column for a
|
||||
hypothetical `NewsPageHolder` type, which contains `NewsPage` children.
|
||||
|
||||
|
||||
**app/code/NewsPageHolder.php**
|
||||
**app/src/NewsPageHolder.php**
|
||||
|
||||
```php
|
||||
class NewsPageHolder extends Page
|
||||
@ -30,7 +30,7 @@ class NewsPageHolder extends Page
|
||||
}
|
||||
```
|
||||
|
||||
**app/code/NewsPage.php**
|
||||
**app/src/NewsPage.php**
|
||||
|
||||
```php
|
||||
class NewsPage extends Page
|
||||
@ -47,7 +47,7 @@ before its rendered. In this case, we limit our logic to the desired page type,
|
||||
although it's just as easy to implement changes which apply to all page types,
|
||||
or across page types with common characteristics.
|
||||
|
||||
**app/code/NewsPageHolderCMSMainExtension.php**
|
||||
**app/src/NewsPageHolderCMSMainExtension.php**
|
||||
|
||||
```php
|
||||
use SilverStripe\Core\Extension;
|
||||
|
||||
Loading…
Reference in New Issue
Block a user