mirror of
https://github.com/silverstripe/silverstripe-framework
synced 2024-10-03 06:38:51 +02:00
Merge remote-tracking branch 'origin/3.1'
This commit is contained in:
commit
538bf01860
@ -623,6 +623,20 @@ class Config_LRU {
|
||||
$this->indexing = array();
|
||||
}
|
||||
|
||||
public function __clone() {
|
||||
if (version_compare(PHP_VERSION, '5.3.7', '<')) {
|
||||
// SplFixedArray causes seg faults before PHP 5.3.7
|
||||
$cloned = array();
|
||||
}
|
||||
else {
|
||||
$cloned = new SplFixedArray(self::SIZE);
|
||||
}
|
||||
for ($i = 0; $i < self::SIZE; $i++) {
|
||||
$cloned[$i] = clone $this->cache[$i];
|
||||
}
|
||||
$this->cache = $cloned;
|
||||
}
|
||||
|
||||
public function set($key, $val, $tags = array()) {
|
||||
// Find an index to set at
|
||||
$replacing = null;
|
||||
|
@ -33,7 +33,7 @@
|
||||
|
||||
## Upgrading
|
||||
|
||||
### Static configuration properties are now immutable, you must use Config API.
|
||||
### Static properties are immutable and private, you must use Config API.
|
||||
|
||||
A common SilverStripe pattern is to use a static variable on a class to define a configuration parameter.
|
||||
The configuration system added in SilverStripe 3.0 builds on this by using this static variable as a way
|
||||
@ -75,6 +75,8 @@ Here's an example on how to rewrite a common `_config.php` configuration:
|
||||
SSViewer::set_theme('basic');
|
||||
}
|
||||
|
||||
Object::add_extension('Member', 'MyMemberExtension');
|
||||
|
||||
The ugpraded `_config.php`:
|
||||
|
||||
:::php
|
||||
@ -106,6 +108,9 @@ The upgraded `config.yml`:
|
||||
---
|
||||
SSViewer:
|
||||
theme: 'simple'
|
||||
Member:
|
||||
extensions:
|
||||
MyMemberExtension
|
||||
---
|
||||
Only:
|
||||
environment: 'live'
|
||||
@ -121,18 +126,54 @@ Some examples of changed notations (not exhaustive, there's over a hundred in to
|
||||
* `Director::setBaseURL`: Use `Director.alternate_base_url` instead
|
||||
* `SSViewer::setOption('rewriteHashlinks', ...)`: Use `SSViewer.rewrite_hashlinks` instead
|
||||
|
||||
**Important**: Please remember to upgrade the installer project as well, particularly
|
||||
<div class="warning" markdown='1'>
|
||||
Please remember to upgrade the installer project as well, particularly
|
||||
your `.htaccess` or `web.config` files. Web access to these sensitive YAML configuration files
|
||||
needs to be explicitly denied through these configuration files (see the [3.0.5 security release](/changelogs/3.0.4))
|
||||
for details.
|
||||
|
||||
This change will also affect any visibility modifiers on `SiteTree` subclasses
|
||||
in your own codebase, since those are further extended by SilverStripe core,
|
||||
e.g. `ErrorPage extends Page`. Please change all "core statics" like `$db`, `$has_one`,
|
||||
`$has_many`, `$many_many`, `$defaults`, etc to `private` visibility.
|
||||
</div>
|
||||
|
||||
For more information about how to use the config system, see the ["Configuration" topic](/topic/configuration).
|
||||
|
||||
### Statics in custom Page classes need to be "private"
|
||||
|
||||
Related to the configuration change described above, many statics in core are now
|
||||
marked with `private` visibility. While PHP allows making variables more visible
|
||||
(e.g. from "private" to "public"), it complains if you try to restrict visibility in subclasses.
|
||||
The core framework extends from the `Page` class in your own codebase (`mysite/`),
|
||||
which means you need to change those statics to `private` yourself.
|
||||
The same rules apply to controllers subclassd from `Page_Controller`.
|
||||
|
||||
Before:
|
||||
|
||||
:::php
|
||||
<?php
|
||||
class Page extends SiteTree {
|
||||
static $db = array('MyVar' => 'Text');
|
||||
}
|
||||
class Page_Controller extends ContentController {
|
||||
static $allowed_actions = array('myaction');
|
||||
}
|
||||
|
||||
After:
|
||||
|
||||
:::php
|
||||
<?php
|
||||
class Page extends SiteTree {
|
||||
private static $db = array('MyVar' => 'Text');
|
||||
}
|
||||
class Page_Controller extends ContentController {
|
||||
private static $allowed_actions = array('myaction');
|
||||
}
|
||||
|
||||
Most statics defined in `SiteTree` and `DataObject` are affected, for example:
|
||||
`$db`, `$has_one`, `$has_many`, `$many_many`, `$defaults`, `$allowed_children`.
|
||||
The same goes for statics defined in `ContentController`, e.g. `$allowed_actions`.
|
||||
|
||||
Classes which are not further extended by the core (e.g. all custom `DataObject` subclasses)
|
||||
are not affected by this change, although we recommend to mark those inherited statics
|
||||
as `private` as well, to make it clear that they should be accessed through the Config API.
|
||||
|
||||
### default_cast is now Text
|
||||
|
||||
In order to reduce the chance of accidentally allowing XSS attacks, the value of default_cast
|
||||
|
@ -62,7 +62,11 @@ or across page types with common characteristics.
|
||||
}
|
||||
}
|
||||
|
||||
Now you just need to enable the extension in your [configuration file](/topics/configuration).
|
||||
|
||||
// mysite/_config/config.yml
|
||||
LeftAndMain:
|
||||
extensions:
|
||||
- NewsPageHolderCMSMainExtension
|
||||
|
||||
You're all set! Don't forget to flush the caches by appending `?flush=all` to the URL.
|
@ -82,10 +82,12 @@ Create a new file called `mysite/code/BookmarkedPageExtension.php` and insert th
|
||||
}
|
||||
}
|
||||
|
||||
Enable the extension with the following line in `mysite/_config.php`:
|
||||
Enable the extension in your [configuration file](/topics/configuration)
|
||||
|
||||
:::php
|
||||
SiteTree::add_extension('BookmarkedPageExtension');
|
||||
:::yml
|
||||
SiteTree:
|
||||
extensions:
|
||||
- BookmarkedPageExtension
|
||||
|
||||
In order to add the field to the database, run a `dev/build/?flush=all`.
|
||||
Refresh the CMS, open a page for editing and you should see the new checkbox.
|
||||
@ -106,10 +108,12 @@ Add the following code to a new file `mysite/code/BookmarkedLeftAndMainExtension
|
||||
}
|
||||
}
|
||||
|
||||
Enable the extension with the following line in `mysite/_config.php`:
|
||||
Enable the extension in your [configuration file](/topics/configuration)
|
||||
|
||||
:::php
|
||||
LeftAndMain::add_extension('BookmarkedPagesLeftAndMainExtension');
|
||||
:::yml
|
||||
LeftAndMain:
|
||||
extensions:
|
||||
- BookmarkedPagesLeftAndMainExtension
|
||||
|
||||
As the last step, replace the hardcoded links with our list from the database.
|
||||
Find the `<ul>` you created earlier in `mysite/admin/templates/LeftAndMain.ss`
|
||||
|
@ -13,12 +13,8 @@ Your extension will need to be a subclass of `[api:DataExtension]` or the `[api:
|
||||
|
||||
:::php
|
||||
<?php
|
||||
|
||||
// mysite/code/CustomMember.php
|
||||
|
||||
class CustomMember extends DataExtension {
|
||||
|
||||
}
|
||||
// mysite/code/MyMemberExtension.php
|
||||
class MyMemberExtension extends DataExtension {}
|
||||
|
||||
This defines your own extension where you can add your own functions, database fields or other properties you want.
|
||||
After you create this extension however it does not yet apply it to your object. Next you need to tell SilverStripe what
|
||||
@ -26,23 +22,27 @@ class you want to extend.
|
||||
|
||||
### Adding a extension to a built-in class
|
||||
|
||||
Sometimes you will want to add extension to classes that you didn't make. For example, you might want to add the
|
||||
ForumRole extension to the `[api:Member]` object.
|
||||
Sometimes you will want to add extension to classes that you can't cleanly subclass.
|
||||
For example, you might want to add a `MyMemberExtension` class to the `[api:Member]` object.
|
||||
|
||||
In order to active this extension, you'd add the following to your [config.yml](/topics/configuration).
|
||||
|
||||
:::yml
|
||||
Member:
|
||||
extensions:
|
||||
- MyMemberExtension
|
||||
|
||||
Alternatively, you can add extensions through PHP code as well (in your `config.php` file),
|
||||
which means they can be used in conditional configuration.
|
||||
|
||||
:::php
|
||||
ClassYouWantToOverride::add_extension('Your Class Name');
|
||||
|
||||
|
||||
For example above we want to override Member with a Custom Member so we would write the following
|
||||
|
||||
:::php
|
||||
// add to mysite/_config.php
|
||||
Member::add_extension('CustomMember');
|
||||
// Preferred notation: Through the Config API
|
||||
Config::inst()->update('Member', 'extensions', array('MyMemberExtension'));
|
||||
// Legacy notation: Through static class access
|
||||
Member::add_extension('MyMemberExtension');
|
||||
|
||||
## Implementation
|
||||
|
||||
|
||||
### Adding extra database fields
|
||||
|
||||
Extra database fields can be added with a extension in the same manner as if they
|
||||
|
@ -88,19 +88,20 @@ and another subclass for the same email-address in the address-database.
|
||||
## Member Role Extension
|
||||
|
||||
Using inheritance to add extra behaviour or data fields to a member is limiting, because you can only inherit from 1
|
||||
class. A better way is to use role extensions to add this behaviour.
|
||||
class. A better way is to use role extensions to add this behaviour. Add the following to your
|
||||
`[config.yml](/topics/configuration)`.
|
||||
|
||||
:::php
|
||||
Member::add_extension('ForumRole');
|
||||
// OR
|
||||
Member::add_role('ForumRole');
|
||||
:::yml
|
||||
Member:
|
||||
extensions:
|
||||
- MyMemberExtension
|
||||
|
||||
A role extension is simply a subclass of `[api:DataExtension]` that is designed to be used to add behaviour to `[api: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.
|
||||
|
||||
:::php
|
||||
class ForumRole extends DataExtension {
|
||||
class MyMemberExtension extends DataExtension {
|
||||
/**
|
||||
|
||||
* Modify the field set to be displayed in the CMS detail pop-up
|
||||
|
@ -245,8 +245,12 @@ also another tool at your disposal: The `[api:Extension]` API.
|
||||
}
|
||||
}
|
||||
|
||||
// mysite/_config.php
|
||||
MyAdmin::add_extension('MyAdminExtension');
|
||||
Now enable this extension through your `[config.yml](/topics/configuration)` file.
|
||||
|
||||
:::yml
|
||||
MyAdmin:
|
||||
extensions:
|
||||
- MyAdminExtension
|
||||
|
||||
The following extension points are available: `updateEditForm()`, `updateSearchContext()`,
|
||||
`updateSearchForm()`, `updateList()`, `updateImportForm`.
|
||||
|
@ -24,7 +24,6 @@ Or if you want to access variables in the PHP you can do
|
||||
|
||||
:::php
|
||||
$config = SiteConfig::current_site_config();
|
||||
|
||||
$config->Title
|
||||
|
||||
|
||||
@ -49,9 +48,12 @@ Create a mysite/code/CustomSiteConfig.php file.
|
||||
}
|
||||
|
||||
|
||||
Then add a link to your extension in the _config.php file like below.
|
||||
Then activate your extension in your `[config.yml](/topics/configuration)` file.
|
||||
|
||||
SiteConfig::add_extension('CustomSiteConfig');
|
||||
:::yml
|
||||
SiteConfig:
|
||||
extensions:
|
||||
- CustomSiteConfig
|
||||
|
||||
|
||||
This tells SilverStripe to add the CustomSiteConfig extension to the `[api:SiteConfig]` class.
|
||||
|
@ -3,6 +3,8 @@
|
||||
## Introduction
|
||||
|
||||
SilverStripe 3 comes with a comprehensive code based configuration system.
|
||||
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.
|
||||
|
||||
Configuration can be seen as separate from other forms of variables (such as per-member or per-site settings) in the
|
||||
SilverStripe system due to three properties:
|
||||
@ -15,24 +17,23 @@ In SilverStripe 3, each class has it's configuration specified as set of named p
|
||||
values at any given time are calculated by merging several sources using rules explained below.
|
||||
These sources are as follows (in highest -> lowest priority order):
|
||||
|
||||
- Values set via a call to Config#update
|
||||
- Values set via a call to `[api:Config::update()]`
|
||||
- Values taken from YAML files in specially named directories
|
||||
- Statics set on an "extra config source" class (such as an extension) named the same as the name of the property
|
||||
(optionally)
|
||||
- Statics set on the class named the same as the name of the property
|
||||
- The parent of the class (optionally)
|
||||
|
||||
Some things to keep in mind when working with the configuration system
|
||||
Like statics, configuration values may only contain a literal or constant; neither objects nor expressions are allowed.
|
||||
|
||||
- Like statics, configuration values may only contain a literal or constant; neither objects nor expressions are
|
||||
allowed
|
||||
- The list of properties that can be set on a class is not pre-defined, and there is no way to introspect the list
|
||||
of properties or the expected type of any property
|
||||
- There is no way currently to restrict read or write access to any configuration property
|
||||
- There is no way currently to mutate or intercept read or write access to any configuration property - that is
|
||||
(for example) there is no support for getters or setters
|
||||
## Finding Configuration
|
||||
|
||||
## The merge
|
||||
Since configuration settings are just static properties on any SilverStripe class,
|
||||
there's no exhaustive list. All configurable statics are marked with a `@config` docblock
|
||||
though, so you can search for them in the codebase. The same docblock will also contain
|
||||
a description of the configuration setting.
|
||||
|
||||
## Customizing Configuration (through merging)
|
||||
|
||||
Each named class configuration property can contain either an array or a non-array value.
|
||||
If the value is an array, each value in the array may also be one of those three types
|
||||
@ -57,7 +58,7 @@ the result will be the higher priority false-ish value.
|
||||
The locations that configuration values are taken from in highest -> lowest priority order are:
|
||||
|
||||
- Any values set via a call to Config#update
|
||||
- The configuration values taken from the YAML files in _config directories (internally sorted in before / after order, where
|
||||
- The configuration values taken from the YAML files in `_config/` directories (internally sorted in before / after order, where
|
||||
the item that is latest is highest priority)
|
||||
- Any static set on an "additional static source" class (such as an extension) named the same as the name of the property
|
||||
- Any static set on the class named the same as the name of the property
|
||||
@ -69,15 +70,18 @@ They are much simpler. They consist of a list of key / value pairs. When applied
|
||||
- If the composite value is an associative array, any member of that array that matches both the key and value of any pair in the mask is removed
|
||||
- If the composite value is not an array, if that value matches any value in the mask it is removed
|
||||
|
||||
## Reading and updating configuration via the Config class
|
||||
## Reading and updating via the Config class
|
||||
|
||||
The Config class is both the primary manner of getting configuration values and one of the locations you can set
|
||||
configuration values
|
||||
configuration values.
|
||||
|
||||
Note: There is no way currently to restrict read or write access to any configuration property,
|
||||
or influence/check the values being read or written.
|
||||
|
||||
### Global access
|
||||
|
||||
The first thing you need to do to use the Config class is to get the singleton instance of that class. This can be
|
||||
done by calling the static method Config::inst(), like so:
|
||||
done by calling the static method `[api:Config::inst()]`, like so:
|
||||
|
||||
$config = Config::inst();
|
||||
|
||||
@ -92,18 +96,18 @@ Note that there is no "set" method. Because of the merge, it is not possible to
|
||||
property (unless you're setting it to a true-ish literal). Update adds new values that are treated as the highest
|
||||
priority in the merge, and remove adds a merge mask that filters out values.
|
||||
|
||||
### Short-hand reading and updating configuration for instances of Object children
|
||||
### Short-hand access
|
||||
|
||||
Within any subclass of Object you can call the config() instance method to get an instance of a proxy object
|
||||
which accesses the Config class with the class parameter already set.
|
||||
|
||||
For instance, instead of writing
|
||||
For instance, instead of writing:
|
||||
|
||||
:::php
|
||||
Config::inst()->get($this->class, 'my_property');
|
||||
Config::inst()->update($this->class, 'my_other_property', 2);
|
||||
|
||||
You can write
|
||||
You can write:
|
||||
|
||||
:::php
|
||||
$this->config()->get('my_property');
|
||||
@ -112,13 +116,18 @@ You can write
|
||||
Or even shorter:
|
||||
|
||||
:::php
|
||||
$this->config()->my_property;
|
||||
$this->config()->my_other_property = 2;
|
||||
$this->config()->my_property; // getter
|
||||
$this->config()->my_other_property = 2; // setter
|
||||
|
||||
This also works statically:
|
||||
|
||||
MyClass::config()->my_property; // getter
|
||||
MyClass::config()->my_property = 2; // setter
|
||||
|
||||
## Setting configuration via YAML files
|
||||
|
||||
Each module can (in fact, should - see below for why) have a directory immediately underneath the main module
|
||||
directory called "_config".
|
||||
directory called `_config/`.
|
||||
|
||||
Inside this directory you can add yaml files that contain values for the configuration system.
|
||||
|
||||
@ -138,15 +147,12 @@ value section in the header section that immediately preceeds the value section.
|
||||
|
||||
#### Reference paths and fragment identifiers
|
||||
|
||||
Each value section has a reference path. Each path looks a little like a URL, and is of this form:
|
||||
Each value section has a reference path. Each path looks a little like a URL,
|
||||
and is of this form: `module/file#fragment`.
|
||||
|
||||
module/file#fragment
|
||||
|
||||
"module" is the name of the module this YAML file is in
|
||||
|
||||
"file" is the name of this YAML file, stripped of the extension (so for routes.yml, it would be routes)
|
||||
|
||||
"fragment" is a specified identifier. It is specified by putting a `Name: {fragment}` key / value pair into the header
|
||||
- "module" is the name of the module this YAML file is in
|
||||
- "file" is the name of this YAML file, stripped of the extension (so for routes.yml, it would be routes)
|
||||
- "fragment" is a specified identifier. It is specified by putting a `Name: {fragment}` key / value pair into the header
|
||||
section. If you don't specify a name, a random one will be assigned.
|
||||
|
||||
This reference path has no affect on the value section itself, but is how other header sections refer to this value
|
||||
@ -282,18 +288,18 @@ do not have to define a static for a property to be valid.
|
||||
## Configuration as a module marker
|
||||
|
||||
Configuration files also have a secondary sub-role. Modules are identified by the `[api:ManifestBuilder]` by the
|
||||
presence of a _config directory (or a _config.php file) as a top level item in the module directory.
|
||||
presence of a `_config/` directory (or a `_config.php` file) as a top level item in the module directory.
|
||||
|
||||
Although your module may choose not to set any configuration, it must still have a _config directory to be recognised
|
||||
as a module by the `[api:ManifestBuilder]`, which is required for features such as autoloading of classes and template
|
||||
detection to work.
|
||||
|
||||
## _config.php
|
||||
## Complex configuration through _config.php
|
||||
|
||||
In addition to the configuration system described above, each module can provide a file called _config.php
|
||||
In addition to the configuration system described above, each module can provide a file called `_config.php`
|
||||
immediately within the module top level directory.
|
||||
|
||||
These _config.php files will be included at initialisation, and are a useful way to set legacy configuration
|
||||
These `_config.php` files will be included at initialisation, and are a useful way to set legacy configuration
|
||||
or set configuration based on rules that are more complex than can be encoded in YAML files.
|
||||
|
||||
However they should generally be avoided when possible, as they slow initialisation.
|
||||
@ -301,29 +307,27 @@ However they should generally be avoided when possible, as they slow initialisat
|
||||
Please note that this is the only place where you can put in procedural code - all other functionality is wrapped in
|
||||
classes (see [common-problems](/installation/common-problems)).
|
||||
|
||||
## Constants
|
||||
|
||||
Some constants are user-defineable within *_ss_environment.php*.
|
||||
## Configuration through the CMS
|
||||
|
||||
## No GUI configuration
|
||||
|
||||
SilverStripe framework does not provide a method to set configuration via a web panel
|
||||
|
||||
This lack of a configuration-GUI is on purpose, as we'd like to keep developer-level options where they belong (into
|
||||
SilverStripe framework does not provide a method to set most system-level configuration via a web panel.
|
||||
This lack of a configuration GUI is on purpose, as we'd like to keep developer-level options where they belong (into
|
||||
code), without cluttering up the interface. See this core forum discussion ["The role of the
|
||||
CMS"](http://www.silverstripe.org/archive/show/532) for further reasoning.
|
||||
|
||||
In addition to these principle, some settings are
|
||||
* Author-level configuration like interface language or date/time formats can be performed in the CMS "My Profile" section (`admin/myprofile`).
|
||||
* Group-related configuration like `[api:HTMLEditorField]` settings can be found in the "Security" section (`admin/security`).
|
||||
The GUI-based configuation is limited to the following:
|
||||
|
||||
* Author-level configuration like interface language or date/time formats can be performed in the CMS "My Profile" section
|
||||
* Group-related configuration like `[api:HTMLEditorField]` settings can be found in the "Security" section
|
||||
* Site-wide settings like page titles can be set (and extended) on the root tree element in the CMS "Content" section (through the [siteconfig](/reference/siteconfig) API).
|
||||
* Any configuration interfaces added by custom code, for example through `getCMSFields()`
|
||||
|
||||
## Constants and the _ss_environment.php File
|
||||
|
||||
See [environment-management](/topics/environment-management).
|
||||
|
||||
|
||||
## User-level: Member-object
|
||||
## User preferences in the `Member` class
|
||||
|
||||
All user-related preferences are stored as a property of the `[api:Member]`-class (and as a database-column in the
|
||||
*Member*-table). You can "mix in" your custom preferences by using `[api:DataObject]` for details.
|
||||
|
@ -3,10 +3,10 @@
|
||||
## Environment Types
|
||||
|
||||
Silverstripe knows three different environment-types (or "debug-levels"). Each of the levels gives you different tools
|
||||
and functionality. "dev", "test" and "live". You can either configure the environment of the site in the
|
||||
mysite/_config.php file or in your [environment configuration file](/topics/environment-management).
|
||||
and functionality. "dev", "test" and "live". You can either configure the environment of the site in your
|
||||
[config.yml file](/topics/configuration) or in your [environment configuration file](/topics/environment-management).
|
||||
|
||||
The definition of setting an environment in your `mysite/_config/config.yml` looks like
|
||||
The definition of setting an environment in your `config.yml` looks like
|
||||
|
||||
:::yml
|
||||
Director:
|
||||
@ -17,7 +17,7 @@ The definition of setting an environment in your `mysite/_config/config.yml` loo
|
||||
When developing your websites, adding page types or installing modules you should run your site in devmode. In this mode
|
||||
you will be able to view full error backtraces and view the development tools without logging in as admin.
|
||||
|
||||
To set your site to dev mode set this in your `mysite/_config/config.yml` file
|
||||
To set your site to dev mode set this in your `config.yml` file
|
||||
|
||||
:::yml
|
||||
Director:
|
||||
@ -37,7 +37,7 @@ not need to use test mode if you do not have a staging environment or a place fo
|
||||
In this mode error messages are hidden from the user and it includes `[api:BasicAuth]` integration if you want to password
|
||||
protect the site.
|
||||
|
||||
To set your site to test mode set this in your `mysite/_config/config.yml` file
|
||||
To set your site to test mode set this in your `config.yml` file
|
||||
|
||||
:::yml
|
||||
Director:
|
||||
@ -45,7 +45,7 @@ To set your site to test mode set this in your `mysite/_config/config.yml` file
|
||||
|
||||
|
||||
A common situation is to enable password protected site viewing on your test site only.
|
||||
You can enable that but adding this to your `mysite/_config/config.yml` file:
|
||||
You can enable that but adding this to your `config.yml` file:
|
||||
|
||||
:::yml
|
||||
---
|
||||
@ -61,7 +61,7 @@ Live sites should always run in live mode. Error messages are suppressed from th
|
||||
to email the developers. This enables near real time reporting of any fatal errors or warnings on the site and can help
|
||||
find any bugs users run into.
|
||||
|
||||
To set your site to live mode set this in your `mysite/_config/config.yml` file
|
||||
To set your site to live mode set this in your `config.yml` file
|
||||
|
||||
:::yml
|
||||
Director:
|
||||
|
@ -21,6 +21,7 @@ existing modules or the directories lists in "Core Structure".
|
||||
| Directory | Description |
|
||||
| --------- | ----------- |
|
||||
| `<mysite>/` | This directory contains all of your code that defines your website. |
|
||||
| `<mysite>/_config` | YAML configuration specific to your application |
|
||||
| `<mysite>/code` | PHP code for model and controller (subdirectories are optional) |
|
||||
| `<mysite>/templates` | HTML [templates](templates) with *.ss-extension |
|
||||
| `<mysite>/css ` | CSS files |
|
||||
@ -38,7 +39,7 @@ See [themes](/topics/themes)
|
||||
|
||||
## Module Structure {#module_structure}
|
||||
|
||||
Modules are currently top-level folders that need to have a *_config.php*-file present.
|
||||
Modules are currently top-level folders that have a `_config.php` file or a `_config/` directory present.
|
||||
They should follow the same conventions as posed in "Custom Site Structure"
|
||||
|
||||
Example Forum:
|
||||
|
@ -35,7 +35,7 @@ Create a new file, `~/Sites/_ss_environment.php`. Put the following content in
|
||||
define('SS_DEFAULT_ADMIN_PASSWORD', 'password');
|
||||
|
||||
|
||||
Now, edit each of your site's configuration file, `~/Sites/(projectname)/mysite/_config.php`. Delete all mention
|
||||
Now, edit each of your site's configuration file, usually `mysite/_config.php`. Delete all mention
|
||||
of `$databaseConfig` and `Director::set_dev_servers`, and instead make sure that you file starts like this.
|
||||
|
||||
:::php
|
||||
|
@ -54,7 +54,7 @@ You can indicate a log file relative to the site root. The named file will have
|
||||
(an encoded file containing backtraces and things) will go to a file of a similar name, but with the suffix ".full"
|
||||
added.
|
||||
|
||||
`<mysite>/_config.php`:
|
||||
`mysite/_config.php`:
|
||||
|
||||
:::php
|
||||
// log errors and warnings
|
||||
@ -67,19 +67,18 @@ added.
|
||||
In addition to SilverStripe-integrated logging, it is adviseable to fall back to PHPs native logging functionality. A
|
||||
script might terminate before it reaches the SilverStripe errorhandling, for example in the case of a fatal error.
|
||||
|
||||
`<mysite>/_config.php`:
|
||||
`mysite/_config.php`:
|
||||
|
||||
:::php
|
||||
ini_set("log_errors", "On");
|
||||
ini_set("error_log", "/my/logfile/path");
|
||||
|
||||
|
||||
|
||||
## Email Logs
|
||||
|
||||
You can send both fatal errors and warnings in your code to a specified email-address.
|
||||
|
||||
`<mysite>/_config.php`:
|
||||
`mysite/_config.php`:
|
||||
|
||||
:::php
|
||||
// log errors and warnings
|
||||
|
@ -5,7 +5,7 @@ It is where most documentation should live, and is the natural "second step" aft
|
||||
|
||||
* [Access Control and Page Security](access-control): Restricting access and setting up permissions on your website
|
||||
* [Command line Usage](commandline): Calling controllers via the command line interface using `sake`
|
||||
* [Configuring your website](configuration): How to configure the `_config.php` file
|
||||
* [Configuration](configuration): Influence behaviour through PHP and YAML configuration
|
||||
* [Controller](controller): The intermediate layer between your templates and the data model
|
||||
* [Data Types](data-types): Types that properties on `DataObject` can have (e.g. `Text` or `Date`)
|
||||
* [Datamodel](datamodel): How we use an "Object-relational model" to expose database information in a useful way
|
||||
|
@ -8,7 +8,7 @@ templating for any initial installation. If you're wanting to add generic functi
|
||||
project, like a forum, an ecommerce package or a blog you can do it like this;
|
||||
|
||||
1. Create another directory at the root level (same level as "framework" and "cms")
|
||||
2. You must create an _config.php inside your module directory, else SilverStripe will not include it
|
||||
2. You must create an `_config/` directory inside your module directory, else SilverStripe will not include it
|
||||
3. Inside your module directory, follow our [directory structure guidelines](/topics/directory-structure#module_structure)
|
||||
|
||||
## Tips
|
||||
|
@ -7,8 +7,9 @@ directory. In a default SilverStripe download, even resources in 'framework' an
|
||||
same as every other module.
|
||||
|
||||
SilverStripe's `[api:ManifestBuilder]` will find any class, css or template files anywhere under the site's main
|
||||
directory. The _config.php file in the module directory can be used to define director rules, calls to
|
||||
Object::useCustomClass(), and the like. So, by unpacking a module into site's main directory and viewing the site with
|
||||
directory. The `_config.php` file in the module directory as well as the [_config/*.yml files](/topics/configuration)
|
||||
can be used to define director rules, add
|
||||
extensions, etc. So, by unpacking a module into site's main directory and viewing the site with
|
||||
?flush=1 on the end of the URL, all the module's new behaviour will be incorporated to your site:
|
||||
|
||||
* You can create subclasses of base classes such as SiteTree to extend behaviour.
|
||||
@ -85,7 +86,7 @@ Github also provides archive downloads which are generated automatically for eve
|
||||
The main folder extracted from the archive
|
||||
might contain the version number or additional "container" folders above the actual module
|
||||
codebase. You need to make sure the folder name is the correct name of the module
|
||||
(e.g. "blog/" rather than "silverstripe-blog/"). This folder should contain a `_config.php` file.
|
||||
(e.g. "blog/" rather than "silverstripe-blog/"). This folder should contain a `_config/` directory.
|
||||
While the module might register and operate in other structures,
|
||||
paths to static files such as CSS or JavaScript won't work.
|
||||
</div>
|
||||
|
@ -25,8 +25,8 @@ functionality. It is usually added through the `[api:DataObject->getCMSFields()]
|
||||
|
||||
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 `_config.php`
|
||||
files in the framework (and the `cms` module in case you've got that installed).
|
||||
The class comes with its own defaults, which are extended through [configuration files](/topics/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 then set the currently active config using `set_active()`.
|
||||
By default, a config named 'cms' is used in any field created throughout the CMS interface.
|
||||
|
@ -14,7 +14,7 @@ as a .tar.gz file.
|
||||
|
||||
1. Unpack the contents of the zip file into the `themes` directory in your SilverStripe installation.
|
||||
2. Change the site to the theme. You can do this either by:
|
||||
- Altering the `SSViewer.theme` setting in your `mysite/_config/config.yml`
|
||||
- Altering the `SSViewer.theme` setting in your `[config.yml](/topics/configuration)`
|
||||
- changing the theme in the Site Configuration panel in the CMS
|
||||
3. Visit your homepage with ?flush=all appended to the URL. `http://yoursite.com?flush=all`
|
||||
|
||||
|
@ -20,11 +20,12 @@ It's a `[api:DataExtension]`, which allow it to be applied to any `[api:DataObje
|
||||
|
||||
Adding versioned to your `DataObject` subclass works the same as any other extension.
|
||||
It accepts two or more arguments denoting the different "stages",
|
||||
which map to different database tables.
|
||||
which map to different database tables. Add the following to your [configuration file](/topics/configuration):
|
||||
|
||||
:::php
|
||||
// mysite/_config.php
|
||||
MyRecord::add_extension('Versioned("Stage","Live")');
|
||||
:::yml
|
||||
MyRecord:
|
||||
extensions:
|
||||
- Versioned("Stage","Live")
|
||||
|
||||
Note: The extension is automatically applied to `SiteTree` class.
|
||||
|
||||
|
@ -1765,7 +1765,7 @@ class i18n extends Object implements TemplateGlobalProvider {
|
||||
* @return Name of the locale
|
||||
*/
|
||||
public static function get_locale_name($code) {
|
||||
$langs = self::get_locale_list();
|
||||
$langs = self::config()->all_locales;
|
||||
return isset($langs[$code]) ? $langs[$code] : false;
|
||||
}
|
||||
|
||||
|
@ -66,7 +66,7 @@ class Currency extends Decimal {
|
||||
|
||||
public static function setCurrencySymbol($value) {
|
||||
Deprecation::notice('3.2', 'Use the "Currency.currency_symbol" config setting instead');
|
||||
$this->config()->currency_symbol = $value;
|
||||
Currency::config()->currency_symbol = $value;
|
||||
}
|
||||
}
|
||||
|
||||
|
@ -43,7 +43,7 @@ class BBCodeParser extends TextParser {
|
||||
if(!BBCodeParser::$smilies_location) {
|
||||
return FRAMEWORK_DIR . '/images/smilies';
|
||||
}
|
||||
return $this->config()->smilies_location;
|
||||
return static::config()->smilies_location;
|
||||
}
|
||||
|
||||
/**
|
||||
@ -51,7 +51,7 @@ class BBCodeParser extends TextParser {
|
||||
*/
|
||||
public static function set_icon_folder($path) {
|
||||
Deprecation::notice('3.2', 'Use the "BBCodeParser.smilies_location" config setting instead');
|
||||
$this->config()->smilies_location = $path;
|
||||
static::config()->smilies_location = $path;
|
||||
}
|
||||
|
||||
/**
|
||||
@ -59,7 +59,7 @@ class BBCodeParser extends TextParser {
|
||||
*/
|
||||
public static function autolinkUrls() {
|
||||
Deprecation::notice('3.2', 'Use the "BBCodeParser.autolink_urls" config setting instead');
|
||||
return $this->config()->autolink_urls;
|
||||
return static::config()->autolink_urls;
|
||||
}
|
||||
|
||||
/**
|
||||
@ -67,7 +67,7 @@ class BBCodeParser extends TextParser {
|
||||
*/
|
||||
public static function disable_autolink_urls($autolink = false) {
|
||||
Deprecation::notice('3.2', 'Use the "BBCodeParser.autolink_urls" config setting instead');
|
||||
$this->config()->autolink_urls = $autolink;
|
||||
static::config()->autolink_urls = $autolink;
|
||||
}
|
||||
|
||||
/**
|
||||
@ -75,7 +75,7 @@ class BBCodeParser extends TextParser {
|
||||
*/
|
||||
public static function smiliesAllowed() {
|
||||
Deprecation::notice('3.2', 'Use the "BBCodeParser.allow_smilies" config setting instead');
|
||||
return $this->config()->allow_smilies;
|
||||
return static::config()->allow_smilies;
|
||||
}
|
||||
|
||||
/**
|
||||
@ -83,7 +83,7 @@ class BBCodeParser extends TextParser {
|
||||
*/
|
||||
public static function enable_smilies() {
|
||||
Deprecation::notice('3.2', 'Use the "BBCodeParser.allow_smilies" config setting instead');
|
||||
$this->config()->allow_similies = true;
|
||||
static::config()->allow_similies = true;
|
||||
}
|
||||
|
||||
|
||||
|
@ -8,12 +8,12 @@
|
||||
class Group extends DataObject {
|
||||
|
||||
private static $db = array(
|
||||
"Title" => "Varchar",
|
||||
"Title" => "Varchar(255)",
|
||||
"Description" => "Text",
|
||||
"Code" => "Varchar",
|
||||
"Code" => "Varchar(255)",
|
||||
"Locked" => "Boolean",
|
||||
"Sort" => "Int",
|
||||
"HtmlEditorConfig" => "Varchar"
|
||||
"HtmlEditorConfig" => "Text"
|
||||
);
|
||||
|
||||
private static $has_one = array(
|
||||
|
Loading…
Reference in New Issue
Block a user