mirror of
https://github.com/silverstripe/silverstripe-framework
synced 2024-10-22 12:05:37 +00:00
Merge pull request #5023 from SpiritLevel/3.0
DOCS 3.0 : re-introduce api: tags since api: parser now fixed
This commit is contained in:
Damian Mooyman
commit
2291434a23
@ -22,7 +22,7 @@ js/css changes.
|
||||
// after
|
||||
<div class="Actions">
|
||||
|
||||
See http://open.silverstripe.com/changeset/43562
|
||||
See `http://open.silverstripe.com/changeset/43562`
|
||||
|
||||
### Form Security Token
|
||||
|
||||
@ -142,9 +142,9 @@ Sitemap.php
|
||||
* Translatable, for multilingual content
|
||||
* New third party libraries
|
||||
* PHP OpenID (http://openidenabled.com/php-openid/)
|
||||
* Browscap (http://garetjax.info/projects/browscap/)
|
||||
* Browscap (http://browscap.org/)
|
||||
* Plotr (http://www.solutoire.com/plotr/)
|
||||
* SWFUpload (http://profandesign.se/swfupload/)
|
||||
* SWFUpload (`http://profandesign.se/`)
|
||||
* Improved classes
|
||||
* CalendarDateField
|
||||
* Refactored part of Field() into HTMLField() so it can be used in PopupDateTimeField
|
||||
|
||||
@ -21,7 +21,7 @@ Basic auth isn't enabled by default on test sites. If you need this, put this i
|
||||
### /silverstripe and /cms no longer work as aliases to /admin
|
||||
|
||||
Removed certain URL aliases for CMS interface to allow for common page URLs like "silverstripe" or "cms". Please use
|
||||
/admin as the main URL to access the CMS. See http://open.silverstripe.com/ticket/3267
|
||||
/admin as the main URL to access the CMS. See `http://open.silverstripe.com/ticket/3267`
|
||||
|
||||
### SiteTree Access tab now lets you select multiple groups
|
||||
|
||||
@ -29,7 +29,7 @@ In order to do this, `SiteTree->ViewersGroup` and `SiteTree->EditorsGroup` have
|
||||
to many_many relations.
|
||||
|
||||
Your group-assignements for "Who can view this page" and "Who can edit this page" should be automatically migrated upon
|
||||
calling `dev/build`. See [#2847](http://open.silverstripe.com/ticket/2847)
|
||||
calling `dev/build`. See `[#2847](http://open.silverstripe.com/ticket/2847)`
|
||||
|
||||
### Newsletter moved into new module
|
||||
|
||||
@ -47,18 +47,18 @@ If you **don't** require the functionality, it's safe to delete these database t
|
||||
#### auth_openid removed from default installation
|
||||
|
||||
The auth_openid module has been removed from default installation. Please install the module separately from
|
||||
[silverstripe.org](http://silverstripe.org/auth-openid-module/)
|
||||
`[silverstripe.org](http://silverstripe.org/auth-openid-module/)`
|
||||
|
||||
### GenericDataAdmin and RelatedDataEditor moved into new module
|
||||
|
||||
GenericDataAdmin functionality has been moved into its own module called
|
||||
|
||||
**[genericdataadmin](modules/genericdataadmin)**. If you were previously using this as a feature out of the box with
|
||||
**[genericdataadmin](https://github.com/silverstripe-labs/silverstripe-genericdataadmin)**. If you were previously using this as a feature out of the box with
|
||||
SilverStripe, then you will need to download this module to continue using it.
|
||||
|
||||
### User Defined Form moved into new module
|
||||
|
||||
User Defined Form has been moved into its own module called **[userforms](modules/userforms)**. If you were previously
|
||||
User Defined Form has been moved into its own module called **[userforms](http://addons.silverstripe.org/add-ons/silverstripe/userforms)**. If you were previously
|
||||
using this as a feature out of the box with SilverStripe, then you will need to download the userforms module to
|
||||
continue using it.
|
||||
|
||||
@ -86,8 +86,7 @@ If you **don't** require the User Defined Form functionality, it's safe to delet
|
||||
|
||||
### PostBackup
|
||||
|
||||
PostBackup has been moved into a module. See [postbackup
|
||||
module](http://open.silverstripe.com/browser/modules/postbackup/trunk).
|
||||
PostBackup has been moved into a module. See `[postbackup module](http://open.silverstripe.com/browser/modules/postbackup/trunk)`.
|
||||
|
||||
### /db/build/?flush=1 is now called /dev/build
|
||||
|
||||
@ -105,8 +104,8 @@ Flushing the manifest with `?flush=1` doesn't need to be explicitly added.
|
||||
* Removed Debug::warning(), use user_error("your message", E_USER_WARNING)
|
||||
* Removed SiteTree->canView_page(), Use instance-specific SiteTree->canView() instead by checking for `$this->ID`.
|
||||
* Deprecated URL parameter ?buildmanifest=1 (please use ?flush=1)
|
||||
* i18ntextcollector is executed from a new URL. Use http://mysite.com/dev/task/i18nTextCollectorTask instead of
|
||||
http://mysite.com/i18ntextcollector
|
||||
* i18ntextcollector is executed from a new URL. Use `http://mysite.com/dev/task/i18nTextCollectorTask` instead of
|
||||
`http://mysite.com/i18ntextcollector`
|
||||
|
||||
### Director::addRules()
|
||||
|
||||
@ -134,7 +133,7 @@ To this:
|
||||
### Decorators
|
||||
|
||||
* Renamed DataObjectDecorator->extraDBFields() to extraStatics() (see
|
||||
[r65065](http://open.silverstripe.com/changeset/65065))
|
||||
`[r65065](http://open.silverstripe.com/changeset/65065)`)
|
||||
|
||||
* DataObjectDecorator->updateCMSFields() is now called from DataObject->getCMSFields(), instead of only SiteTree
|
||||
instances
|
||||
@ -162,7 +161,7 @@ FormField::performDisabledTransformation() must return new form fields, e.g., cl
|
||||
* '''$Top''' in templates has changed its behaviour; if you call $Top from inside a template that is rendered
|
||||
separately (eg, a Form template), it will point to the top element of that template execution (in this case, the Form
|
||||
object) rather than the top element of the outermost template (which would presumably be the page in question). This
|
||||
was a bug that we have fixed, but some people may rely on it. See http://open.silverstripe.com/ticket/2781
|
||||
was a bug that we have fixed, but some people may rely on it. See `http://open.silverstripe.com/ticket/2781`
|
||||
|
||||
* A `<legend>` element has been added before any `<fieldset>` in all SilverStripe forms. SearchForm.ss and Form.ss are
|
||||
where it has been added. This now validates the form HTML for W3C compliance. Please verify that your forms visually
|
||||
@ -218,7 +217,7 @@ _config.php:
|
||||
:::php
|
||||
Validator::set_javascript_validation_handler('none');
|
||||
|
||||
See http://open.silverstripe.com/changeset/69688
|
||||
See `http://open.silverstripe.com/changeset/69688`
|
||||
|
||||
|
||||
## New Features
|
||||
@ -1067,9 +1066,9 @@ See http://open.silverstripe.com/changeset/69688
|
||||
* ![rev:65827] Added error messages to flash uploader panel, to be consistent with the image uploader one
|
||||
* ![rev:65582] Using actual classname in DataObjectSet->debug()
|
||||
* ![rev:65581] Added unit tests for FieldSet->insertBefore()/insertAfter()
|
||||
* ![rev:65513] Using currently used content languages for options in the TinyMCE spellchecker (see http://open.silverstripe.com/ticket/2498#comment:2)
|
||||
* ![rev:65513] Using currently used content languages for options in the TinyMCE spellchecker (see `http://open.silverstripe.com/ticket/2498#comment:2`)
|
||||
* ![rev:65508] Added language tables for tinymce_ssbuttons Plugin, incl. German translation
|
||||
* ![rev:65495] Calling UpgradeSiteTreePermissionSchemaTask from SiteTree->requireDefaultRecords as a temporary workaround for missing migration infrastructure. This means that upgrading the schema for 2.3 can be done without manual task triggers, just the usual dev/build (see http://open.silverstripe.com/ticket/2847#comment:4)
|
||||
* ![rev:65495] Calling UpgradeSiteTreePermissionSchemaTask from SiteTree->requireDefaultRecords as a temporary workaround for missing migration infrastructure. This means that upgrading the schema for 2.3 can be done without manual task triggers, just the usual dev/build (see `http://open.silverstripe.com/ticket/2847#comment:4`)
|
||||
* ![rev:65494] Added DatabaseTest
|
||||
* ![rev:65464] Better CLI output for browsing dev/tests
|
||||
* ![rev:65463] Allowing strings instead of arrays in ModelAdmin::$managed_models to make it less error-prone for beginners
|
||||
|
||||
@ -16,7 +16,7 @@ See [2.4.6]
|
||||
### Features and Enhancements
|
||||
|
||||
* 2011-10-17 [8113e9c](https://github.com/silverstripe/sapphire/commit/8113e9c) Added SSViewer::getOption() as a logical counterpart to SSViewer::setOption() (Ingo Schommer)
|
||||
* 2011-02-07 [e2267a0](https://github.com/silverstripe/sapphire/commit/e2267a0) Added sapphire/docs (migrated from https://github.com/chillu/silverstripe-doc-restructuring) (Ingo Schommer)
|
||||
* 2011-02-07 [e2267a0](https://github.com/silverstripe/sapphire/commit/e2267a0) Added sapphire/docs (migrated from `https://github.com/chillu/silverstripe-doc-restructuring`) (Ingo Schommer)
|
||||
|
||||
### Bugfixes
|
||||
|
||||
@ -34,4 +34,4 @@ See [2.4.6]
|
||||
### Other
|
||||
|
||||
* 2011-10-18 [fbe8b7b](https://github.com/silverstripe/sapphire/commit/fbe8b7b) MINO Switching 'rewriteHashlinks' sanitization from Convert::raw2att() to strip_tags() to make the resulting PHP more portable when mode is set to 'php' (Ingo Schommer)
|
||||
* 2011-09-15 [ca78784](https://github.com/silverstripe/sapphire/commit/ca78784) SECURITY Backporting MySQLDatabase->addslashes() to use mysql_real_escape_string() instead of the non-multibyte-safe addslashes() PHP function, and using it in Convert::raw2sql() (Ingo Schommer)
|
||||
* 2011-09-15 [ca78784](https://github.com/silverstripe/sapphire/commit/ca78784) SECURITY Backporting MySQLDatabase->addslashes() to use mysql_real_escape_string() instead of the non-multibyte-safe addslashes() PHP function, and using it in Convert::raw2sql() (Ingo Schommer)
|
||||
|
||||
@ -25,7 +25,7 @@ They need to be changed to the following (respectively):
|
||||
|
||||
Here's an example of how the default Blackcandy theme was changed:
|
||||
|
||||
[http://open.silverstripe.org/changeset/75917/themes/blackcandy/branches/2.3/blackcandy/css/typography.css](http://open.silverstripe.org/changeset/75917/themes/blackcandy/branches/2.3/blackcandy/css/typography.css)
|
||||
`[http://open.silverstripe.org/changeset/75917/themes/blackcandy/branches/2.3/blackcandy/css/typography.css](http://open.silverstripe.org/changeset/75917/themes/blackcandy/branches/2.3/blackcandy/css/typography.css)`
|
||||
|
||||
#### Translatable Datamodel
|
||||
|
||||
@ -46,7 +46,7 @@ and
|
||||
It is no longer possible to exclude certain properties on a DataObject from being translatable. This is a limitation by
|
||||
our database schema choice. See
|
||||
[discussion](http://groups.google.com/group/silverstripe-dev/browse_thread/thread/2b3df26361d17119/be8f9f08a797bd43?lnk=gst&q=translatable#be8f9f08a797bd43)
|
||||
on our mailinglist and ticket [#3722](http://open.silverstripe.com/ticket/3722).
|
||||
on our mailinglist and ticket `[#3722](http://open.silverstripe.com/ticket/3722)`.
|
||||
|
||||
#### Translatable URLs
|
||||
|
||||
|
||||
@ -63,25 +63,25 @@ are going to be removed for the next major release.
|
||||
| Class name | | Comment |
|
||||
| ---------- | | ------- |
|
||||
| `AjaxFormAction` | | |
|
||||
| `BankAccountField` | | moved to [formfields_nz](http://open.silverstripe.org/browser/modules/formfields_nz) module |
|
||||
| `CalendarDateField` | | use `DateField` with ''setConfig('showcalendar', true)'', moved to [legacydatetimefields](http://open.silverstripe.org/browser/modules/legacydatetimefields/trunk) module |
|
||||
| `CompositeDateField`, `DMYDateField` | | use `DateField` with ''setConfig('dmyfields', true)'', moved to [legacydatetimefields](http://open.silverstripe.org/browser/modules/legacydatetimefields/trunk) module |
|
||||
| `BankAccountField` | | moved to `[formfields_nz](http://open.silverstripe.org/browser/modules/formfields_nz)` module |
|
||||
| `CalendarDateField` | | use `DateField` with ''setConfig('showcalendar', true)'', moved to `[legacydatetimefields](http://open.silverstripe.org/browser/modules/legacydatetimefields/trunk)` module |
|
||||
| `CompositeDateField`, `DMYDateField` | | use `DateField` with ''setConfig('dmyfields', true)'', moved to `[legacydatetimefields](http://open.silverstripe.org/browser/modules/legacydatetimefields/trunk)` module |
|
||||
| `ConfirmedFormAction` | | |
|
||||
| `DMYDateField` | | |
|
||||
| `DropdownTimeField` | | use `TimeField` with ''setConfig('showdropdown', true)'', moved to [legacydatetimefields](http://open.silverstripe.org/browser/modules/legacydatetimefields/trunk) module |
|
||||
| `DropdownTimeField` | | use `TimeField` with ''setConfig('showdropdown', true)'', moved to `[legacydatetimefields](http://open.silverstripe.org/browser/modules/legacydatetimefields/trunk)` module |
|
||||
| `Email_Template` | | use `Email` instead |
|
||||
| `GhostPage` | | |
|
||||
| `GSTNumberField` | | moved to [formfields_nz](http://open.silverstripe.org/browser/modules/formfields_nz) module |
|
||||
| `GSTNumberField` | | moved to `[formfields_nz](http://open.silverstripe.org/browser/modules/formfields_nz)` module |
|
||||
| `HiddenFieldGroup` | | |
|
||||
| `PDODatabase` | | |
|
||||
| `PermissionDropdownField` | | |
|
||||
| `PopupDateTimeField` | | use `DatetimeField`, moved to [legacydatetimefields](http://open.silverstripe.org/browser/modules/legacydatetimefields/trunk) module |
|
||||
| `PopupDateTimeField` | | use `DatetimeField`, moved to `[legacydatetimefields](http://open.silverstripe.org/browser/modules/legacydatetimefields/trunk)` module |
|
||||
| `ReportField` | | |
|
||||
| `TypeDropdown` | | |
|
||||
|
||||
|
||||
Some date/time field implementations were completely refactored, and their old implementations moved to the
|
||||
[legacydatetimefields](http://open.silverstripe.org/browser/modules/legacydatetimefields/trunk) module:
|
||||
`[legacydatetimefields](http://open.silverstripe.org/browser/modules/legacydatetimefields/trunk)` module:
|
||||
|
||||
| Class name | | Comment |
|
||||
| ---------- | |------- |
|
||||
@ -124,8 +124,7 @@ still contained within the `ClassName.php'' file (no `SS_` prefix)
|
||||
### Nested URLs enabled by default
|
||||
|
||||
When using our installer, the "nested URLs" feature will be enabled by default by a setting in *mysite/_config.php* (see
|
||||
[blog
|
||||
post](http://www.silverstripe.org/preview-of-silverstripe-2-4-hierarchical-urls-a-developer-community-contribution/)).
|
||||
[blog post](https://www.silverstripe.org/blog/preview-of-silverstripe-2-4-hierarchical-urls-a-developer-community-contribution/).
|
||||
You can enable it manually for existing websites. Existing URLs will automatically change to the nested format without
|
||||
republication (your old URLs should redirect automatically).
|
||||
|
||||
@ -160,7 +159,7 @@ completely drop a database.
|
||||
### Registering reports through SS_Report::register()
|
||||
|
||||
Removed `ReportAdmin->getReportClassNames()` in favour of `SS_Report::register()` to add custom reports to the CMS
|
||||
(see [r98175](http://open.silverstripe.org/changeset/98175), [r98215](http://open.silverstripe.org/changeset/98215))
|
||||
(see `[r98175](http://open.silverstripe.org/changeset/98175)`, `[r98215](http://open.silverstripe.org/changeset/98215)`)
|
||||
|
||||
:::php
|
||||
// in your _config file
|
||||
@ -228,7 +227,7 @@ TinyMCE entities back into UTF8 for database storage.
|
||||
The MySQL character set for SilverStripe used to be the database default (often "latin1", sometimes "utf8"). While all
|
||||
textual database columns created by SilverStripe have been storing their content as "utf8" already in earlier releases,
|
||||
MySQL fulltext search might not return the desired results with special characters (see
|
||||
[#3582](http://open.silverstripe.org/ticket/3582)).
|
||||
`[#3582](http://open.silverstripe.org/ticket/3582)`).
|
||||
|
||||
For new installations with a MySQL database backend, this will be set automatically to "utf8" by the installer in
|
||||
|
||||
@ -432,7 +431,7 @@ from the EditableFormField table.
|
||||
* [rev:96792] Added new onRenameLinkAsset() handler to static publishing for better link rewriting. (from r89014)
|
||||
* [rev:96778] Files and images section warns if you are deleting a file that is linked to
|
||||
* [rev:96752] Recognise HTTP_X_FORWARDED_HOST header and use that in place of HTTP_HOST (from r93148)
|
||||
* [rev:96668] Change to TreeDropdownField, giving it filtering behaviour as described in ticket http://open.silverstripe.org/ticket/3007 . Its disabled by default for legacy compatibility, but enabled for HtmlEditorField so that link editor is filterable for local links, via an extra boolean parameter on TreeDowndownField.
|
||||
* [rev:96668] Change to TreeDropdownField, giving it filtering behaviour as described in ticket `http://open.silverstripe.org/ticket/3007` . Its disabled by default for legacy compatibility, but enabled for HtmlEditorField so that link editor is filterable for local links, via an extra boolean parameter on TreeDowndownField.
|
||||
* [rev:96440] Add onLoad callback handler CMSLoadFunctions
|
||||
* [rev:96049] Added Date::Rfc3339() for returning an RFC 3339 valid date format (from r96010)
|
||||
* [rev:95418] added delete all link to page comments. Patch via #4427. Thanks walec51
|
||||
@ -858,4 +857,4 @@ from the EditableFormField table.
|
||||
* [rev:98944] testing framework needs to be reset to a clean state after each test: now also nested urls and redirection state will be reverted
|
||||
* [rev:98897] Fixed strpos() check in BASE_URL check
|
||||
* [rev:98895] Installer now opens if mod_rewrite is disabled. Using index.php instead of rewriting the URL didn't quite work with the new BASE_URL, so we need to take this case into account as well
|
||||
* [rev:98869]
|
||||
* [rev:98869]
|
||||
|
||||
@ -15,12 +15,12 @@
|
||||
|
||||
## Upgrading
|
||||
|
||||
See [API Changes](http://open.silverstripe.org/wiki/ChangeLog/2.4.1-rc1?version=2#APIChanges).
|
||||
See `[API Changes](http://open.silverstripe.org/wiki/ChangeLog/2.4.1-rc1?version=2#APIChanges)`.
|
||||
### Security: File->setName() and File->Filename handling
|
||||
|
||||
Setting properties on *File* and *Image* are not reflected on the filesystem until *write()* is called. This was a
|
||||
necessary change to fix a security vulnerability around File->setName() and file extension validation. This
|
||||
vulnerability requires a user to be logged-in to the CMS (see [#5693](http://open.silverstripe.org/ticket/5693)).
|
||||
vulnerability requires a user to be logged-in to the CMS (see `[#5693](http://open.silverstripe.org/ticket/5693)`).
|
||||
|
||||
This means that CMS users with access to "Files & Images" can no longer rename uploaded files to invalid extensions in
|
||||
2.4.1. In SilverStripe 2.3.8, this restriction only applies when *AssetAdmin::$apply_restrictions_to_admin* is set to
|
||||
@ -79,7 +79,7 @@ modules and folders you might have created in your own project.
|
||||
|
||||
Fixed password encryption when saving members through the "Add Member" dialog in the "Security" admin. The saving
|
||||
process was disregarding password encyrption and saving them as plaintext
|
||||
([#5772](http://open.silverstripe.org/ticket/5772)). The issue was introduced in 2.4.0 - if you have created any new
|
||||
(`[#5772](http://open.silverstripe.org/ticket/5772)`). The issue was introduced in 2.4.0 - if you have created any new
|
||||
members through "Add Member" since then (not the inline member table), please re-encrypt all existing passwords using
|
||||
this task:
|
||||
|
||||
@ -98,8 +98,8 @@ Example: Setting German date formats in *mysite/_config.php*:
|
||||
i18n::set_time_format('HH:mm');
|
||||
|
||||
|
||||
Please note that these form fields use [ISO date
|
||||
format](http://framework.zend.com/manual/en/zend.date.constants.html#zend.date.constants.selfdefinedformats), not PHP's
|
||||
Please note that these form fields use
|
||||
[ISO date format](http://framework.zend.com/manual/1.12/en/zend.date.constants.html#zend.date.constants.selfdefinedformats), not PHP's
|
||||
built-in [date()](http://nz.php.net/manual/en/function.date.php).
|
||||
|
||||
To set the locale and date/time formats for all existing members, use the following SQL (adjust to your preferred
|
||||
@ -119,7 +119,7 @@ The new behaviour has three states:
|
||||
* NULL: Don't affect the outcome
|
||||
|
||||
To clarify: Leaving existing decorators unchanged might mean that you allow actions that were previously denied (See
|
||||
[r104669](http://open.silverstripe.org/changeset/104669)).
|
||||
`[r104669](http://open.silverstripe.org/changeset/104669)`).
|
||||
|
||||
// In mysite/_config.php
|
||||
:::php
|
||||
@ -154,7 +154,7 @@ To clarify: Leaving existing decorators unchanged might mean that you allow acti
|
||||
|
||||
This feature was disabled for a while, and has now been removed from the source tree as well. Please please use
|
||||
thirdparty modules instead, e.g. "[silverstripe-pixlr](http://github.com/nyeholt/silverstripe-pixlr)"
|
||||
([r104987](http://open.silverstripe.org/changeset/104987)).
|
||||
(`[r104987](http://open.silverstripe.org/changeset/104987)`).
|
||||
|
||||
### URL Transliteration
|
||||
|
||||
@ -494,4 +494,4 @@ existing pages when their title is changed.
|
||||
* [rev:104667] Added explicit bash handler to sake
|
||||
* [rev:104442] Multi-use redemption page created
|
||||
|
||||
<code>./sscreatechangelog --version 2.4.1 --branch branches/2.4 --stopbranch tags/2.4.0</code>
|
||||
<code>./sscreatechangelog --version 2.4.1 --branch branches/2.4 --stopbranch tags/2.4.0</code>
|
||||
|
||||
@ -16,7 +16,7 @@ Your development environment, or production web host may be running PHP as FastC
|
||||
there is a regression in 2.4.3 which will break your site. There are two ways to resolve this problem:
|
||||
|
||||
- Don't upgrade to 2.4.3 for now, until 2.4.4 is released
|
||||
- Patch the assets/.htaccess file like this: http://open.silverstripe.org/changeset/113809
|
||||
- Patch the assets/.htaccess file like this: `http://open.silverstripe.org/changeset/113809`
|
||||
|
||||
This does **NOT** affect IIS, or other web servers that don't understand .htaccess files.
|
||||
|
||||
@ -26,8 +26,8 @@ your site to see the environment information.
|
||||
|
||||
Forum references of where the community have had issues:
|
||||
|
||||
* http://silverstripe.org/installing-silverstripe/show/14878
|
||||
* http://www.silverstripe.org/general-questions/show/14861
|
||||
* http://www.silverstripe.org/community/forums/general-questions/show/14878
|
||||
* http://www.silverstripe.org/community/forums/general-questions/show/14861
|
||||
|
||||
### Important: Add manual request forgery protection to destructive controller actions
|
||||
|
||||
@ -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 [api: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
|
||||
[api:TableListField] or
|
||||
[api:ComplexTableField] subclasses and any
|
||||
[api: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.
|
||||
|
||||
@ -347,4 +347,4 @@ You can manually enable security tokens, either globally or for a specific form.
|
||||
* [rev:111040] API-CHANGE: remove include which is not required.
|
||||
* [rev:111038] ENHACENEMENT: Change behaviour of the !MenufestBuilder to use spl_autoload_register instead of traditional __autoload.
|
||||
|
||||
<code>sscreatechangelog --version 2.4.3 --branch branches/2.4 --stopbranch tags/2.4.2</code>
|
||||
<code>sscreatechangelog --version 2.4.3 --branch branches/2.4 --stopbranch tags/2.4.2</code>
|
||||
|
||||
@ -20,7 +20,7 @@ There is a bug in 2.4.4 which breaks open_basedir restriction.
|
||||
The issue has been fixed in the development 2.4 branch, but you'll need to patch your existing copy of SilverStripe
|
||||
2.4.4 if this affects you. The error usually occurs when you try logging into the CMS.
|
||||
|
||||
It can be fixed by patching your working copy with this change: http://open.silverstripe.org/changeset/115314
|
||||
It can be fixed by patching your working copy with this change: `http://open.silverstripe.org/changeset/115314`
|
||||
|
||||
### Security: SQL information disclosure in MySQLDatabase
|
||||
|
||||
@ -47,8 +47,8 @@ Andrew Lord, Nathaniel McHugh
|
||||
|
||||
#### Patches
|
||||
|
||||
* trunk: http://open.silverstripe.org/changeset/114782
|
||||
* 2.4: http://open.silverstripe.org/changeset/114783
|
||||
* trunk: `http://open.silverstripe.org/changeset/114782`
|
||||
* 2.4: `http://open.silverstripe.org/changeset/114783`
|
||||
|
||||
|
||||
### Security: XSS in controller handling for missing actions
|
||||
@ -85,8 +85,8 @@ Tim Suter, Andrew Horton (http://security-assessment.com)
|
||||
|
||||
#### Patches
|
||||
|
||||
* trunk: http://open.silverstripe.org/changeset/114444
|
||||
* 2.4: http://open.silverstripe.org/changeset/114751
|
||||
* trunk: `http://open.silverstripe.org/changeset/114444`
|
||||
* 2.4: `http://open.silverstripe.org/changeset/114751`
|
||||
|
||||
|
||||
### Security: SQL injection with Translatable extension enabled
|
||||
@ -118,9 +118,9 @@ Pavol Ondras
|
||||
|
||||
#### Patches
|
||||
|
||||
* trunk: http://open.silverstripe.org/changeset/114515
|
||||
* 2.4: http://open.silverstripe.org/changeset/114516
|
||||
* 2.3: http://open.silverstripe.org/changeset/114517
|
||||
* trunk: `http://open.silverstripe.org/changeset/114515`
|
||||
* 2.4: `http://open.silverstripe.org/changeset/114516`
|
||||
* 2.3: `http://open.silverstripe.org/changeset/114517`
|
||||
|
||||
|
||||
### Security: Version number information disclosure
|
||||
@ -134,8 +134,8 @@ The files are:
|
||||
sapphire/silverstripe_version
|
||||
cms/silverstripe_version
|
||||
|
||||
See http://open.silverstripe.org/ticket/5031
|
||||
See http://secunia.com/advisories/42346/
|
||||
See `http://open.silverstripe.org/ticket/5031`
|
||||
See `http://secunia.com/advisories/42346/`
|
||||
|
||||
#### Solution
|
||||
|
||||
@ -151,9 +151,9 @@ Robert Mac Neil
|
||||
|
||||
#### Patches
|
||||
|
||||
* trunk: http://open.silverstripe.org/changeset/114774 http://open.silverstripe.org/changeset/114770
|
||||
* 2.4: http://open.silverstripe.org/changeset/114774 http://open.silverstripe.org/changeset/114771
|
||||
* 2.3: http://open.silverstripe.org/changeset/114776 http://open.silverstripe.org/changeset/114772
|
||||
* trunk: `http://open.silverstripe.org/changeset/114774 http://open.silverstripe.org/changeset/114770`
|
||||
* 2.4: `http://open.silverstripe.org/changeset/114774 http://open.silverstripe.org/changeset/114771`
|
||||
* 2.3: `http://open.silverstripe.org/changeset/114776 http://open.silverstripe.org/changeset/114772`
|
||||
|
||||
|
||||
### Security: Weak entropy in tokens for CSRF protection, autologin, "forgot password" emails and password salts
|
||||
@ -185,13 +185,13 @@ Andrew Horton (http://security-assessment.com)
|
||||
|
||||
#### Patches
|
||||
|
||||
* trunk: http://open.silverstripe.org/changeset/114497 http://open.silverstripe.org/changeset/114498
|
||||
http://open.silverstripe.org/changeset/114503 http://open.silverstripe.org/changeset/114504
|
||||
http://open.silverstripe.org/changeset/114505
|
||||
* 2.4: http://open.silverstripe.org/changeset/114499 http://open.silverstripe.org/changeset/114500
|
||||
http://open.silverstripe.org/changeset/114506 http://open.silverstripe.org/changeset/114507
|
||||
* 2.3: http://open.silverstripe.org/changeset/114501 http://open.silverstripe.org/changeset/114502
|
||||
http://open.silverstripe.org/changeset/114509
|
||||
* trunk: `http://open.silverstripe.org/changeset/114497` `http://open.silverstripe.org/changeset/114498`
|
||||
`http://open.silverstripe.org/changeset/114503` `http://open.silverstripe.org/changeset/114504`
|
||||
`http://open.silverstripe.org/changeset/114505`
|
||||
* 2.4: `http://open.silverstripe.org/changeset/114499` `http://open.silverstripe.org/changeset/114500`
|
||||
`http://open.silverstripe.org/changeset/114506` `http://open.silverstripe.org/changeset/114507`
|
||||
* 2.3: `http://open.silverstripe.org/changeset/114501` `http://open.silverstripe.org/changeset/114502`
|
||||
`http://open.silverstripe.org/changeset/114509`
|
||||
|
||||
|
||||
### Security: HTTP referer leakage on Security/changepassword
|
||||
@ -227,9 +227,9 @@ Andrew Lord
|
||||
|
||||
#### Patches
|
||||
|
||||
* trunk: http://open.silverstripe.org/changeset/114758
|
||||
* 2.4: http://open.silverstripe.org/changeset/114760
|
||||
* 2.3: http://open.silverstripe.org/changeset/114763
|
||||
* trunk: `http://open.silverstripe.org/changeset/114758`
|
||||
* 2.4: `http://open.silverstripe.org/changeset/114760`
|
||||
* 2.3: `http://open.silverstripe.org/changeset/114763`
|
||||
|
||||
|
||||
### Security: CSRF protection bypassed when handling form action requests through controller
|
||||
@ -267,9 +267,9 @@ Ingo Schommer
|
||||
#### Patches
|
||||
|
||||
|
||||
* trunk: http://open.silverstripe.org/changeset/115182 http://open.silverstripe.org/changeset/115185
|
||||
* 2.4: http://open.silverstripe.org/changeset/115189 http://open.silverstripe.org/changeset/115188
|
||||
* 2.3: http://open.silverstripe.org/changeset/115200 http://open.silverstripe.org/changeset/115191
|
||||
* trunk: `http://open.silverstripe.org/changeset/115182` `http://open.silverstripe.org/changeset/115185`
|
||||
* 2.4: `http://open.silverstripe.org/changeset/115189` `http://open.silverstripe.org/changeset/115188`
|
||||
* 2.3: `http://open.silverstripe.org/changeset/115200` `http://open.silverstripe.org/changeset/115191`
|
||||
|
||||
|
||||
## Changelog
|
||||
@ -361,4 +361,4 @@ Ingo Schommer
|
||||
### Other
|
||||
|
||||
* [rev:114464] FIX: Revert last commit
|
||||
* [rev:114463] FIX: Revert last commit
|
||||
* [rev:114463] FIX: Revert last commit
|
||||
|
||||
@ -29,7 +29,7 @@ Please note that all these files are still exposed through the webserver if the
|
||||
regardless of the `ShowInSearch` setting. To fully secure uploaded files,
|
||||
you can apply protection on a webserver level (e.g. `.htaccess`/`web.config` configuration).
|
||||
Alternatively, you can proxy these files through your own permission control system
|
||||
rather than exposing them directly through the webserver (e.g. with the ["securefiles" module](http://www.silverstripe.org/secure-files/)).
|
||||
rather than exposing them directly through the webserver (e.g. with the ["secureassets" module](https://github.com/silverstripe-labs/silverstripe-secureassets/)).
|
||||
|
||||
One common way to allow user-uploaded files is the ["userforms" module](http://www.silverstripe.org/user-forms-module/). This module has been altered to mark all uploaded files with `ShowInSearch`=0 by default.
|
||||
|
||||
@ -91,7 +91,7 @@ which has the same bugfixes applied.
|
||||
* 2011-09-15 [83ad8d4](https://github.com/silverstripe/sapphire/commit/83ad8d4) Added File.ShowInSearch flag to mirror the existing SiteTree.ShowInSearch flag - e.g. useful to limit visibility of user-uploaded files. Enforced in MySQLDatabase->searchEngine(). (Ingo Schommer)
|
||||
* 2011-05-26 [9d344a0](https://github.com/silverstripe/sapphire/commit/9d344a0) Allowing filtered arguments on specific functions like mysql_connect() in SS_Backtrace (Ingo Schommer)
|
||||
* 2011-02-11 [c6992f3](https://github.com/silverstripe/sapphire/commit/c6992f3) Adjusted from-source documentation to github and piston (Ingo Schommer)
|
||||
* 2011-02-07 [8bd01d6](https://github.com/silverstripe/sapphire/commit/8bd01d6) Added sapphire/docs (migrated from https://github.com/chillu/silverstripe-doc-restructuring) (Ingo Schommer)
|
||||
* 2011-02-07 [8bd01d6](https://github.com/silverstripe/sapphire/commit/8bd01d6) Added sapphire/docs (migrated from `https://github.com/chillu/silverstripe-doc-restructuring`) (Ingo Schommer)
|
||||
* 2011-02-02 [590dbb5](https://github.com/silverstripe/sapphire/commit/590dbb5) Made it possible to attach utility links to a ComplexTableField beyond just exporting (e.g. printing). (ajshort)
|
||||
|
||||
### Bugfixes
|
||||
@ -111,8 +111,8 @@ which has the same bugfixes applied.
|
||||
* 2011-08-20 [0ef4161](https://github.com/silverstripe/sapphire/commit/0ef4161) fixed syntax error in FormAction example. (Will Rossiter)
|
||||
* 2011-08-11 [62ed138](https://github.com/silverstripe/sapphire/commit/62ed138) documentation fixes from comments provided by the community. See below for a list of fixes: * fixed typo in Email documentation. * updated link for tutorial code to be relative now that bug #6408 is fixed * removed 2.3 related docs from 2.4 docs folder * fixed typo with Orientation documentation * updated old task url for images/flush (Will Rossiter)
|
||||
* 2011-05-19 [1704e42](https://github.com/silverstripe/sapphire/commit/1704e42) Return empty string from SQLQuery->sql() if SELECT is the default value, and no FROM is set (moved logic from DB-specific implementations) (Ingo Schommer)
|
||||
* 2011-03-21 [4c1866c](https://github.com/silverstripe/sapphire/commit/4c1866c) Updated contributing guidelines (Ingo Schommer)
|
||||
* 2011-03-21 [551bc5d](https://github.com/silverstripe/sapphire/commit/551bc5d) Improved patch documentation (Ingo Schommer)
|
||||
* 2011-03-21 `[4c1866c](https://github.com/silverstripe/sapphire/commit/4c1866c)` Updated contributing guidelines (Ingo Schommer)
|
||||
* 2011-03-21 `[551bc5d](https://github.com/silverstripe/sapphire/commit/551bc5d)` Improved patch documentation (Ingo Schommer)
|
||||
* 2011-03-08 [e9f20cf](https://github.com/silverstripe/sapphire/commit/e9f20cf) Documentation fixes (Ingo Schommer)
|
||||
* 2011-03-08 [5d87f29](https://github.com/silverstripe/sapphire/commit/5d87f29) Added fix to test troubleshooting docs about PHPUnit 3.5 missing MockObject class (Sean Harvey)
|
||||
* 2011-03-03 [cc0f62c](https://github.com/silverstripe/sapphire/commit/cc0f62c) Fixed title escaping in 'built in page controls' documentation (Ingo Schommer)
|
||||
@ -142,4 +142,4 @@ which has the same bugfixes applied.
|
||||
* 2011-06-09 [5d3ddaf](https://github.com/silverstripe/silverstripe-cms/commit/5d3ddaf) Add some translation in cms core (Ladislav Kubes)
|
||||
* 2011-06-09 [46090cf](https://github.com/silverstripe/sapphire/commit/46090cf) fix language namespace (devel)
|
||||
* 2011-06-09 [5f3dde5](https://github.com/silverstripe/sapphire/commit/5f3dde5) Add some CZ translations (devel)
|
||||
* 2011-03-09 [f3ac573](https://github.com/silverstripe/sapphire/commit/f3ac573) Small text changes, added api links, cont. updating images for tutorials, fixed tutorials from member feedback (Michael Andrewartha)
|
||||
* 2011-03-09 [f3ac573](https://github.com/silverstripe/sapphire/commit/f3ac573) Small text changes, added api links, cont. updating images for tutorials, fixed tutorials from member feedback (Michael Andrewartha)
|
||||
|
||||
@ -61,7 +61,7 @@ which points to the framework directory, and in the templates you can use `$Modu
|
||||
|
||||
### GridField: Replacement for TableListField and ComplexTableField [gridfield]###
|
||||
|
||||
We have a new component for managing lists of objects: The `[GridField](/reference/grid-field)`.
|
||||
We have a new component for managing lists of objects: The [api:GridField].
|
||||
It's a substantial rewrite of the features previously captured by `TableListField`,
|
||||
`ComplexTableField`, `HasManyComplexTableField` and `ManyManyComplexTableField`.
|
||||
|
||||
@ -432,9 +432,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 [api:GridField] API
|
||||
for more flexible data presentation (replacing [api:ComplexTableField]),
|
||||
and the [api:DataList] API for more expressive querying.
|
||||
|
||||
If you have overwritten any methods in the class, customized templates,
|
||||
or implemented your own `$collection_controller_class`/`$record_controller_class` controllers,
|
||||
@ -444,7 +444,7 @@ on details for how to achieve the same goals in the new class.
|
||||
### Stylesheet preprocessing via SCSS and the "compass" module [scss]###
|
||||
|
||||
CSS files in the `cms` and `framework/admin` modules are now generated through
|
||||
the ["compass" SilverStripe module](http://silverstripe.org/compass-module), which uses
|
||||
the ["compass" SilverStripe module](https://github.com/silverstripe-labs/silverstripe-compass), which uses
|
||||
the ["Compass" framework](http://compass-style.org/) and the ["SCSS" language](http://sass-lang.com/).
|
||||
This allows us to build more flexible and expressive stylesheets as a foundation for any
|
||||
extensions to the CMS interface.
|
||||
@ -452,7 +452,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 [api:LeftAndMain::require_css()].
|
||||
|
||||
### Built-in Javascript validation removed {#js-validation}
|
||||
|
||||
@ -468,7 +468,7 @@ The [api: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 [api:FormField::addExtraClass()]
|
||||
and the "type" class are now consistently added to the container `<div>`
|
||||
as well as the HTML form element itself.
|
||||
|
||||
@ -523,7 +523,7 @@ The `$$()` shorthand for `document.getElementsBySelector()` is no longer globall
|
||||
but rather just defined when used through other components. The `$()` shorthand
|
||||
had two meanings, based on context: Either `document.getElementsById()` through prototype.js,
|
||||
or as an alias for the `jQuery()` method. In general, we recommend not to rely on
|
||||
the `$()` global in SilverStripe, as we unset it via `[jQuery.noConflict()](http://api.jquery.com/jQuery.noConflict/)`.
|
||||
the `$()` global in SilverStripe, as we unset it via [jQuery.noConflict()](http://api.jquery.com/jQuery.noConflict/)`.
|
||||
Use a [custom alias via function scope](http://api.jquery.com/jQuery.noConflict/#example-1) if possible.
|
||||
|
||||
### Moved `Widget` API into new 'widgets' module [widgets]###
|
||||
|
||||
@ -9,11 +9,11 @@
|
||||
|
||||
## Security
|
||||
|
||||
* [BUG Fix issue with versioned dataobjects being cached between stages](https://github.com/silverstripe/silverstripe-framework/commit/4415a75d9304a3930b9c28763fc092299640c685) - See [announcement SS-2014-007](http://www.silverstripe.org/ss-2014-007-confidentiality-breach-can-occur-between-draft-and-live-modes/)
|
||||
* [BUG Fix encoding of JS redirection script](https://github.com/silverstripe/silverstripe-framework/commit/f8e3bbe3ae3f29f22d85abb73cea033659511168) - See [announcement SS-2014-006](http://www.silverstripe.org/ss-2014-006-xss-in-returnurl-redirection/)
|
||||
* [BUG Fix issue with versioned dataobjects being cached between stages](https://github.com/silverstripe/silverstripe-framework/commit/4415a75d9304a3930b9c28763fc092299640c685) - See `[announcement SS-2014-007](http://www.silverstripe.org/download/security-releases/ss-2014-007)`
|
||||
* [BUG Fix encoding of JS redirection script](https://github.com/silverstripe/silverstripe-framework/commit/f8e3bbe3ae3f29f22d85abb73cea033659511168) - See `[announcement SS-2014-006](http://www.silverstripe.org/download/security-releases/ss-2014-006)`
|
||||
* [Amends solution to SS-2014-006](https://github.com/silverstripe/silverstripe-framework/commit/5b0a96979484fad12e11ce69aef98feda57b321f)
|
||||
* [FIX Prevent SQLi when no URL filters are applied](https://github.com/silverstripe/silverstripe-cms/commit/114df8a3a5e4800ef7586c5d9c8d79798fd2a11d) - See [announcement SS-2014-004](http://www.silverstripe.org/ss-2014-004-sql-injection-in-sitetree-with-custom-urlsegmentfilter-rules/)
|
||||
* [FIX Do now allow arbitary class creation in CMS](https://github.com/silverstripe/silverstripe-cms/commit/bf9b22fd4331a6f78cec12a75262f570b025ec2d) - See [announcement SS-2014-005](http://www.silverstripe.org/ss-2014-005-arbitrary-class-creation-in-cms-backend/)
|
||||
* [FIX Prevent SQLi when no URL filters are applied](https://github.com/silverstripe/silverstripe-cms/commit/114df8a3a5e4800ef7586c5d9c8d79798fd2a11d) - See `[announcement SS-2014-004](http://www.silverstripe.org/download/security-releases/ss-2014-004)`
|
||||
* [FIX Do now allow arbitary class creation in CMS](https://github.com/silverstripe/silverstripe-cms/commit/bf9b22fd4331a6f78cec12a75262f570b025ec2d) - See `[announcement SS-2014-005](http://www.silverstripe.org/download/security-releases/ss-2014-005)`
|
||||
|
||||
## General
|
||||
|
||||
|
||||
@ -4,9 +4,9 @@ Minor security release
|
||||
|
||||
## Security
|
||||
|
||||
* 2014-04-16 [9d74bc4](https://github.com/silverstripe/sapphire/commit/9d74bc4) Potential DoS exploit in TinyMCE - See [announcement SS-2014-009](http://www.silverstripe.org/ss-2014-009-potential-dos-exploit-in-tinymce/)
|
||||
* 2014-05-05 [9bfeffd](https://github.com/silverstripe/silverstripe-framework/commit/9bfeffd) Injection / Filesystem vulnerability in generatesecuretoken - See [announcement SS-2014-010](http://www.silverstripe.org/ss-2014-010-injection-filesystem-vulnerability-in-generatesecuretoken/)
|
||||
* 2014-05-07 [0099a18](https://github.com/silverstripe/silverstripe-framework/commit/0099a18) Folder filename injection - See [announcement SS-2014-011](http://www.silverstripe.org/ss-2014-011-folder-filename-injection/)
|
||||
* 2014-04-16 [9d74bc4](https://github.com/silverstripe/sapphire/commit/9d74bc4) Potential DoS exploit in TinyMCE - See `[announcement SS-2014-009](http://www.silverstripe.org/download/security-releases/ss-2014-009)`
|
||||
* 2014-05-05 [9bfeffd](https://github.com/silverstripe/silverstripe-framework/commit/9bfeffd) Injection / Filesystem vulnerability in generatesecuretoken - See `[announcement SS-2014-010](http://www.silverstripe.org/download/security-releases/ss-2014-010)`
|
||||
* 2014-05-07 [0099a18](https://github.com/silverstripe/silverstripe-framework/commit/0099a18) Folder filename injection - See `[announcement SS-2014-011](http://www.silverstripe.org/download/security-releases/ss-2014-011)`
|
||||
|
||||
### Bugfixes
|
||||
|
||||
|
||||
@ -44,7 +44,7 @@ For more information on the reason for this change please see the security annou
|
||||
|
||||
## Security
|
||||
|
||||
* 2015-03-16 [64955e5](https://github.com/silverstripe/silverstripe-cms/commit/64955e5) Fix SiteTree / SiteConfig permissions (Damian Mooyman) - See announcement [ss-2015-008](http://www.silverstripe.org/software/download/security-releases/ss-2015-008-sitetree-creation-permission-vulnerability)
|
||||
* 2015-03-16 [64955e5](https://github.com/silverstripe/silverstripe-cms/commit/64955e5) Fix SiteTree / SiteConfig permissions (Damian Mooyman) - See announcement `[ss-2015-008](http://www.silverstripe.org/download/security-releases/ss-2015-008)`
|
||||
|
||||
### Bugfixes
|
||||
|
||||
|
||||
@ -6,7 +6,8 @@ This security release resolves an XSS vulnerability in the Framework.
|
||||
|
||||
## Security
|
||||
|
||||
* 2015-03-20 [bdef4fc](https://github.com/silverstripe/sapphire/commit/bdef4fc) Fixed XSS vulnerability relating to rewrite_hash (Christopher Pitt) - See announcements [ss-2014-015](http://www.silverstripe.org/software/download/security-releases/ss-2014-015-ie-requests-not-properly-behaving-with-rewritehashlinks), [ss-2015-009](http://www.silverstripe.org/software/download/security-releases/ss-2015-009-xss-in-rewritten-hash-links)
|
||||
* 2015-03-20 [bdef4fc](https://github.com/silverstripe/sapphire/commit/bdef4fc) Fixed XSS vulnerability relating to rewrite_hash (Christopher Pitt) - See announcements `[ss-2014-015](http://www.silverstripe.org/download/security-releases/ss-2014-015)`
|
||||
, `[ss-2015-009](http://www.silverstripe.org/download/security-releases/ss-2015-009`)
|
||||
|
||||
## Changelog
|
||||
|
||||
|
||||
@ -7,6 +7,6 @@ to be set via unauthenticated requests, as well as some other minor security fix
|
||||
|
||||
### Security
|
||||
|
||||
* 2015-05-22 [cb6717c](https://github.com/silverstripe/sapphire/commit/cb6717c) Fix handling of empty parameter token (Damian Mooyman) - See [ss-2015-014](http://www.silverstripe.org/software/download/security-releases/ss-2015-014)
|
||||
* 2015-05-25 [c14e7f6](https://github.com/silverstripe/sapphire/commit/c14e7f6) Fix malformed urls redirecting to external sites (Damian Mooyman) - See [ss-2015-012](http://www.silverstripe.org/software/download/security-releases/ss-2015-012)
|
||||
* 2015-05-22 [5f6ac27](https://github.com/silverstripe/sapphire/commit/5f6ac27) Bug fix sqlquery select (Damian Mooyman) - See [ss-2015-011](http://www.silverstripe.org/software/download/security-releases/ss-2015-011)
|
||||
* 2015-05-22 [cb6717c](https://github.com/silverstripe/sapphire/commit/cb6717c) Fix handling of empty parameter token (Damian Mooyman) - See `[ss-2015-014](http://www.silverstripe.org/download/security-releases/ss-2015-014)`
|
||||
* 2015-05-25 [c14e7f6](https://github.com/silverstripe/sapphire/commit/c14e7f6) Fix malformed urls redirecting to external sites (Damian Mooyman) - See `[ss-2015-012](http://www.silverstripe.org/software/download/security-releases/ss-2015-012)`
|
||||
* 2015-05-22 [5f6ac27](https://github.com/silverstripe/sapphire/commit/5f6ac27) Bug fix sqlquery select (Damian Mooyman) - See `[ss-2015-011](http://www.silverstripe.org/software/download/security-releases/ss-2015-011)`
|
||||
|
||||
@ -10,23 +10,23 @@
|
||||
|
||||
### Security: Require ADMIN for ?flush=1 (SS-2013-001)
|
||||
|
||||
See [announcement](http://www.silverstripe.org/ss-2013-001-require-admin-for-flush1/)
|
||||
See `[announcement](http://www.silverstripe.org/software/download/security-releases/ss-2013-001)`
|
||||
|
||||
### Security: Privilege escalation through Group hierarchy setting (SS-2013-003)
|
||||
|
||||
See [announcement](http://www.silverstripe.org/ss-2013-003-privilege-escalation-through-group-hierarchy-setting/)
|
||||
See `[announcement](http://www.silverstripe.org/software/download/security-releases/ss-2013-003)`
|
||||
|
||||
### Security: Privilege escalation through Group and Member CSV upload (SS-2013-004)
|
||||
|
||||
See [announcement](http://www.silverstripe.org/ss-2013-004-privilege-escalation-through-group-and-member-csv-upload/)
|
||||
See `[announcement](http://www.silverstripe.org/software/download/security-releases/ss-2013-004)`
|
||||
|
||||
### Security: Privilege escalation through APPLY_ROLES assignment (SS-2013-005)
|
||||
|
||||
See [announcement](http://www.silverstripe.org/ss-2013-005-privilege-escalation-through-apply-roles-assignment/)
|
||||
See `[announcement](http://www.silverstripe.org/software/download/security-releases/ss-2013-005)`
|
||||
|
||||
### Security: Information disclosure in Versioned.php (SS-2013-006)
|
||||
|
||||
See [announcement](http://www.silverstripe.org/ss-2013-006-information-disclosure-in-versioned/)
|
||||
See `[announcement](http://www.silverstripe.org/software/download/security-releases/ss-2013-006)`
|
||||
|
||||
## Upgrading
|
||||
|
||||
|
||||
@ -4,11 +4,11 @@
|
||||
|
||||
### Security: XSS in form validation errors (SS-2013-008)
|
||||
|
||||
See [announcement](http://www.silverstripe.org/ss-2013-008-xss-in-numericfield-validation/)
|
||||
See `[announcement](http://www.silverstripe.org/software/download/security-releases/ss-2013-008)`
|
||||
|
||||
### Security: XSS in CMS "Pages" section (SS-2013-009)
|
||||
|
||||
See [announcement](http://www.silverstripe.org/ss-2013-009-xss-in-cms-pages-section/)
|
||||
See `[announcement](http://www.silverstripe.org/software/download/security-releases/ss-2013-009)`
|
||||
|
||||
### API: Form validation message no longer allow HTML
|
||||
|
||||
@ -23,4 +23,4 @@ in the `FormField->validate()` API.
|
||||
* 2013-09-24 [114fb59](https://github.com/silverstripe/sapphire/commit/114fb59) Auto-escape titles in TreeDropdownField (Ingo Schommer)
|
||||
* 2013-09-24 [e170f4c](https://github.com/silverstripe/silverstripe-cms/commit/e170f4c) Escaping in "dependent pages" (SS-2013-009) (Ingo Schommer)
|
||||
* 2013-09-20 [b383a07](https://github.com/silverstripe/sapphire/commit/b383a07) Fixing tabindex added to CreditCardField when tabindex is NULL (Sean Harvey)
|
||||
* 2013-09-20 [c453ea3](https://github.com/silverstripe/sapphire/commit/c453ea3) Fixing tabindex added to CreditCardField when tabindex is NULL (Sean Harvey)
|
||||
* 2013-09-20 [c453ea3](https://github.com/silverstripe/sapphire/commit/c453ea3) Fixing tabindex added to CreditCardField when tabindex is NULL (Sean Harvey)
|
||||
|
||||
@ -2,11 +2,11 @@
|
||||
|
||||
## Overview
|
||||
|
||||
* Security: Require ADMIN for ?flush=1&isDev=1 ([SS-2014-001](http://www.silverstripe.org/ss-2014-001-require-admin-for-flush1-and-isdev1))
|
||||
* Security: XSS in third party library (SWFUpload) ([SS-2014-002](http://www.silverstripe.org/ss-2014-002-xss-in-third-party-library-swfupload/))
|
||||
* Security: Require ADMIN for ?flush=1&isDev=1 (`[SS-2014-001](http://www.silverstripe.org/ss-2014-001-require-admin-for-flush1-and-isdev1)`)
|
||||
* Security: XSS in third party library (SWFUpload) (`[SS-2014-002](http://www.silverstripe.org/ss-2014-002-xss-in-third-party-library-swfupload/)`)
|
||||
|
||||
## Changelog
|
||||
|
||||
* [framework](https://github.com/silverstripe/silverstripe-framework/releases/tag/3.0.9)
|
||||
* [cms](https://github.com/silverstripe/silverstripe-framework/releases/tag/3.0.9)
|
||||
* [installer](https://github.com/silverstripe/silverstripe-framework/releases/tag/3.0.9)
|
||||
* [installer](https://github.com/silverstripe/silverstripe-framework/releases/tag/3.0.9)
|
||||
|
||||
@ -60,8 +60,8 @@ See [3.0.0 upgrading guide](../3.0.0) for further details.
|
||||
* 2011-08-29 [6a98615](https://github.com/silverstripe/sapphire/commit/6a98615) Supporting values not in $source in LookupField, instead of displaying "(none)" (which makes it useable in DataDifferencer) (AIR-24) (Ingo Schommer)
|
||||
* 2011-08-29 [2ec2c97](https://github.com/silverstripe/sapphire/commit/2ec2c97) Allowing diffs of has_one relationship in DataDifferencer (AIR-24) (Ingo Schommer)
|
||||
* 2011-08-29 [4d31ac6](https://github.com/silverstripe/sapphire/commit/4d31ac6) Allowing array values in ListboxField->setValue(), serialising into comma-separated list of values (AIR-35) (Ingo Schommer)
|
||||
* 2011-08-22 [37dc807](https://github.com/silverstripe/sapphire/commit/37dc807) Added custom 'onafterinsert' event to forms dealing with link/image/flash insertion through tiny_mce_improvements.js, which allows e.g. to close them automatically after insertion (AIR-14) (Ingo Schommer)
|
||||
* 2011-08-22 [654173e](https://github.com/silverstripe/sapphire/commit/654173e) Allow usage of custom 'fieldClasses' argument to FormScaffolder for relationships (Ingo Schommer)
|
||||
* 2011-08-22 `[37dc807](https://github.com/silverstripe/sapphire/commit/37dc807)` Added custom 'onafterinsert' event to forms dealing with link/image/flash insertion through tiny_mce_improvements.js, which allows e.g. to close them automatically after insertion (AIR-14) (Ingo Schommer)
|
||||
* 2011-08-22 `[654173e](https://github.com/silverstripe/sapphire/commit/654173e)` Allow usage of custom 'fieldClasses' argument to FormScaffolder for relationships (Ingo Schommer)
|
||||
* 2011-08-12 [aefda19](https://github.com/silverstripe/silverstripe-cms/commit/aefda19) Adding SilverStripe navigator to CMSMain->getEditForm() if not already present through LeftandMain->getEditForm() (in case custom $fields parameter is passed into the method) (Ingo Schommer)
|
||||
* 2011-07-21 [4461cae](https://github.com/silverstripe/sapphire/commit/4461cae) New CMSPreviewable interface class to standardize metadata making a record previewable by the CMS. ENHANCEMENT New "preview" and "edit" buttons to toggle between preview and cms views. Reinstated utility links to switch between draft and live preview (based on SilverStripeNavigator) (formerly called "AjaxSwitchView") (Ingo Schommer)
|
||||
* 2011-07-21 [ab3fe3e](https://github.com/silverstripe/silverstripe-cms/commit/ab3fe3e) Implementing CMSPreviewable in SiteTree (Ingo Schommer)
|
||||
@ -281,4 +281,4 @@ See [3.0.0 upgrading guide](../3.0.0) for further details.
|
||||
* 2011-06-23 [bb09555](https://github.com/silverstripe/sapphire/commit/bb09555) Forgot to remove this line in my last commit. (Colby Klein)
|
||||
* 2011-06-23 [1460789](https://github.com/silverstripe/sapphire/commit/1460789) Fix tabindex being present on read only form fields instead of regular ones. (Colby Klein)
|
||||
* 2011-06-08 [047d256](https://github.com/silverstripe/sapphire/commit/047d256) Updated return types for createTag and describe in documentation (Marijn Kampf)
|
||||
* 2011-03-18 [cae7791](https://github.com/silverstripe/sapphire/commit/cae7791) Allowing success and error callbacks in refresh() (Ingo Schommer)
|
||||
* 2011-03-18 [cae7791](https://github.com/silverstripe/sapphire/commit/cae7791) Allowing success and error callbacks in refresh() (Ingo Schommer)
|
||||
|
||||
@ -327,4 +327,4 @@ See [3.0.0 upgrading guide](../3.0.0) for further details.
|
||||
* 2011-12-18 [05d19d9](https://github.com/silverstripe/sapphire/commit/05d19d9) Revert "MINOR Use json_decode() instead of the Services_JSON class if the function exists." - it breaks assumptions around Convert::json2array() only converting the *first* level of an object structure into an array, which in turn fails CMSMainTest and LeftAndMainTest (as well as some UI functionality relying on it). In order to introduce this change we have to fix these issues in a backwards compatible manner. (Ingo Schommer)
|
||||
* 2011-12-15 [40f0fde](https://github.com/silverstripe/sapphire/commit/40f0fde) Adding in the 'RS' => "Republic of Serbia", into this list of Counties. Will continue to add more as I come across countries not added. (Colin Burns)
|
||||
* 2011-12-09 [a642a29](https://github.com/silverstripe/sapphire/commit/a642a29) DOC Update the documentation for the datamodel to describe the SS_List sort, filter and exclude methods (Stig Lindqvist)
|
||||
* 2011-11-14 [77f5ea7](https://github.com/silverstripe/sapphire/commit/77f5ea7) Fix for bug when destroying a session with a domain cookie. See http://www.silverstripe.org/general-questions/show/18539 for more details (joaosantos81)
|
||||
* 2011-11-14 [77f5ea7](https://github.com/silverstripe/sapphire/commit/77f5ea7) Fix for bug when destroying a session with a domain cookie. See http://www.silverstripe.org/community/forums/general-questions/show/18539 for more details (joaosantos81)
|
||||
|
||||
@ -80,7 +80,7 @@
|
||||
* [rev:96792] Added new onRenameLinkAsset() handler to static publishing for better link rewriting. (from r89014)
|
||||
* [rev:96778] Files and images section warns if you are deleting a file that is linked to
|
||||
* [rev:96752] Recognise HTTP_X_FORWARDED_HOST header and use that in place of HTTP_HOST (from r93148)
|
||||
* [rev:96668] Change to TreeDropdownField, giving it filtering behaviour as described in ticket http://open.silverstripe.org/ticket/3007 . Its disabled by default for legacy compatibility, but enabled for HtmlEditorField so that link editor is filterable for local links, via an extra boolean parameter on TreeDowndownField.
|
||||
* [rev:96668] Change to TreeDropdownField, giving it filtering behaviour as described in ticket `http://open.silverstripe.org/ticket/3007` . Its disabled by default for legacy compatibility, but enabled for HtmlEditorField so that link editor is filterable for local links, via an extra boolean parameter on TreeDowndownField.
|
||||
* [rev:96440] Add onLoad callback handler CMSLoadFunctions
|
||||
* [rev:96049] Added Date::Rfc3339() for returning an RFC 3339 valid date format (from r96010)
|
||||
* [rev:95418] added delete all link to page comments. Patch via #4427. Thanks walec51
|
||||
@ -222,7 +222,7 @@
|
||||
* [rev:97980] #5009: Removed inappropriate field-detection change on multienums with no default
|
||||
* [rev:97937] missing comma
|
||||
* [rev:97935] can't upload swf file in admin/assets (open ticket #4999)
|
||||
* [rev:97926] remove the possibility that Director::isDev() could be recursively called when putting isDev=1 in $_GET, addressed in ticket #4978 (http://open.silverstripe.org/ticket/4978)
|
||||
* [rev:97926] remove the possibility that Director::isDev() could be recursively called when putting isDev=1 in $_GET, addressed in ticket #4978 (`http://open.silverstripe.org/ticket/4978`)
|
||||
* [rev:97912] Allowing translations of VirtualPage by not copying over original Locale property (see #5000)
|
||||
* [rev:97911] If a Group doesn't have any specific TRANSLATE_`<locale>` edit rights, but has general CMS access (CMS_ACCESS_CMSMain, CMS_ACCESS_LeftAndMain, ADMIN), then assign TRANSLATE_ALL permissions as a default. Necessary to avoid locking out CMS editors from their default language (see #4940 and 4941)
|
||||
* [rev:97909] Don't let a user's theme break the CMS.
|
||||
@ -235,7 +235,7 @@
|
||||
* [rev:97755] add custom search function, so the search catches also the Titles (search uses DataObject::get, which bypasses the getMenuTitle function)
|
||||
* [rev:97746] allow only 2 and 4 digit years.
|
||||
* [rev:97731] Use BASE_PATH and BASE_URL instead of data from $_SERVER.
|
||||
* [rev:97730] fix front-end validation for DYMCalendarDateField, addressed in open ticket #4967(http://open.silverstripe.org/ticket/4967).
|
||||
* [rev:97730] fix front-end validation for DYMCalendarDateField, addressed in open ticket #4967(`http://open.silverstripe.org/ticket/4967`).
|
||||
* [rev:97728] Don't rely on the current working directory for any file access; use BASE_PATH.
|
||||
* [rev:97727] Don't rely on the current directory for any logic.
|
||||
* [rev:97673] the anchor dropdown now works in IE. Also fixes other anchor-related problems as described in ticket #4961
|
||||
@ -357,7 +357,7 @@
|
||||
* [rev:96551] getting rid of problem with disappearing buttons on the initial page load (not ajax). The initialization was called twice on the CMSForm, and on the second call the ajaxActionsAtTop was removing the buttons - now the buttons are removed only when there is something to be added.
|
||||
* [rev:96443] Check for functions existence
|
||||
* [rev:96441] Check for empty
|
||||
* [rev:96427] Fixed reloading of TableFields after ajax save. (http://mingle.silverstripe.com/projects/air_nz_cms_enhancements/cards/154) (from r88921)
|
||||
* [rev:96427] Fixed reloading of TableFields after ajax save. (`http://mingle.silverstripe.com/projects/air_nz_cms_enhancements/cards/154`) (from r88921)
|
||||
* [rev:96363] Fix multiselect tree selection, since changes in r91342
|
||||
* [rev:96362] Readonly TreeMultiSelectField has form linked properly
|
||||
* [rev:95973] #4140 When clicking a tree node that was just dragged, "Stack overflow" error would be given in IE. Firebug would report "Too much recursion"
|
||||
@ -405,8 +405,8 @@
|
||||
* [rev:94002] fix some missing langs/en.js loading.
|
||||
* [rev:93984] add proper language link broken
|
||||
* [rev:93965] Changed paths according to moved thirdparty dependencies. This bit change is merged from r92613.
|
||||
* [rev:93955] fix bug that can't find tinymce_ssbuttons under sapphire/thirdpaty. this is a change merged from r92853 http://open.silverstripe.org/changeset/92853#file3
|
||||
* [rev:93950] fix bug that can't find tinymce_ssbuttons under sapphire/thirdpaty. this is a change merged from r92853 http://open.silverstripe.org/changeset/92853#file3
|
||||
* [rev:93955] fix bug that can't find tinymce_ssbuttons under sapphire/thirdpaty. this is a change merged from r92853 `http://open.silverstripe.org/changeset/92853#file3`
|
||||
* [rev:93950] fix bug that can't find tinymce_ssbuttons under sapphire/thirdpaty. this is a change merged from r92853 `http://open.silverstripe.org/changeset/92853#file3`
|
||||
* [rev:93935] merge r92502 from trunk for HtmlEditorConfig.php, merge r93934 from trunk for HtmlEditorField.js, merge r92500 from trunk for sapphire/thirdpart/tinymce-advcode/editor_plugin_src.js, aiming to solve the conflict of folder name tinymce-advcode.
|
||||
* [rev:93860] Fixed incorrect hasDatabaseField() in SearchFilter::getDbName() - use hasOwnTableDatabaseField() instead
|
||||
* [rev:93777] Fixed SearchContextTest failure
|
||||
@ -729,4 +729,4 @@
|
||||
* [rev:96779] admin section via URL (from r87320)
|
||||
* [rev:96777] javascript syntax fixes (from r86396)
|
||||
* [rev:96712] MERGE merged back a whole bunch of defect fixes from trunk (from r87846)
|
||||
*
|
||||
*
|
||||
|
||||
@ -347,7 +347,7 @@ when using deprecated functionality (through the new `Deprecation` class).
|
||||
|
||||
### Minor changes
|
||||
|
||||
* 2012-03-12 [5003b98](https://github.com/silverstripe/sapphire/commit/5003b98) 3.0.0-beta1 changelog (Ingo Schommer)
|
||||
* 2012-03-12 `[5003b98](https://github.com/silverstripe/sapphire/commit/5003b98)` 3.0.0-beta1 changelog (Ingo Schommer)
|
||||
* 2012-03-13 [f367db2](https://github.com/silverstripe/sapphire/commit/f367db2) Remove table filter from modeladmin search results (Andrew O'Neil)
|
||||
* 2012-03-13 [54507d7](https://github.com/silverstripe/sapphire/commit/54507d7) Fixed coding style in CreditCardField::Field() (Sean Harvey)
|
||||
* 2012-03-12 [2c42ffd](https://github.com/silverstripe/sapphire/commit/2c42ffd) Removed ModelAdmin JS which no longer applies due to rewrite (Ingo Schommer)
|
||||
@ -653,4 +653,4 @@ when using deprecated functionality (through the new `Deprecation` class).
|
||||
* 2012-01-17 [82ef236](https://github.com/silverstripe/sapphire/commit/82ef236) Reset ... (Dominik Beerbohm)
|
||||
* 2012-01-17 [09c1f8f](https://github.com/silverstripe/sapphire/commit/09c1f8f) Bad parameter forwarding from SS_ListDecorator (sort,filter,exclude) to i.e. DataList. (Dominik Beerbohm)
|
||||
* 2012-01-16 [3a9ea42](https://github.com/silverstripe/sapphire/commit/3a9ea42) Update view/SSViewer.php (Dominik Beerbohm)
|
||||
* 2012-01-11 [3c09e9d](https://github.com/silverstripe/sapphire/commit/3c09e9d) ENH: Some webhosters require username/password credentials to test for existing DB server (dompie)
|
||||
* 2012-01-11 [3c09e9d](https://github.com/silverstripe/sapphire/commit/3c09e9d) ENH: Some webhosters require username/password credentials to test for existing DB server (dompie)
|
||||
|
||||
@ -141,8 +141,8 @@ See [3.0.0](/changelogs/3.0.0) for previous details.
|
||||
* 2012-05-24 [808819e](https://github.com/silverstripe/silverstripe-cms/commit/808819e) Themes dropdown in SiteConfig::getCMSFields() should use setEmptyString() as the $emptyString argument is now deprecated. (Sean Harvey)
|
||||
* 2012-05-24 [63ed0cb](https://github.com/silverstripe/sapphire/commit/63ed0cb) return a meaningful translatable string when resource is invalid (Mateusz Uzdowski)
|
||||
* 2012-05-24 [9074f52](https://github.com/silverstripe/sapphire/commit/9074f52) Fixing regression in Boolean::scaffoldSearchField() (Sean Harvey)
|
||||
* 2012-05-23 [a172a2e](https://github.com/silverstripe/sapphire/commit/a172a2e) Handle consecutive shortcodes. (Simon Welsh)
|
||||
* 2012-05-23 [be2c811](https://github.com/silverstripe/silverstripe-cms/commit/be2c811) Adding missing onunmatch in AssetAdmin.DragDrop (Sean Harvey)
|
||||
* 2012-05-23 `[a172a2e](https://github.com/silverstripe/sapphire/commit/a172a2e)` Handle consecutive shortcodes. (Simon Welsh)
|
||||
* 2012-05-23 `[be2c811](https://github.com/silverstripe/silverstripe-cms/commit/be2c811)` Adding missing onunmatch in AssetAdmin.DragDrop (Sean Harvey)
|
||||
* 2012-05-23 [bbb08df](https://github.com/silverstripe/sapphire/commit/bbb08df) cater for elements without href (Mateusz Uzdowski)
|
||||
* 2012-05-23 [50cbef7](https://github.com/silverstripe/silverstripe-cms/commit/50cbef7) remove unnecessary class that breaks the tab opening. (Mateusz Uzdowski)
|
||||
* 2012-05-23 [77dbcee](https://github.com/silverstripe/sapphire/commit/77dbcee) i18n::include_by_locale() doesn't include a fallback language, _t() instead will include the language if it's not available. This fixes en_GB translations not being picked up. i18n::get_translators() will always have a fallback of "en" language without the region, and "en_US" as the locale. (Sean Harvey)
|
||||
|
||||
@ -12,8 +12,8 @@ See [3.0.0 upgrading guide](../3.0.0)
|
||||
|
||||
### API Changes
|
||||
|
||||
* 2011-04-28 [48d326c](https://github.com/silverstripe/sapphire/commit/48d326c) Removed Object->cacheToFileWithArgs(), please use Object->cacheToFile() with the $arguments param (Ingo Schommer)
|
||||
* 2011-04-28 [f485220](https://github.com/silverstripe/sapphire/commit/f485220) Removed LeftAndMain->getitem(), use show() instead (Ingo Schommer)
|
||||
* 2011-04-28 `[48d326c](https://github.com/silverstripe/sapphire/commit/48d326c)` Removed Object->cacheToFileWithArgs(), please use Object->cacheToFile() with the $arguments param (Ingo Schommer)
|
||||
* 2011-04-28 `[f485220](https://github.com/silverstripe/sapphire/commit/f485220)` Removed LeftAndMain->getitem(), use show() instead (Ingo Schommer)
|
||||
* 2011-04-23 [beb9fe4](https://github.com/silverstripe/silverstripe-cms/commit/beb9fe4) Removed CMSMain->getfilteredsubtree(), use getsubtree(). API CHANGE Removed CMSMain->SiteTreeFilters(), use CMSSiteTreeFilter_Search (Ingo Schommer)
|
||||
* 2011-04-23 [2c3dd5d](https://github.com/silverstripe/silverstripe-cms/commit/2c3dd5d) Removed CMSMainMarkingFilter, replaced a while ago by CMSSiteTreeFilter_Search (Ingo Schommer)
|
||||
* 2011-04-19 [ecddf5b](https://github.com/silverstripe/sapphire/commit/ecddf5b) ModelAdmin->ResultsForm() no longer returns a TabSet (was just a layout crutch to support correct sizing) (Ingo Schommer)
|
||||
@ -113,7 +113,7 @@ See [3.0.0 upgrading guide](../3.0.0)
|
||||
|
||||
### Features and Enhancements
|
||||
|
||||
* 2011-04-30 [1e69d08](https://github.com/silverstripe/sapphire/commit/1e69d08) Added ClassManifest->getModules(), and removed limitation to toplevel modules in ClassManifest->handleFile() (necessary to detect new sapphire/admin/ "submodule") (Ingo Schommer)
|
||||
* 2011-04-30 `[1e69d08](https://github.com/silverstripe/sapphire/commit/1e69d08)` Added ClassManifest->getModules(), and removed limitation to toplevel modules in ClassManifest->handleFile() (necessary to detect new sapphire/admin/ "submodule") (Ingo Schommer)
|
||||
* 2011-04-28 [8fe9283](https://github.com/silverstripe/silverstripe-cms/commit/8fe9283) Adding page ID as metadata in SiteTree->MetaTags() in order to provide context for CMS preview of pages (Ingo Schommer)
|
||||
* 2011-04-28 [0fd6924](https://github.com/silverstripe/sapphire/commit/0fd6924) Preview changes of page edits in CMS on website (through <iframe> sidebar) (Ingo Schommer)
|
||||
* 2011-04-24 [d916140](https://github.com/silverstripe/sapphire/commit/d916140) Added incompatibility notice for Internet Explorer 6 in LeftAndMain.js (Ingo Schommer)
|
||||
@ -687,12 +687,12 @@ See [3.0.0 upgrading guide](../3.0.0)
|
||||
|
||||
* 2011-05-01 [e33576d](https://github.com/silverstripe/silverstripe-cms/commit/e33576d) Grouping date search fields in CMSMain->SearchForm (Ingo Schommer)
|
||||
* 2011-04-30 [4f157e3](https://github.com/silverstripe/silverstripe-cms/commit/4f157e3) Fixed CreateToplevelGroups toggling in CMSMain.EditForm.js (Ingo Schommer)
|
||||
* 2011-04-30 [1486bb0](https://github.com/silverstripe/sapphire/commit/1486bb0) Rendering DateField instances with button by default in CMS (Ingo Schommer)
|
||||
* 2011-04-30 [ea7a6ff](https://github.com/silverstripe/sapphire/commit/ea7a6ff) Adding (optional) Compass_RebuildDecorator to LeftAndMain in order to rebuild admin stylesheets dynamically (Ingo Schommer)
|
||||
* 2011-04-30 `[1486bb0](https://github.com/silverstripe/sapphire/commit/1486bb0)` Rendering DateField instances with button by default in CMS (Ingo Schommer)
|
||||
* 2011-04-30 `[ea7a6ff](https://github.com/silverstripe/sapphire/commit/ea7a6ff)` Adding (optional) Compass_RebuildDecorator to LeftAndMain in order to rebuild admin stylesheets dynamically (Ingo Schommer)
|
||||
* 2011-04-30 [bf8bc1d](https://github.com/silverstripe/silverstripe-cms/commit/bf8bc1d) Added CMSPageHistoryController, CMSPageReportsController, marked placeholders for new functionality in AssetAdmin (Ingo Schommer)
|
||||
* 2011-04-30 [330255d](https://github.com/silverstripe/sapphire/commit/330255d) Fixed Member_ProfileForm styling, inlining into _style.css. Misc style fixes (Ingo Schommer)
|
||||
* 2011-04-30 [5fc816f](https://github.com/silverstripe/sapphire/commit/5fc816f) Fixed panel styling for TreeDropdownField (Ingo Schommer)
|
||||
* 2011-04-30 [b8ecc0c](https://github.com/silverstripe/sapphire/commit/b8ecc0c) Removed unnecessary headers from Member->getCMSFields() (Ingo Schommer)
|
||||
* 2011-04-30 `[330255d](https://github.com/silverstripe/sapphire/commit/330255d)` Fixed Member_ProfileForm styling, inlining into _style.css. Misc style fixes (Ingo Schommer)
|
||||
* 2011-04-30 `[5fc816f](https://github.com/silverstripe/sapphire/commit/5fc816f)` Fixed panel styling for TreeDropdownField (Ingo Schommer)
|
||||
* 2011-04-30 `[b8ecc0c](https://github.com/silverstripe/sapphire/commit/b8ecc0c)` Removed unnecessary headers from Member->getCMSFields() (Ingo Schommer)
|
||||
* 2011-04-28 [51ba790](https://github.com/silverstripe/silverstripe-cms/commit/51ba790) Correct stage URL in CMSMain->EditForm (Ingo Schommer)
|
||||
* 2011-04-27 [afa05f9](https://github.com/silverstripe/sapphire/commit/afa05f9) Background color fallbacks for IE (no gradient support) (Ingo Schommer)
|
||||
* 2011-04-25 [dc2a120](https://github.com/silverstripe/sapphire/commit/dc2a120) Moved HTMLEditorField dialog title to jQuery UI compatible form attribute (Ingo Schommer)
|
||||
@ -731,8 +731,8 @@ See [3.0.0 upgrading guide](../3.0.0)
|
||||
* 2011-04-17 [f4cb6ae](https://github.com/silverstripe/sapphire/commit/f4cb6ae) Renamed #sitetree_ul to .cms-tree in templates, removed #sitetree from contained <ul> (unnecessary duplication) (Ingo Schommer)
|
||||
* 2011-04-16 [7bee470](https://github.com/silverstripe/sapphire/commit/7bee470) Updated jquery-metadata to v2.1 (removed piston as the release is not contained in the canonical git repo) (Ingo Schommer)
|
||||
* 2011-04-16 [bb4dbaa](https://github.com/silverstripe/silverstripe-cms/commit/bb4dbaa) Removed unused CMSMain_rightbottom.ss (Ingo Schommer)
|
||||
* 2011-04-16 [87bdb0d](https://github.com/silverstripe/sapphire/commit/87bdb0d) Removed unused LeftAndMain_rightbottom.ss (Ingo Schommer)
|
||||
* 2011-04-15 [53ed7c4](https://github.com/silverstripe/silverstripe-cms/commit/53ed7c4) Disallow nested ErrorPage instances via canAddChildren() (Ingo Schommer)
|
||||
* 2011-04-16 `[87bdb0d](https://github.com/silverstripe/sapphire/commit/87bdb0d)` Removed unused LeftAndMain_rightbottom.ss (Ingo Schommer)
|
||||
* 2011-04-15 `[53ed7c4](https://github.com/silverstripe/silverstripe-cms/commit/53ed7c4)` Disallow nested ErrorPage instances via canAddChildren() (Ingo Schommer)
|
||||
* 2011-04-15 [6dbfd5f](https://github.com/silverstripe/sapphire/commit/6dbfd5f) Renaming <div id="contentPanel"> to "cms-editor-dialogs" (Ingo Schommer)
|
||||
* 2011-04-15 [dafb93f](https://github.com/silverstripe/sapphire/commit/dafb93f) Moved loading screen above layout initialization to avoid FOUC in LeftAndMain.js (Ingo Schommer)
|
||||
* 2011-04-15 [f2f6ecc](https://github.com/silverstripe/sapphire/commit/f2f6ecc) Hardcoding jstree CSS url to avoid loading non-existant CSS files via ajax (through jstree library) (Ingo Schommer)
|
||||
@ -876,7 +876,7 @@ See [3.0.0 upgrading guide](../3.0.0)
|
||||
* 2011-03-03 [a05de97](https://github.com/silverstripe/sapphire/commit/a05de97) Adding custom load icon for tree node ajax loading in TreeDropdownField.css (Ingo Schommer)
|
||||
* 2011-03-03 [cf467d5](https://github.com/silverstripe/silverstripe-cms/commit/cf467d5) Disabled animation on tree (for performance reasons) (Ingo Schommer)
|
||||
* 2011-03-03 [6d3cf21](https://github.com/silverstripe/silverstripe-cms/commit/6d3cf21) Removed unnecessary tree CSS styles, will be replaced by new styles based on jstree.js (Ingo Schommer)
|
||||
* 2011-03-03 [8419ee8](https://github.com/silverstripe/silverstripe-cms/commit/8419ee8) Removed custom TreeDropdownField CSS styles (copypasted the entire block only to adjust widths), no longer necessary due to a flexible width system on the base styles (Ingo Schommer)
|
||||
* 2011-03-03 `[8419ee8](https://github.com/silverstripe/silverstripe-cms/commit/8419ee8)` Removed custom TreeDropdownField CSS styles (copypasted the entire block only to adjust widths), no longer necessary due to a flexible width system on the base styles (Ingo Schommer)
|
||||
* 2011-03-03 [3dbe03c](https://github.com/silverstripe/silverstripe-cms/commit/3dbe03c) Reverted floating of TinyMCE icons, as they don't automatically break into multiple lines like other floated elements (Ingo Schommer)
|
||||
* 2011-03-03 [a137360](https://github.com/silverstripe/silverstripe-cms/commit/a137360) Temporarily disabled onchange bindings in ThumbnailStripField, as they fail in IE7/IE8 (Ingo Schommer)
|
||||
* 2011-03-03 [76d32cb](https://github.com/silverstripe/sapphire/commit/76d32cb) Removed window.onresize() call in tiny_mce_improvements.js, now handled by jQuery.layout (Ingo Schommer)
|
||||
@ -1381,7 +1381,7 @@ See [3.0.0 upgrading guide](../3.0.0)
|
||||
* 2009-11-27 [0f8c47c](https://github.com/silverstripe/sapphire/commit/0f8c47c) Moved static functions in ContentNegotiator above the instance methods (from r93641) (Sean Harvey)
|
||||
* 2009-11-27 [162c607](https://github.com/silverstripe/sapphire/commit/162c607) Update mergeinfo to ignore jsparty changes in 2.4 (Sean Harvey)
|
||||
* 2009-11-27 [ae083e3](https://github.com/silverstripe/sapphire/commit/ae083e3) Update the main.php PHP version numbers at the top doc block (from r93449) (Sean Harvey)
|
||||
* 2009-11-27 [487bb76](https://github.com/silverstripe/sapphire/commit/487bb76) Fixed PHP notice (#4765) (Ingo Schommer)
|
||||
* 2009-11-27 `[487bb76](https://github.com/silverstripe/sapphire/commit/487bb76)` Fixed PHP notice (#4765) (Ingo Schommer)
|
||||
* 2009-11-27 [3b9fef2](https://github.com/silverstripe/silverstripe-installer/commit/3b9fef2) Removed jsparty from mergesources (sharvey)
|
||||
* 2009-11-26 [64faf66](https://github.com/silverstripe/silverstripe-installer/commit/64faf66) Removed checks for jsparty/ directory, which is no longer required (ischommer)
|
||||
* 2009-11-26 [7ca8524](https://github.com/silverstripe/sapphire/commit/7ca8524) Moved jsparty/tiny_mce to sapphire/thirdparty/tinymce (Ingo Schommer)
|
||||
@ -1622,8 +1622,8 @@ See [3.0.0 upgrading guide](../3.0.0)
|
||||
|
||||
### Other
|
||||
|
||||
* 2011-04-30 [4621210](https://github.com/silverstripe/sapphire/commit/4621210) merge styles (Ingo Schommer)
|
||||
* 2011-04-30 [0085101](https://github.com/silverstripe/sapphire/commit/0085101) merge menu (Ingo Schommer)
|
||||
* 2011-04-30 `[4621210](https://github.com/silverstripe/sapphire/commit/4621210)` merge styles (Ingo Schommer)
|
||||
* 2011-04-30 `[0085101](https://github.com/silverstripe/sapphire/commit/0085101)` merge menu (Ingo Schommer)
|
||||
* 2011-04-26 [c2d3da6](https://github.com/silverstripe/sapphire/commit/c2d3da6) Change path directory in comment (Hugues Lamy)
|
||||
* 2011-04-25 [14c60c5](https://github.com/silverstripe/sapphire/commit/14c60c5) Landing pull request 17. Fixes Call to a member function setValue() on a non-object in ConfirmedPasswordField Fixes #????. (Will Rossiter)
|
||||
* 2011-04-06 [940df33](https://github.com/silverstripe/silverstripe-installer/commit/940df33) Updated the installer to reflect the moved Sapphire files (Howard Grigg)
|
||||
@ -1676,4 +1676,4 @@ See [3.0.0 upgrading guide](../3.0.0)
|
||||
* 2009-11-19 [19c7e11](https://github.com/silverstripe/silverstripe-installer/commit/19c7e11) added mysite theme (from r71148) (ischommer)
|
||||
* 2009-11-19 [e361bea](https://github.com/silverstripe/silverstripe-installer/commit/e361bea) removed tutorial files (from r71147) (ischommer)
|
||||
* 2009-11-19 [3c07e8b](https://github.com/silverstripe/silverstripe-installer/commit/3c07e8b) ... (from r71146) (ischommer)
|
||||
* 2009-11-19 [5bb0d9b](https://github.com/silverstripe/silverstripe-installer/commit/5bb0d9b) Removed DirectorySlash update from installer's default htaccess as it breaks some installation targets (from r67085) (ischommer)
|
||||
* 2009-11-19 [5bb0d9b](https://github.com/silverstripe/silverstripe-installer/commit/5bb0d9b) Removed DirectorySlash update from installer's default htaccess as it breaks some installation targets (from r67085) (ischommer)
|
||||
|
||||
@ -51,7 +51,7 @@ See [3.0.0](/changelogs/3.0.0) for previous details.
|
||||
* 2012-06-22 [86a2ff5](https://github.com/silverstripe/sapphire/commit/86a2ff5) Updated translations master (Ingo Schommer)
|
||||
* 2012-06-20 [3a7128d](https://github.com/silverstripe/sapphire/commit/3a7128d) Fixed phpdocs (Ingo Schommer)
|
||||
* 2012-06-20 [211ce61](https://github.com/silverstripe/silverstripe-cms/commit/211ce61) move route to cms module (Will Rossiter)
|
||||
* 2012-06-19 [facc8ba](https://github.com/silverstripe/silverstripe-cms/commit/facc8ba) restore backlinkcount into cms module. (removed from framework in https://github.com/willrossi/sapphire/commit/266a61221cbf3d128f8aa0248726352dba91c19b) (Will Rossiter)
|
||||
* 2012-06-19 [facc8ba](https://github.com/silverstripe/silverstripe-cms/commit/facc8ba) restore backlinkcount into cms module. (removed from framework in `https://github.com/willrossi/sapphire/commit/266a61221cbf3d128f8aa0248726352dba91c19b`) (Will Rossiter)
|
||||
* 2012-06-19 [8b43780](https://github.com/silverstripe/sapphire/commit/8b43780) remove dependency on RootURLController and show a default Controller template as a failback. (Will Rossiter)
|
||||
* 2012-06-19 [eb2a042](https://github.com/silverstripe/sapphire/commit/eb2a042) exclude functional tests when running just framework module tests (Will Rossiter)
|
||||
* 2012-06-18 [0352a91](https://github.com/silverstripe/sapphire/commit/0352a91) Fixed filename glitch in changelog (Sam Minnee)
|
||||
|
||||
@ -9,10 +9,10 @@
|
||||
|
||||
## Security
|
||||
|
||||
* [BUG Fix issue with versioned dataobjects being cached between stages](https://github.com/silverstripe/silverstripe-framework/commit/4415a75d9304a3930b9c28763fc092299640c685) - See [announcement SS-2014-007](http://www.silverstripe.org/ss-2014-007-confidentiality-breach-can-occur-between-draft-and-live-modes/)
|
||||
* [BUG Fix encoding of JS redirection script](https://github.com/silverstripe/silverstripe-framework/commit/f8e3bbe3ae3f29f22d85abb73cea033659511168) - See [announcement SS-2014-006](http://www.silverstripe.org/ss-2014-006-xss-in-returnurl-redirection/)
|
||||
* [FIX Prevent SQLi when no URL filters are applied](https://github.com/silverstripe/silverstripe-cms/commit/114df8a3a5e4800ef7586c5d9c8d79798fd2a11d) - See [announcement SS-2014-004](http://www.silverstripe.org/ss-2014-004-sql-injection-in-sitetree-with-custom-urlsegmentfilter-rules/)
|
||||
* [FIX Do now allow arbitary class creation in CMS](https://github.com/silverstripe/silverstripe-cms/commit/bf9b22fd4331a6f78cec12a75262f570b025ec2d) - See [announcement SS-2014-005](http://www.silverstripe.org/ss-2014-005-arbitrary-class-creation-in-cms-backend/)
|
||||
* [BUG Fix issue with versioned dataobjects being cached between stages](https://github.com/silverstripe/silverstripe-framework/commit/4415a75d9304a3930b9c28763fc092299640c685) - See `[announcement SS-2014-007](http://www.silverstripe.org/ss-2014-007-confidentiality-breach-can-occur-between-draft-and-live-modes/)`
|
||||
* [BUG Fix encoding of JS redirection script](https://github.com/silverstripe/silverstripe-framework/commit/f8e3bbe3ae3f29f22d85abb73cea033659511168) - See `[announcement SS-2014-006](http://www.silverstripe.org/ss-2014-006-xss-in-returnurl-redirection/)`
|
||||
* [FIX Prevent SQLi when no URL filters are applied](https://github.com/silverstripe/silverstripe-cms/commit/114df8a3a5e4800ef7586c5d9c8d79798fd2a11d) - See `[announcement SS-2014-004](http://www.silverstripe.org/ss-2014-004-sql-injection-in-sitetree-with-custom-urlsegmentfilter-rules/)`
|
||||
* [FIX Do now allow arbitary class creation in CMS](https://github.com/silverstripe/silverstripe-cms/commit/bf9b22fd4331a6f78cec12a75262f570b025ec2d) - See `[announcement SS-2014-005](http://www.silverstripe.org/ss-2014-005-arbitrary-class-creation-in-cms-backend/)`
|
||||
|
||||
## General
|
||||
|
||||
|
||||
@ -4,9 +4,9 @@ Minor security release
|
||||
|
||||
## Security
|
||||
|
||||
* 2014-04-16 [9d74bc4](https://github.com/silverstripe/sapphire/commit/9d74bc4) Potential DoS exploit in TinyMCE - See [announcement SS-2014-009](http://www.silverstripe.org/ss-2014-009-potential-dos-exploit-in-tinymce/)
|
||||
* 2014-05-05 [9bfeffd](https://github.com/silverstripe/silverstripe-framework/commit/9bfeffd) Injection / Filesystem vulnerability in generatesecuretoken - See [announcement SS-2014-010](http://www.silverstripe.org/ss-2014-010-injection-filesystem-vulnerability-in-generatesecuretoken/)
|
||||
* 2014-05-07 [0099a18](https://github.com/silverstripe/silverstripe-framework/commit/0099a18) Folder filename injection - See [announcement SS-2014-011](http://www.silverstripe.org/ss-2014-011-folder-filename-injection/)
|
||||
* 2014-04-16 [9d74bc4](https://github.com/silverstripe/sapphire/commit/9d74bc4) Potential DoS exploit in TinyMCE - See `[announcement SS-2014-009](http://www.silverstripe.org/ss-2014-009-potential-dos-exploit-in-tinymce/)`
|
||||
* 2014-05-05 [9bfeffd](https://github.com/silverstripe/silverstripe-framework/commit/9bfeffd) Injection / Filesystem vulnerability in generatesecuretoken - See `[announcement SS-2014-010](http://www.silverstripe.org/ss-2014-010-injection-filesystem-vulnerability-in-generatesecuretoken/)`
|
||||
* 2014-05-07 [0099a18](https://github.com/silverstripe/silverstripe-framework/commit/0099a18) Folder filename injection - See `[announcement SS-2014-011](http://www.silverstripe.org/ss-2014-011-folder-filename-injection/)`
|
||||
|
||||
### Bugfixes
|
||||
|
||||
|
||||
@ -4,14 +4,14 @@
|
||||
|
||||
### Security: XSS in form validation errors (SS-2013-008)
|
||||
|
||||
See [announcement](http://www.silverstripe.org/ss-2013-008-xss-in-numericfield-validation/)
|
||||
See `[announcement](http://www.silverstripe.org/ss-2013-008-xss-in-numericfield-validation/)`
|
||||
|
||||
### Security: XSS in CMS "Pages" section (SS-2013-009)
|
||||
|
||||
See [announcement](http://www.silverstripe.org/ss-2013-009-xss-in-cms-pages-section/)
|
||||
See `[announcement](http://www.silverstripe.org/ss-2013-009-xss-in-cms-pages-section/)`
|
||||
|
||||
### API: Form validation message no longer allow HTML
|
||||
|
||||
Due to cross-site scripting concerns when user data is used for form messages,
|
||||
it is no longer possible to use HTML in `Form->sessionMessage()`, and consequently
|
||||
in the `FormField->validate()` API.
|
||||
in the `FormField->validate()` API.
|
||||
|
||||
@ -2,11 +2,13 @@
|
||||
|
||||
## Overview
|
||||
|
||||
* Security: Require ADMIN for ?flush=1&isDev=1 ([SS-2014-001](http://www.silverstripe.org/ss-2014-001-require-admin-for-flush1-and-isdev1))
|
||||
* Security: XSS in third party library (SWFUpload) ([SS-2014-002](http://www.silverstripe.org/ss-2014-002-xss-in-third-party-library-swfupload/))
|
||||
|
||||
|
||||
* Security: Require ADMIN for ?flush=1&isDev=1 ([SS-2014-001](http://www.silverstripe.org/download/security-releases/ss-2014-001-require-admin-for-flush1-and-isdev1))
|
||||
* Security: XSS in third party library (SWFUpload) ([SS-2014-002](http://www.silverstripe.org/download/security-releases/ss-2014-002-xss-in-third-party-library-swfupload/))
|
||||
|
||||
## Changelog
|
||||
|
||||
* [framework](https://github.com/silverstripe/silverstripe-framework/releases/tag/3.0.9-rc1)
|
||||
* [cms](https://github.com/silverstripe/silverstripe-framework/releases/tag/3.0.9-rc1)
|
||||
* [installer](https://github.com/silverstripe/silverstripe-framework/releases/tag/3.0.9-rc1)
|
||||
* [installer](https://github.com/silverstripe/silverstripe-framework/releases/tag/3.0.9-rc1)
|
||||
|
||||
@ -15,11 +15,11 @@ Default setting:
|
||||
|
||||
Overriding these defaults
|
||||
|
||||
* `[api:HTTP::set_cache_age()]` can be used to set the max-age component of the cache-control line, in seconds.
|
||||
* [api:HTTP::set_cache_age()] can be used to set the max-age component of the cache-control line, in seconds.
|
||||
Set it to 0 to disable caching; the "no-cache" clause in `Cache-Control` and `Pragma` will be included.
|
||||
* `[api:HTTP::register_modification_date()]` can be used to set the modification date to something more recent than the default.
|
||||
* [api:HTTP::register_modification_date()] can be used to set the modification date to something more recent than the default.
|
||||
|
||||
How it works:
|
||||
|
||||
* `[api:DataObject::__construct()]` calls `[api:HTTP::register_modification_date()]` whenever a record comes from the database
|
||||
* `Controller::run()` calls `[api:HTTP::add_cache_headers()]` before outputting the page
|
||||
* [api:DataObject::__construct()] calls [api:HTTP::register_modification_date()] whenever a record comes from the database
|
||||
* [api:Controller::run()] calls [api:HTTP::add_cache_headers()] before outputting the page
|
||||
|
||||
@ -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:
|
||||
[api:Member] class could have this data in a file:
|
||||
|
||||
FirstName,LastName,Email
|
||||
Donald,Duck,donald@disney.com
|
||||
@ -38,7 +38,7 @@ 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 [api:Member] and [api:Group] data through `http://localhost/admin/security`
|
||||
interface out of the box.
|
||||
|
||||
## Import through ModelAdmin
|
||||
|
||||
@ -2,11 +2,11 @@
|
||||
|
||||
## Defining a Custom Icon ##
|
||||
|
||||
Every time you add a new extension of the `api:LeftAndMain` class to the CMS, SilverStripe will automatically create a new menu-item for it, with a default title and icon.
|
||||
Every time you add a new extension of the [api:LeftAndMain] class to the CMS, SilverStripe will automatically create a new menu-item for it, with a default title and icon.
|
||||
We can easily change that behaviour by using the static `$menu_title` and `$menu_icon` statics to
|
||||
provide a custom title and icon.
|
||||
|
||||
The most popular extension of LeftAndMain is the `api:ModelAdmin` class, so we'll use that for an example.
|
||||
The most popular extension of LeftAndMain is the [api:ModelAdmin] class, so we'll use that for an example.
|
||||
We'll take the `ProductAdmin` class used in the [ModelAdmin reference](../reference/modeladmin#setup).
|
||||
|
||||
First we'll need a custom icon. For this purpose SilverStripe uses 16x16 black-and-transparent PNG graphics.
|
||||
@ -32,7 +32,7 @@ removing the "Admin" bit at the end.
|
||||
|
||||
In order to localize the menu title in different languages, use the `<classname>.MENUTITLE`
|
||||
entity name, which is automatically created when running the i18n text collection.
|
||||
For more information on language and translations, please refer to the [i18n](/topics/1i8n) docs.
|
||||
For more information on language and translations, please refer to the [i18n](/topics/i18n) docs.
|
||||
|
||||
## Related
|
||||
|
||||
|
||||
@ -7,10 +7,10 @@ by the [jstree](http://jstree.com) library. It is configured through
|
||||
`sapphire/admin/javascript/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 [api: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 [api:Hierarchy] extension,
|
||||
but in the CMS usually is a [api: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:
|
||||
|
||||
|
||||
SiteTree is a `[api:DataObject]` which is versioned by `[api:Versioned]` extension.
|
||||
SiteTree is a [api:DataObject] which is versioned by [api: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 [api: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,8 +74,8 @@ __Example: using a subclass__
|
||||
}
|
||||
}
|
||||
|
||||
The above subclass of `[api:SiteTree]` will add a new flag for indicating its
|
||||
The above subclass of [api:SiteTree] will add a new flag for indicating its
|
||||
__'Scheduled To Publish'__ status. The look of the page node will be changed
|
||||
from  to . The getStatusFlags has an `updateStatusFlags()`
|
||||
extension point, so the flags can be modified through `DataExtension` rather than
|
||||
inheritance as well. Deleting existing flags works by simply unsetting the array key.
|
||||
inheritance as well. Deleting existing flags works by simply unsetting the array key.
|
||||
|
||||
@ -2,7 +2,7 @@
|
||||
|
||||
The [api:DataObject::$defaults] array allows you to specify simple static values to be the default value for when a
|
||||
record is created, but in many situations default values needs to be dynamically calculated. In order to do this, the
|
||||
`[api:DataObject->populateDefaults()]` method will need to be overloaded.
|
||||
[api: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!
|
||||
@ -33,4 +33,4 @@ methods. For example:
|
||||
$this->FullTitle = $this->Title;
|
||||
}
|
||||
parent::populateDefaults();
|
||||
}
|
||||
}
|
||||
|
||||
@ -6,8 +6,8 @@ These lists can get quite long, and hard to present on a single list.
|
||||
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 [api:GroupedList] class.
|
||||
This class is a [api:SS_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
|
||||
@ -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 [api: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 [api:GroupedList::GroupedBy()] method.
|
||||
|
||||
:::ss
|
||||
// Modules list grouped by the Month Posted
|
||||
@ -144,4 +144,4 @@ The final step is the render this into the template using the [api:GroupedList->
|
||||
|
||||
## Related
|
||||
|
||||
* [Howto: "Pagination"](/howto/pagination)
|
||||
* [Howto: "Pagination"](/howto/pagination)
|
||||
|
||||
@ -1,12 +1,12 @@
|
||||
# Paginating A List
|
||||
|
||||
Adding pagination to a `[api:SS_List]` is quite simple. All
|
||||
you need to do is wrap the object in a `[api:PaginatedList]` decorator, which takes
|
||||
Adding pagination to a [api:SS_List] is quite simple. All
|
||||
you need to do is wrap the object in a [api:PaginatedList] decorator, which takes
|
||||
care of fetching a sub-set of the total list and presenting it to the template.
|
||||
|
||||
In order to create a paginated list, you can create a method on your controller
|
||||
that first creates a `SS_List` that will return all pages, and then wraps it
|
||||
in a `[api:PaginatedList]` object. The `PaginatedList` object is also passed the
|
||||
in a [api:PaginatedList] object. The `PaginatedList` object is also passed the
|
||||
HTTP request object so it can read the current page information from the
|
||||
"?start=" GET var.
|
||||
|
||||
@ -29,7 +29,7 @@ a sub-collection of the list.
|
||||
|
||||
Now all that remains is to render this list into a template, along with pagination
|
||||
controls. There are two ways to generate pagination controls:
|
||||
`[api:PaginatedList->Pages()]` and `[api:PaginatedList->PaginationSummary()]`. In
|
||||
[api:PaginatedList::Pages()] and [api:PaginatedList::PaginationSummary()]. In
|
||||
this example we will use `PaginationSummary()`.
|
||||
|
||||
The first step is to simply list the objects in the template:
|
||||
@ -72,10 +72,10 @@ controls in the form `[1] ... [3] [4] [[5]] [6] [7] ... [10]`.
|
||||
|
||||
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]`
|
||||
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 when using custom lists.
|
||||
[api:PaginatedList::setLimitItems()] method when using custom lists.
|
||||
|
||||
## Related
|
||||
|
||||
* [Howto: "Grouping Lists"](/howto/grouping-dataobjectsets)
|
||||
* [Howto: "Grouping Lists"](/howto/grouping-dataobjectsets)
|
||||
|
||||
@ -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 [api: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 [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.
|
||||
|
||||
:::php
|
||||
return new Form($this, 'Form', $fields, $actions);
|
||||
@ -103,7 +103,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 [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:
|
||||
|
||||
:::php
|
||||
public function Form() {
|
||||
|
||||
@ -4,14 +4,14 @@ Please read our [guide to contributing documentation](misc/contributing/document
|
||||
|
||||
### Overview
|
||||
|
||||
* [Getting started](http://silverstripe.org/getting-started/) | [Feature Overview](http://silverstripe.org/introduction/) | [Demo](http://demo.silverstripe.org/)
|
||||
* [Download and Installation](installation/) | [Upgrading](/installation/upgrading) | [Requirements](/installation/server-requirements) | [Changelog](/changelogs) | [Roadmap](http://www.silverstripe.org/roadmap/)
|
||||
* [API documentation](http://api.silverstripe.org/current) | [Official english book](http://www.silverstripe.org/silverstripe-book) | [Official german book](http://www.silverstripe.org/das-silverstripe-buch)
|
||||
* [Getting started](http://silverstripe.org/getting-started/) | `[Feature Overview](http://silverstripe.org/introduction/)` | [Demo](http://demo.silverstripe.org/)
|
||||
* [Download and Installation](installation/) | [Upgrading](/installation/upgrading) | [Requirements](/installation/server-requirements) | [Changelog](/changelogs) | `[Roadmap](http://www.silverstripe.org/roadmap/)`
|
||||
* [API documentation](http://api.silverstripe.org/current) | `[Official english book](http://www.silverstripe.org/silverstripe-book)` | `[Official german book](http://www.silverstripe.org/das-silverstripe-buch)`
|
||||
|
||||
|
||||
### Getting support
|
||||
|
||||
[Forum](http://www.silverstripe.org/forums/) | [IRC channel](http://silverstripe.org/irc) | [End user docs](http://userhelp.silverstripe.com) | [Core mailinglist](https://groups.google.com/forum/#!forum/silverstripe-dev)
|
||||
[Forum](http://www.silverstripe.org/forums/) | `[IRC channel](http://silverstripe.org/irc)` | [End user docs](http://userhelp.silverstripe.com) | [Core mailinglist](https://groups.google.com/forum/#!forum/silverstripe-dev)
|
||||
|
||||
|
||||
### Level 1: Building your first SilverStripe website
|
||||
@ -55,4 +55,4 @@ Please read our [guide to contributing documentation](misc/contributing/document
|
||||
### Level 4: Contributing to the SilverStripe core
|
||||
|
||||
* [Contributing](misc/contributing)
|
||||
* [Coding Conventions](misc/coding-conventions)
|
||||
* [Coding Conventions](misc/coding-conventions)
|
||||
|
||||
@ -2,7 +2,7 @@
|
||||
|
||||
From time to time, things will go wrong. Here's a few things to try when you're confused.
|
||||
|
||||
See ["8 Common SilverStripe Errors Explain (and solved!) (leftandmain.com)"](http://www.leftandmain.com/silverstripe-tips/2010/09/08/8-common-silverstripe-errors-explained-and-solved/)
|
||||
See `["8 Common SilverStripe Errors Explain (and solved!) (leftandmain.com)"](http://www.leftandmain.com/silverstripe-tips/2010/09/08/8-common-silverstripe-errors-explained-and-solved/)`
|
||||
for more common problems.
|
||||
|
||||
## The output shows only "Website Error"
|
||||
@ -49,7 +49,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 [api:DataObject::$db] array,
|
||||
creating a new page type), SilverStripe will need to update the database. Visiting `http://<my-domain>/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,
|
||||
@ -69,7 +69,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 [api:ManifestBuilder]
|
||||
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](/topics/datamodel) and [controllers](/topics/controller)
|
||||
for ways how to structure your code.
|
||||
|
||||
@ -17,7 +17,7 @@ lets you install and upgrade SilverStripe and its modules. Although installing
|
||||
Other ways to get SilverStripe:
|
||||
|
||||
* If you just want to get the code as quickly as possible, you can [download SilverStripe from our website](http://silverstripe.org/download).
|
||||
* If you already have an installed version of SilverStripe, and you haven't used Composer to get it, please see our [upgrading](upgrading) guide. Note that [Composer](/installatin/composer) provides its own tools for upgrading.
|
||||
* If you already have an installed version of SilverStripe, and you haven't used Composer to get it, please see our [upgrading](upgrading) guide. Note that [Composer](/installation/composer) provides its own tools for upgrading.
|
||||
|
||||
## Setting up a server
|
||||
|
||||
@ -54,4 +54,4 @@ If you run into trouble, see [common-problems](common-problems) or post to the
|
||||
## Related
|
||||
|
||||
* [Module installation](/topics/modules)
|
||||
* [Suggested web hosts](http://doc.silverstripe.org/old/suggested-web-hosts)
|
||||
* [Suggested web hosts](http://www.silverstripe.org/community/forums/archive/show/393)
|
||||
|
||||
@ -23,7 +23,7 @@ Our web-based [PHP installer](/installation) can check if you meet the requireme
|
||||
* MySQL 5.0+
|
||||
* PostgreSQL 8.3+ (requires ["postgresql" module](http://silverstripe.org/postgresql-module))
|
||||
* SQL Server 2008+ (requires ["mssql" module](http://silverstripe.org/microsoft-sql-server-database/))
|
||||
* Support for [Oracle](http://www.silverstripe.org/oracle-database-module/) and [SQLite](http://silverstripe.org/sqlite-database/) is not commercially supported, but is under development by our open source community.
|
||||
* Support for `[Oracle](http://www.silverstripe.org/oracle-database-module/)` and [SQLite](http://silverstripe.org/sqlite-database/) is not commercially supported, but is under development by our open source community.
|
||||
* One of the following web server products:
|
||||
* Apache 1.3+ with mod_rewrite and "AllowOverride All" set
|
||||
* IIS 7+
|
||||
|
||||
@ -29,7 +29,7 @@ See our [upgrade notes and changelogs](/changelogs) for release-specific informa
|
||||
|
||||
How easy will it be to update my project? It's a fair question, and sometimes a difficult one to answer.
|
||||
|
||||
* "Micro" releases (x.y.z) are explicitly backwards compatible, "minor" and "major" releases can deprecate features and change APIs (see our [Release process](/misc/release process) for details)
|
||||
* "Micro" releases (x.y.z) are explicitly backwards compatible, "minor" and "major" releases can deprecate features and change APIs (see our [Release process](/misc/release-process) for details)
|
||||
* If you've made custom branches of SilverStripe core, or any thirdparty module, it's going to be harder to upgrade.
|
||||
* The more custom features you have, the harder it will be to upgrade. You will have to re-test all of those features, and adapt to API changes in core.
|
||||
* Customisations of a well defined type - such as custom page types or custom blog widgets - are going to be easier to upgrade than customisations that modify deep system internals like rewriting SQL queries.
|
||||
|
||||
@ -111,7 +111,7 @@ You should see some output showing the PHP version. If you get something else, o
|
||||
|
||||
## Install SilverStripe
|
||||
|
||||
- [Download SilverStripe](http://silverstripe.org/downloads)
|
||||
- [Download SilverStripe](https://www.silverstripe.org/download)
|
||||
- Extract the download contents to **C:\Inetpub\wwwroot\silverstripe**
|
||||
- Open **inetmgr.exe**
|
||||
- Right click **Web Sites** and go to **New** > **Web Site**
|
||||
|
||||
@ -12,7 +12,7 @@ These versions of Windows will **NOT** work with this guide:
|
||||
* Windows Server 2003
|
||||
* Windows XP
|
||||
|
||||
**IMPORTANT**: Windows Server 2003 users should [follow this guide](http://doc.silverstripe.org/installation-on-windows-server-2003-iis-6) to installing SilverStripe.
|
||||
**IMPORTANT**: Windows Server 2003 users should [follow this link](https://www.silverstripe.org/blog/installing-on-windows-now-easier-thanks-to-microsoft-web-platform-installer/) to instal SilverStripe.
|
||||
|
||||
The goal is to get a good working web server platform so that one or more SilverStripe projects can be easily deployed onto the server using SVN/GIT.
|
||||
|
||||
|
||||
@ -28,4 +28,4 @@ Instructions are available for [installing PHP on IIS 6](http://learn.iis.net/pa
|
||||
|
||||
On Windows XP, you need to disable **Check that file exists**. See [installation-on-windows-pi](windows-pi) for more information.
|
||||
|
||||
Matthew Poole has expanded on these instructions [with a tutorial](http://cubiksoundz.blogspot.com/2008/12/tech-note-installing-silverstripe-cms.html).
|
||||
[See also](http://www.silverstripe.org/community/forums/installing-silverstripe/show/8305)
|
||||
|
||||
@ -5,7 +5,7 @@
|
||||
## Installing SilverStripe
|
||||
|
||||
* Download and run Microsoft Web Platform Installer (WebPI):
|
||||
[](http://www.microsoft.com/web/gallery/install.aspx?appsxml=www.microsoft.com%2fweb%2fwebpi%2f2.0%2fWebApplicationList.xml&appid=105)
|
||||
(http://www.microsoft.com/web/gallery/install.aspx?appsxml=www.microsoft.com%2fweb%2fwebpi%2f2.0%2fWebApplicationList.xml&appid=105)
|
||||
|
||||
* In WebPI, select 'SilverStripe' from the 'Content Management System' link
|
||||
* Select install. It will install dependancies like MySQL and PHP if you don't have these installed already.
|
||||
@ -33,7 +33,7 @@ necessary for URLs of the form http://localhost/silverstripe/index.php/about-us/
|
||||
|
||||
## Support
|
||||
|
||||
* http://www.silverstripe.org/installing-on-windows-now-easier-thanks-to-microsoft-web-platform-installer/ (This shows
|
||||
* https://www.silverstripe.org/blog/installing-on-windows-now-easier-thanks-to-microsoft-web-platform-installer/ (This shows
|
||||
a beta version of the software)
|
||||
* Microsoft Forum: http://forums.iis.net/1155.aspx
|
||||
* SilverStripe Installation Issues Forum: http://silverstripe.org/installing-silverstripe/
|
||||
|
||||
@ -445,7 +445,7 @@ See [security](/topics/security) for conventions related to handing security per
|
||||
|
||||
## License
|
||||
|
||||
Parts of these coding conventions were adapted from [Zend Framework](http://framework.zend.com/manual/en/coding-standard.overview.html),
|
||||
Parts of these coding conventions were adapted from `[Zend Framework](http://framework.zend.com/manual/en/coding-standard.overview.html)`,
|
||||
which are licensed under BSD (see [license](http://framework.zend.com/license)).
|
||||
|
||||
## Related
|
||||
|
||||
@ -6,7 +6,7 @@ The SilverStripe core modules (`framework` and `cms`), as well as some of the mo
|
||||
git version control. SilverStripe hosts its modules on [github.com/silverstripe](http://github.com/silverstripe) and [github.com/silverstripe-labs](http://github.com/silverstripe-labs). After [installing git](http://help.github.com/git-installation-redirect) and creating a [free github.com account](https://github.com/signup/free), you can "fork" a module,
|
||||
which creates a copy that you can commit to (see github's [guide to "forking"](http://help.github.com/forking/)).
|
||||
|
||||
For other modules, our [module list on silverstripe.org](http://silverstripe.org/modules) lists the repository locations, typically using a version control system like "git" or "subversion".
|
||||
For other modules, our `[module list on silverstripe.org](http://silverstripe.org/modules)` lists the repository locations, typically using a version control system like "git" or "subversion".
|
||||
|
||||
<div class="hint" markdown="1">
|
||||
Note: By supplying code to the SilverStripe core team in patches, tickets and pull requests, you agree to assign copyright of that code to SilverStripe Limited, on the condition that SilverStripe Limited releases that code under the BSD license.
|
||||
@ -104,7 +104,7 @@ step.
|
||||
* It's better to submit multiple patches with separate bits of functionality than a big patch containing lots of
|
||||
changes
|
||||
* Document your code inline through [PHPDoc](http://en.wikipedia.org/wiki/PHPDoc) syntax. See our
|
||||
[API documentation](http://api.silverstripe.org/trunk) for good examples.
|
||||
[API documentation](http://api.silverstripe.org) for good examples.
|
||||
* Also check and update documentation on [doc.silverstripe.org](http://doc.silverstripe.org). Check for any references to functionality deprecated or extended through your patch. Documentation changes should be included in the patch.
|
||||
* We will attribute the change to you whereever possible (git does this automatically for pull requests)
|
||||
* If you get stuck, please post to the [forum](http://silverstripe.org/forum) or for deeper core problems, to the [core mailinglist](https://groups.google.com/forum/#!forum/silverstripe-dev)
|
||||
@ -117,7 +117,7 @@ Most importantly: Keep the first line short, and add more detail below.
|
||||
This ensures commits are easy to browse, and look nice on github.com
|
||||
(more info about [proper git commit messages](http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html)).
|
||||
|
||||
As we automatically generate [changelogs](http://doc.silverstripe.org/sapphire/en/trunk/changelogs/) from them, we need a way to categorize and filter.
|
||||
As we automatically generate `[changelogs](http://doc.silverstripe.org/sapphire/en/trunk/changelogs/)` from them, we need a way to categorize and filter.
|
||||
Please prefix **noteworthy** commit messages with one of the following tags:
|
||||
|
||||
* `NEW`: New feature or major enhancement (both for users and developers)
|
||||
@ -133,7 +133,7 @@ Same goes for version control plumbing like merges, file renames or reverts.
|
||||
Further guidelines:
|
||||
|
||||
* Each commit should form a logical unit - if you fix two unrelated bugs, commit each one separately
|
||||
* If you are fixing a ticket from our [bugtracker](http://open.silverstripe.com), please append `(fixes #<ticketnumber>)`
|
||||
* If you are fixing a ticket from our `[bugtracker](http://open.silverstripe.com)`, please append `(fixes #<ticketnumber>)`
|
||||
* If your change is related to another commit, reference it with its abbreviated commit hash.
|
||||
* Mention important changed classes and methods in the commit summary.
|
||||
|
||||
|
||||
@ -10,14 +10,14 @@ well written bug reports can be half of the solution already!
|
||||
* [Framework Bugtracker](https://github.com/silverstripe/silverstripe-framework/issues)
|
||||
* [CMS Bugtracker](https://github.com/silverstripe/silverstripe-cms/issues)
|
||||
* [Documentation Bugtracker](https://github.com/silverstripe/silverstripe-framework/issues)
|
||||
* Search on [http://silverstripe.org/modules](http://silverstripe.org/modules) for module-specific bugtrackers
|
||||
* Search on `[http://silverstripe.org/modules](http://silverstripe.org/modules)` for module-specific bugtrackers
|
||||
|
||||
Before submitting a bug:
|
||||
|
||||
* Ask for assistance on the [forums](http://silverstripe.org/forums), [core mailinglist](http://groups.google.com/group/silverstripe-dev) or on [IRC](http://silverstripe.org/irc) if you're unsure if its really a bug.
|
||||
* Ask for assistance on the [forums](http://silverstripe.org/forums), [core mailinglist](http://groups.google.com/group/silverstripe-dev) or on `[IRC](http://silverstripe.org/irc)` if you're unsure if its really a bug.
|
||||
* Search for similar, existing tickets
|
||||
* Is this a security issue? Please follow our separate reporting guidelines below.
|
||||
* Is this a issue with the core framework or cms? Modules have their own issue trackers (see [silverstripe.org/modules](http://www.silverstripe.org/modules))
|
||||
* Is this a issue with the core framework or cms? Modules have their own issue trackers (see `[silverstripe.org/modules](http://www.silverstripe.org/modules)`)
|
||||
* Try to reproduce your issue on a [clean installation](http://doc.silverstripe.org/framework/en/installation/composer#using-development-versions), maybe the bug has already been fixed on an unreleased branch?
|
||||
* The bugtracker is not the place to discuss enhancements, please use the forums or mailinglist.
|
||||
Only log enhancement tickets if they gather a large interest in the community
|
||||
@ -45,7 +45,7 @@ can be expected to be closed as soon as they're reviewed.
|
||||
</div>
|
||||
|
||||
In order to gain interest and feedback in your feature, we encourage you to present
|
||||
it to the community through the [forums](http://silverstripe.org/forums), [core mailinglist](http://groups.google.com/group/silverstripe-dev) or on [IRC](http://silverstripe.org/irc).
|
||||
it to the community through the [forums](http://silverstripe.org/forums), [core mailinglist](http://groups.google.com/group/silverstripe-dev) or on `[IRC](http://silverstripe.org/irc)`.
|
||||
|
||||
## Reporting Security Issues
|
||||
|
||||
|
||||
@ -42,7 +42,7 @@ Special characters (such as german umlauts) need to be entered in their native f
|
||||
Currently translated entities are not directly factored into code (for security reasons and release/review-control), so you can't see them straight away.
|
||||
|
||||
It is strongly encouraged that you check your translation this way, as its a good way to doublecheck your translation works in the right context.
|
||||
Please use our [daily-builds](http://www.silverstripe.org/daily-builds/) for your local installation, to ensure you're looking at the most up to date interface. See "Download Translations" above
|
||||
Please use our `[daily-builds](http://www.silverstripe.org/daily-builds/)` for your local installation, to ensure you're looking at the most up to date interface. See "Download Translations" above
|
||||
to find out how to retrieve the latest translation files.
|
||||
|
||||
### Can I change a translation just for one SilverStripe version?
|
||||
@ -117,7 +117,7 @@ This also applies for any modules staying compatible with SilverStripe 2.x.
|
||||
## Contact
|
||||
|
||||
Translators have their own [mailinglist](https://groups.google.com/forum/#!forum/silverstripe-translators),
|
||||
but you can also reach a core member on [IRC](http://silverstripe.org/irc).
|
||||
but you can also reach a core member on `[IRC](http://silverstripe.org/irc)`.
|
||||
The transifex.com interface has a built-in discussion board if
|
||||
you have specific comments on a translation.
|
||||
|
||||
@ -126,4 +126,4 @@ you have specific comments on a translation.
|
||||
* [i18n](/topics/i18n): Developer-level documentation of Silverstripe's i18n capabilities
|
||||
* [translation-process](../translation-process): Information about managing translations for the core team and/or module maintainers.
|
||||
* [translatable](https://github.com/silverstripe/silverstripe-translatable): DataObject-interface powering the website-content translations
|
||||
* ["Translatable ModelAdmin" module](http://silverstripe.org/translatablemodeladmin-module/): An extension which allows translations of DataObjects inside ModelAdmin
|
||||
* `["Translatable ModelAdmin" module](http://silverstripe.org/translatablemodeladmin-module/)`: An extension which allows translations of DataObjects inside ModelAdmin
|
||||
|
||||
@ -4,10 +4,9 @@
|
||||
|
||||
One of the best ways that you can contribute to SilverStripe is by developing a module for SilverStripe.
|
||||
If you do, we would love to host your module and have you become an official module maintainer on our site.
|
||||
Please read our ["Contributing to SilverStripe"](http://silverstripe.org/contributing-to-silverstripe/) overview.
|
||||
Please read our [Contributing to SilverStripe](http://silverstripe.org/contributing-to-silverstripe/) overview.
|
||||
|
||||
Once you have created a module, login at [silverstripe.org](http://silverstripe.org) and
|
||||
[submit your module](http://silverstripe.org/modules/manage/add)
|
||||
Once you have created a module, you can share it with the rest of the community by [submitting your module](http://addons.silverstripe.org/add-ons)
|
||||
|
||||
It's very important to us that users of SilverStripe can come to expect a level of quality from the core product and any
|
||||
modules running on it. In order to provide this, we require certain things from module maintainers.
|
||||
@ -32,7 +31,7 @@ Each line of code you write should be version controlled, in version control sys
|
||||
available for opensource projects, including wiki and bugtracker functionality
|
||||
(e.g. [Google Code for Subversion](http://code.google.com) or [Github for Git](http://github.com)).
|
||||
|
||||
* Add your module to [silverstripe.org/modules](http://silverstripe.org/modules) (and keep the version compatibility information current)
|
||||
* Add your module to `[silverstripe.org/modules](http://silverstripe.org/modules)` (and keep the version compatibility information current)
|
||||
* Follow our [coding-conventions](coding-conventions)
|
||||
* Write unit tests and functional tests covering code bundled with the module - see [testing-guide](/topics/testing)
|
||||
* Ensure your code is [localizable](/topics/i18n)
|
||||
@ -120,7 +119,7 @@ to be readable in plain text as well).
|
||||
In return for all your hard work in putting a high-quality module on the site, the SilverStripe project has the following
|
||||
options to support you:
|
||||
|
||||
* Advertising of your module on the http://silverstripe.org/modules/ modules page once it has reached a beta stage and shown
|
||||
* Advertising of your module on the http://addons.silverstripe.org/add-ons modules site once it has reached a beta stage and shown
|
||||
to meet our requirements above.
|
||||
* We might showcase your module on our blog and/or newsletter, when it's first released and/or when a major version with
|
||||
significant new features is released. We'll work with you to publicise it on other blogs too (it helps if you deliver
|
||||
@ -188,7 +187,7 @@ export to a tar.gz.
|
||||
|
||||
* See [Producing OSS: "Announcing Releases"](http://producingoss.com/en/testing-and-releasing.html#release-announcement)
|
||||
* Update your [documentation](module-release-process#documentation) in the sourcecode, wiki and README
|
||||
* Add your release to the [silverstripe.org/modules](http://silverstripe.org/modules) listing
|
||||
* Add your release to the `[silverstripe.org/modules](http://silverstripe.org/modules)` listing
|
||||
* Announce the release on [silverstripe-announce](http://groups.google.com/group/silverstripe-announce). Include a
|
||||
[changelog](module-release-process#changelogs), the download link and instructions for filing bug reports.
|
||||
* If this release is a major release, our [marketing guys](http://silverstripe.com/contact/) will strive to announce it
|
||||
@ -237,4 +236,4 @@ trunk.
|
||||
* [Module Development](/topics/module-development)
|
||||
* [Documentation Guide](contributing/documentation)
|
||||
* [Contributing to SilverStripe](contributing)
|
||||
* [Submit your Module](http://silverstripe.org/modules/manage/add)
|
||||
* [Submit your Module](http://addons.silverstripe.org/add-ons)
|
||||
|
||||
@ -9,7 +9,7 @@ The current maintainer responsible for planning and performing releases is Ingo
|
||||
|
||||
## Release Planning
|
||||
|
||||
Our most up-to-date release plans are typically in the ["framework" milestone](https://github.com/silverstripe/silverstripe-framework/issues/milestones) and ["cms" milestone](https://github.com/silverstripe/silverstripe-cms/issues/milestones).
|
||||
Our most up-to-date release plans are typically in the ["framework" milestones](https://github.com/silverstripe/silverstripe-framework/milestones) and ["cms" milestones](https://github.com/silverstripe/silverstripe-cms/milestones).
|
||||
New features and API changes are typically discussed on the [core
|
||||
mailinglist](http://groups.google.com/group/silverstripe-dev). They are prioritized by the core team as tickets on
|
||||
github.com.
|
||||
@ -94,7 +94,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 [api: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 pre-release version, the target version will either be 3.2 or 4.0,
|
||||
depending on how disruptive the change is.
|
||||
|
||||
@ -51,12 +51,12 @@ You can link to API documentation from within the markup by pseudo-links.
|
||||
These are automatically resolved to the right URL on `http://api.silverstripe.org`.
|
||||
API links are automatically wrapped in `<code>` blocks by the formatter.
|
||||
|
||||
* Link to class: `[api:DataObject]`
|
||||
* Link to static method: `[api:DataObject::has_one()]`
|
||||
* Link to instance method: `[api:DataObject->write()]`
|
||||
* Link to static property: `[api:DataObject::$searchable_fields]`
|
||||
* Link to instance property: `[api:DataObject->changedFields]`
|
||||
* Custom titles: `[my title](api:DataObject)`
|
||||
* Link to class: [api:DataObject]
|
||||
* Link to static method: [api:DataObject::has_one()]
|
||||
* Link to instance method: [api:DataObject->write()]
|
||||
* Link to static property: [api:DataObject::$searchable_fields]
|
||||
* Link to instance property: [api:DataObject->changedFields]
|
||||
* Custom titles: [my title](api:DataObject)
|
||||
|
||||
There's some gotchas:
|
||||
|
||||
@ -112,4 +112,4 @@ Of course, the `docsviewer` code is BSD licensed - we're looking forward to your
|
||||
|
||||
## Related ##
|
||||
|
||||
* [contributing/documentation](contributing/documentation): The doc.silverstripe.org website has certain styling and writing conventions
|
||||
* [contributing/documentation](contributing/documentation): The doc.silverstripe.org website has certain styling and writing conventions
|
||||
|
||||
@ -84,4 +84,4 @@ You can download your work right from Transifex in order to speed up the process
|
||||
* [i18n](/topics/i18n): Developer-level documentation of Silverstripe's i18n capabilities
|
||||
* [contributing/translation](contributing/translation): Information for translators looking to contribute translations of the SilverStripe UI.
|
||||
* [translatable](https://github.com/silverstripe/silverstripe-translatable): DataObject-interface powering the website-content translations
|
||||
* ["Translatable ModelAdmin" module](http://silverstripe.org/translatablemodeladmin-module/): An extension which allows translations of DataObjects inside ModelAdmin
|
||||
* ["Translatable ModelAdmin" module](https://github.com/silverstripe-labs/silverstripe-translatablemodeladmin): An extension which allows translations of DataObjects inside ModelAdmin
|
||||
|
||||
@ -21,16 +21,16 @@ BBCode can be enabled in comments by adding the following to _config.php
|
||||
|
||||
## Supported Tags
|
||||
|
||||
- [b]Bold[/b]
|
||||
- [i]Italics[/i]
|
||||
- [u]Underlined[/u]
|
||||
- [s]Struck-out[/s]
|
||||
- [color=blue]blue text[/color]
|
||||
- [align=right]right aligned[/align]
|
||||
- [code]Code block[/code]
|
||||
- [email]you@yoursite.com[/email]
|
||||
- [email=you@yoursite.com]Email[/email]
|
||||
- [ulist][*]unordered item 1[/ulist]
|
||||
- [img]http://www.website.com/image.jpg[/img]
|
||||
- [url]http://www.website.com/[/url]
|
||||
- [url=http://www.website.com/]Website[/url]
|
||||
- `[b]Bold[/b]`
|
||||
- `[i]Italics[/i]`
|
||||
- `[u]Underlined[/u]`
|
||||
- `[s]Struck-out[/s]`
|
||||
- `[color=blue]blue text[/color]`
|
||||
- `[align=right]right aligned[/align]`
|
||||
- `[code]Code block[/code]`
|
||||
- `[email]you@yoursite.com[/email]`
|
||||
- `[email=you@yoursite.com]Email[/email]`
|
||||
- `[ulist][*]unordered item 1[/ulist]`
|
||||
- `[img]http://www.website.com/image.jpg[/img]`
|
||||
- `[url]http://www.website.com/[/url]`
|
||||
- `[url=http://www.website.com/]Website[/url]`
|
||||
|
||||
@ -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 [api:SiteTree::getCMSFields()]), as well as creating
|
||||
your own data management interfaces through [api: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
|
||||
@ -23,14 +23,14 @@ we're following the principles of "[Progressive Enhancement](http://en.wikipedia
|
||||
where feasible, relying on a comparatively light layer of JavaScript to enhance
|
||||
forms and markup generated on the server. This allows seamless customization of
|
||||
aspects like form fields. We're explaining this philosophy in more detail
|
||||
on our [blog](http://www.silverstripe.org/the-3-0-ui-a-better-framework-for-your-ideas/)).
|
||||
on our [blog](https://www.silverstripe.org/blog/the-3-0-ui-a-better-framework-for-your-ideas/).
|
||||
|
||||
All CSS in the CMS UI is written in the [SCSS language extensions](http://sass-lang.com/)
|
||||
and the [Compass framework](http://compass-style.org/), which helps
|
||||
us maintain expressive and concise style declarations. The files are located in `framework/admin/scss`
|
||||
(and if you have the `cms` module installed, in `cms/scss`), and are compiled to a `css` folder on the
|
||||
same directory path. Changes to the SCSS files can be automatically converted by installing
|
||||
the ["compass" module](http://www.silverstripe.org/compass-module/) for SilverStripe,
|
||||
the ["compass" module](http://addons.silverstripe.org/add-ons/silverstripe/compass/) for SilverStripe,
|
||||
although [installing the compass framework](http://compass-style.org/install/) directly works as well.
|
||||
Each file describes its purpose at the top of the declarations. Note that you can write
|
||||
plain CSS without SCSS for your custom CMS interfaces as well, we just mandate SCSS for core usage.
|
||||
@ -45,20 +45,20 @@ As there's a whole lot of CSS driving the CMS, we have certain best practives ar
|
||||
* Class naming: Use the `cms-` class prefix for major components in the cms interface,
|
||||
and the `ss-ui-` prefix for extensions to jQuery UI. Don't use the `ui-` class prefix, its reserved for jQuery UI built-in styles.
|
||||
* Use jQuery UI's built-in styles where possible, e.g. `ui-widget` for a generic container, or `ui-state-highlight`
|
||||
to highlight a specific component. See the [jQuery UI Theming API](http://jqueryui.com/docs/Theming/API) for a full list.
|
||||
to highlight a specific component. See the [jQuery UI Themeroller](http://jqueryui.com/themeroller/) for a full list.
|
||||
|
||||
See our [system requirements](../installation/server-requirements) for a list of supported browsers.
|
||||
|
||||
## Templates and Controllers
|
||||
|
||||
The CMS backend is handled through the `[api:LeftAndMain]` controller class,
|
||||
The CMS backend is handled through the [api: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 ([api:SecurityAdmin]),
|
||||
a search interface ([api:ModelAdmin]) or an "Add Page" form ([api: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 [api:LeftAndMain::getRecord()] and [api:LeftAndMain::getEditForm()].
|
||||
If you have the `cms` module installed, have a look at [api: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
|
||||
@ -72,13 +72,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 [api: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 [api:LeftAndMain::Tools()] and
|
||||
[api: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.
|
||||
@ -108,7 +108,7 @@ before the form itself is layouted with its sibling panels to avoid incorrect di
|
||||
## Forms
|
||||
|
||||
SilverStripe constructs forms and its fields within PHP,
|
||||
mainly through the `[getCMSFields()](api:DataObject->getCMSFields())` method.
|
||||
mainly through the [api: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>
|
||||
|
||||
@ -134,10 +134,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 [api:Requirements] class, by adding
|
||||
them to [api: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 [api: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.
|
||||
@ -157,7 +157,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 [api:Requirements] API.
|
||||
|
||||
## Ajax Loading and Browser History
|
||||
|
||||
@ -189,10 +189,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 [api:PjaxResponseNegotiator] class.
|
||||
|
||||
Through a custom `X-Pjax` HTTP header, the client can declare which view he's expecting,
|
||||
through identifiers like `CurrentForm` or `Content` (see `[api:LeftAndMain->getResponseNegotiator()]`).
|
||||
through identifiers like `CurrentForm` or `Content` (see [api: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.
|
||||
@ -318,11 +318,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 [api: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 [api:CMSMenu::add_menu_item()]
|
||||
and [api: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
|
||||
@ -338,7 +338,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 [api: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.
|
||||
@ -353,7 +353,7 @@ For more information, see the [Howto: Customize the CMS tree](../howto/customize
|
||||
|
||||
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]`).
|
||||
([api:TreeDropdownField] and [api:TreeMultiselectField]).
|
||||
|
||||
## Related
|
||||
|
||||
|
||||
@ -6,20 +6,20 @@
|
||||
This field is deprecated in favour of the new [GridField](/reference/grid-field) API.
|
||||
</div>
|
||||
|
||||
Shows a group of DataObjects as a (readonly) tabular list (similiar to `[api:TableListField]`.)
|
||||
Shows a group of DataObjects as a (readonly) tabular list (similiar to [api:TableListField].)
|
||||
|
||||
You can specify limits and filters for the resultset by customizing query-settings (mostly the ID-field on the other
|
||||
side of a one-to-many-relationship).
|
||||
|
||||
See `[api:TableListField]` for more documentation on the base-class
|
||||
See [api:TableListField] for more documentation on the base-class
|
||||
|
||||
## Source Input
|
||||
|
||||
See `[api:TableListField]`.
|
||||
See [api:TableListField].
|
||||
|
||||
## Setting Parent/Child-Relations
|
||||
|
||||
`[api:ComplexTableField]` tries to determine the parent-relation automatically by looking at the $has_one property on the listed
|
||||
[api:ComplexTableField] tries to determine the parent-relation automatically by looking at the $has_one property on the listed
|
||||
child, or the record loaded into the surrounding form (see getParentClass() and getParentIdName()). You can force a
|
||||
specific parent relation:
|
||||
|
||||
@ -69,7 +69,7 @@ If you don't want several functions to appear (e.g. no add-link), there's severa
|
||||
* Use `ComplexTableField->setPermissions(array("show","edit"))` to limit the functionality without touching the template
|
||||
(more secure). Possible values are "show","edit", "delete" and "add".
|
||||
|
||||
* Subclass `[api:ComplexTableField]` and override the rendering-mechanism
|
||||
* Subclass [api:ComplexTableField] and override the rendering-mechanism
|
||||
* Use `ComplexTableField->setTemplate()` and `ComplexTableField->setTemplatePopup()` to provide custom templates
|
||||
|
||||
### Customising fields and Requirements in the popup
|
||||
@ -77,7 +77,7 @@ If you don't want several functions to appear (e.g. no add-link), there's severa
|
||||
There are several ways to customise the fields in the popup. Often you would want to display more information in the
|
||||
popup as there is more real-estate for you to play with.
|
||||
|
||||
`[api:ComplexTableField]` gives you several options to do this. You can either
|
||||
[api:ComplexTableField] gives you several options to do this. You can either
|
||||
|
||||
* Pass a FieldList in the constructor.
|
||||
* Pass a String in the constructor.
|
||||
@ -87,7 +87,7 @@ The second will call the String as a method on the source class (Which should re
|
||||
Popup.
|
||||
|
||||
You can also customise Javascript which is loaded for the Lightbox. As Requirements::clear() is called when the popup is
|
||||
instantiated, `[api:ComplexTableField]` will look for a function to gather any specific requirements that you might need on your
|
||||
instantiated, [api:ComplexTableField] will look for a function to gather any specific requirements that you might need on your
|
||||
source class. (e.g. Inline Javascript or styling).
|
||||
|
||||
For this, create a function called "getRequirementsForPopup".
|
||||
@ -120,7 +120,7 @@ You'll have to do something like this in your form:
|
||||
|
||||
You have to hack in an ID on the form, as the CMS forms have this, and front end forms usually do not.
|
||||
|
||||
It's not a perfect solution, but it works relatively well to get a simple `[api:ComplexTableField]` up and running on the front
|
||||
It's not a perfect solution, but it works relatively well to get a simple [api:ComplexTableField] up and running on the front
|
||||
end.
|
||||
|
||||
To come: Make it a lot more flexible so tables can be easily used on the front end. It also needs to be flexible enough
|
||||
@ -132,4 +132,4 @@ Most of the time, you need to override the following methods:
|
||||
|
||||
* ComplexTableField->sourceItems() - querying
|
||||
* ComplexTableField->DetailForm() - form output
|
||||
* ComplexTableField_Popup->saveComplexTableField() - saving
|
||||
* ComplexTableField_Popup->saveComplexTableField() - saving
|
||||
|
||||
@ -5,7 +5,7 @@ opting for "convention over configuration". This page details what that databas
|
||||
|
||||
## Base tables
|
||||
|
||||
Each direct sub-class of `[api:DataObject]` will have its own table.
|
||||
Each direct sub-class of [api:DataObject] will have its own table.
|
||||
|
||||
The following fields are always created.
|
||||
|
||||
@ -36,21 +36,21 @@ data sub-classed objects across **multiple tables**.
|
||||
|
||||
For example, suppose we have the following set of classes:
|
||||
|
||||
* Class `[api:SiteTree]` extends `[api:DataObject]`: Title, Content fields
|
||||
* Class `[api:Page]` extends `[api:SiteTree]`: Abstract field
|
||||
* Class NewsSection extends `[api:SiteTree]`: *No special fields*
|
||||
* Class NewsArticle extend `[api:Page]`: ArticleDate field
|
||||
* Class [api:SiteTree] extends [api:DataObject]: Title, Content fields
|
||||
* Class Page extends [api:SiteTree]: Abstract field
|
||||
* Class NewsSection extends [api:SiteTree]: *No special fields*
|
||||
* Class NewsArticle extends Page: ArticleDate field
|
||||
|
||||
The data for the following classes would be stored across the following tables:
|
||||
|
||||
* `[api:SiteTree]`
|
||||
* [api:SiteTree]
|
||||
* ID: Int
|
||||
* ClassName: Enum('SiteTree', 'Page', 'NewsArticle')
|
||||
* Created: Datetime
|
||||
* LastEdited: Datetime
|
||||
* Title: Varchar
|
||||
* Content: Text
|
||||
* `[api:Page]`
|
||||
* Page
|
||||
* ID: Int
|
||||
* Abstract: Text
|
||||
* NewsArticle
|
||||
@ -59,16 +59,16 @@ The data for the following classes would be stored across the following tables:
|
||||
|
||||
The way it works 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 [api:DataObject]. They are always given a table, whether or not they have
|
||||
special fields. This is called the "base table"
|
||||
* The base table's ClassName field is set to class of the given record. It's an enumeration of all possible
|
||||
sub-classes of the base class (including the base class itself)
|
||||
* Each sub-class of the base object will also be given its own table, *as long as it has custom fields*. In the
|
||||
example above, NewsSection didn't have its own data and 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 [api:SiteTree].
|
||||
|
||||
To retrieve a news article, SilverStripe joins the `[api:SiteTree]`, `[api:Page]` and NewsArticle tables by their ID fields. We use a
|
||||
To retrieve a news article, SilverStripe joins the [api:SiteTree], Page and NewsArticle tables by their ID fields. We use a
|
||||
left-join for robustness; if there is no matching record in Page, we can return a record with a blank Article field.
|
||||
|
||||
## Staging and versioning
|
||||
@ -102,13 +102,13 @@ It **won't** do any of the following
|
||||
|
||||
The information documented in this page is reflected in a few places in the code:
|
||||
|
||||
* `[api:DataObject]`
|
||||
* [api:DataObject]
|
||||
* requireTable() is responsible for specifying the required database schema
|
||||
* instance_get() and instance_get_one() are responsible for generating the database queries for selecting data.
|
||||
* write() is responsible for generating the database queries for writing data.
|
||||
* `[api:Versioned]`
|
||||
* [api:Versioned]
|
||||
* augmentWrite() is responsible for altering the normal database writing operation to handle versions.
|
||||
* augmentQuery() is responsible for altering the normal data selection queries to support versions.
|
||||
* augmentDatabase() is responsible for specifying the altered database schema to support versions.
|
||||
* `[api:MySQLDatabase]`: getNextID() is used when creating new objects; it also handles the mechanics of
|
||||
updating the database to have the required schema.
|
||||
* [api:MySQLDatabase]: getNextID() is used when creating new objects; it also handles the mechanics of
|
||||
updating the database to have the required schema.
|
||||
|
||||
@ -2,14 +2,14 @@
|
||||
|
||||
## Introduction
|
||||
|
||||
Extensions allow for adding additional functionality to a `[api:DataObject]`.
|
||||
Extensions allow for adding additional functionality to a [api:DataObject].
|
||||
|
||||
In some cases, it can be easier to completely replace the used class throughout the core with your custom
|
||||
implementation. Have a look at `[api:Object->useCustomClass()]`.
|
||||
implementation. Have a look at [api:Object::useCustomClass()].
|
||||
|
||||
## Usage
|
||||
|
||||
Your extension will need to be a subclass of `[api:DataExtension]` or the `[api:Extension]` class.
|
||||
Your extension will need to be a subclass of [api:DataExtension] or the [api:Extension] class.
|
||||
|
||||
:::php
|
||||
<?php
|
||||
@ -27,7 +27,7 @@ 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.
|
||||
ForumRole extension to the [api:Member] object.
|
||||
|
||||
|
||||
:::php
|
||||
@ -84,7 +84,7 @@ The `$`fields parameter is passed by reference, as it is an object.
|
||||
### Custom database generation
|
||||
|
||||
Some extensions are designed to transparently add more sophisticated data-collection capabilities to your data object.
|
||||
For example, `[api:Versioned]` adds version tracking and staging to any data object that it is applied to. To do this,
|
||||
For example, [api:Versioned] adds version tracking and staging to any data object that it is applied to. To do this,
|
||||
you need to be able to create additional database tables and fields to keep your state stored in.
|
||||
|
||||
To do this, define an **augmentDatabase()** method on your extension. This will be called when db/build is visited.
|
||||
@ -96,7 +96,7 @@ care of creating, modifying, or leaving tables as required, based on your desire
|
||||
### Custom write queries
|
||||
|
||||
If you have customised the generated database, then you probably want to change the way that writes happen. This is
|
||||
used by `[api:Versioned]` to get an entry written in ClassName_versions whenever an insert/update happens.
|
||||
used by [api:Versioned] to get an entry written in ClassName_versions whenever an insert/update happens.
|
||||
|
||||
To do this, define the **augmentWrite(&$manipulation)** method. This method is passed a manipulation array representing
|
||||
the write about to happen, and is able to amend this as desired, since it is passed by reference.
|
||||
@ -107,21 +107,21 @@ The other queries that you will want to customise are the selection queries, cal
|
||||
Versioned object has code to redirect every request to ClassName_live, if you are browsing the live site.
|
||||
|
||||
To do this, define the **augmentSQL(SQLQuery &$query)** method. Again, the $query object is passed by reference and can
|
||||
be modified as needed by your method. Instead of a manipulation array, we have a `[api:SQLQuery]` object.
|
||||
be modified as needed by your method. Instead of a manipulation array, we have a [api:SQLQuery] object.
|
||||
|
||||
### Additional methods
|
||||
|
||||
The other thing you may want to do with a extension is provide a method that can be called on the `[api:DataObject]` that is
|
||||
being extended. For instance, you may add a publish() method to every `[api:DataObject]` that is extended with `[api:Versioned]`.
|
||||
The other thing you may want to do with a extension is provide a method that can be called on the [api:DataObject] that is
|
||||
being extended. For instance, you may add a publish() method to every [api:DataObject] that is extended with [api:Versioned].
|
||||
|
||||
This is as simple as defining a method called publish() on your extension. Bear in mind, however, that instead of
|
||||
$this, you should be referring to $this->owner.
|
||||
|
||||
* $this = The `[api:DataExtension]` object.
|
||||
* $this->owner = The related `[api:DataObject]` object.
|
||||
* $this = The [api:DataExtension] object.
|
||||
* $this->owner = The related [api:DataObject] object.
|
||||
|
||||
If you want to add your own internal properties, you can add this to the `[api:DataExtension]`, and these will be referred
|
||||
to as `$this->propertyName`. Every `[api:DataObject]` has an associated `[api:DataExtension]` instance for each class that it is
|
||||
If you want to add your own internal properties, you can add this to the [api:DataExtension], and these will be referred
|
||||
to as `$this->propertyName`. Every [api:DataObject] has an associated [api:DataExtension] instance for each class that it is
|
||||
extended by.
|
||||
|
||||
:::php
|
||||
@ -155,4 +155,4 @@ extended by.
|
||||
|
||||
|
||||
## API Documentation
|
||||
`[api:DataExtension]`
|
||||
[api:DataExtension]
|
||||
|
||||
@ -2,7 +2,7 @@
|
||||
|
||||
## Introduction
|
||||
|
||||
The `[api:DataObject]` class represents a single row in a database table,
|
||||
The [api:DataObject] class represents a single row in a database table,
|
||||
following the ["Active Record"](http://en.wikipedia.org/wiki/Active_record_pattern) design pattern.
|
||||
|
||||
## Defining Properties
|
||||
@ -19,7 +19,7 @@ is explained in the ["datamodel" topic](/topics/datamodel).
|
||||
|
||||
In addition to defining how data is persisted, the class can also
|
||||
help with editing it by providing form fields through `DataObject->getCMSFields()`.
|
||||
The resulting `[api:FieldList]` is the centrepiece of many data administration interfaces in SilverStripe.
|
||||
The resulting [api:FieldList] is the centrepiece of many data administration interfaces in SilverStripe.
|
||||
Many customizations of the SilverStripe CMS interface start here,
|
||||
by adding, removing or configuring fields.
|
||||
|
||||
@ -44,7 +44,7 @@ restricting input to numbers, and much more.
|
||||
|
||||
The ORM already has a lot of information about the data represented by a `DataObject`
|
||||
through its `$db` property, so why not use it to create form fields as well?
|
||||
If you call the parent implementation, the class will use `[api:FormScaffolder]`
|
||||
If you call the parent implementation, the class will use [api:FormScaffolder]
|
||||
to provide reasonable defaults based on the property type (e.g. a checkbox field for booleans).
|
||||
You can then further customize those fields as required.
|
||||
|
||||
@ -62,7 +62,7 @@ The `[ModelAdmin](/reference/modeladmin)` class uses this approach to provide
|
||||
data management interfaces with very little custom coding.
|
||||
|
||||
You can also alter the fields of built-in and module `DataObject` classes through
|
||||
your own `[DataExtension](/reference/dataextension)`, and a call to `[api:DataExtension->updateCMSFields()]`.
|
||||
your own `[DataExtension](/reference/dataextension)`, and a call to [api:DataExtension::updateCMSFields()].
|
||||
|
||||
### Searchable Fields
|
||||
|
||||
@ -86,8 +86,8 @@ Example: Simple Definition
|
||||
}
|
||||
|
||||
|
||||
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 additional information
|
||||
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 additional information
|
||||
on `$searchable_fields`:
|
||||
|
||||
:::php
|
||||
@ -99,7 +99,7 @@ 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 both, you can
|
||||
If you assign a single string value, you can set it to be either a [api:FormField] or [api:SearchFilter]. To specify both, you can
|
||||
assign an array:
|
||||
|
||||
:::php
|
||||
@ -146,8 +146,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. 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 [api:DataObject] record. Most common use is
|
||||
their display as table columns, e.g. in the search results of a [api:ModelAdmin] CMS interface.
|
||||
|
||||
Example: Getting predefined summary fields
|
||||
|
||||
@ -195,4 +195,4 @@ To include relations in your summaries, you can use a dot-notation.
|
||||
|
||||
## API Documentation
|
||||
|
||||
`[api:DataObject]`
|
||||
[api:DataObject]
|
||||
|
||||
@ -105,7 +105,7 @@ and/or monthnames are used. After saving, the correct format will be displayed.
|
||||
If you find the jQuery locale file for your chosen locale is missing, the
|
||||
following section will explain how to create one. If you wish to contribute
|
||||
your file to the SilverStripe core, please check out the guide on
|
||||
['contributing code'](http://doc.silverstripe.org/framework/en/trunk/misc/contributing/code).
|
||||
[contributing code](https://docs.silverstripe.org/en/3.0/misc/contributing/code/).
|
||||
|
||||
### 1. Get the Sourcefile
|
||||
|
||||
@ -128,4 +128,4 @@ sensitive`!
|
||||
### 4. Filename
|
||||
|
||||
Use the original jQuery UI filename 'jquery.ui.datepicker-xx.js', where xx
|
||||
stands for the locale.
|
||||
stands for the locale.
|
||||
|
||||
@ -2,42 +2,42 @@
|
||||
|
||||
## Introduction
|
||||
|
||||
`[api:Director]` is the first step in the "execution pipeline". It parses the
|
||||
[api:Director] is the first step in the "execution pipeline". It parses the
|
||||
URL, matching it to one of a number of patterns, and determines the controller,
|
||||
action and any argument to be used. It then runs the controller, which will
|
||||
finally run the viewer and/or perform processing steps.
|
||||
|
||||
## Request processing
|
||||
|
||||
The `[api:Director]` is the entry point in Silverstring Framework for processing
|
||||
a request. You can read through the execution steps in `[api:Director]``::direct()`,
|
||||
The [api:Director] is the entry point in Silverstring Framework for processing
|
||||
a request. You can read through the execution steps in [api:Director::direct()],
|
||||
but in short
|
||||
|
||||
* File uploads are first analysed to remove potentially harmful uploads (this
|
||||
will likely change!)
|
||||
* The `[api:SS_HTTPRequest]` object is created
|
||||
* The [api:SS_HTTPRequest] object is created
|
||||
* The session object is created
|
||||
* The `[api:Injector]` is first referenced, and asks the registered `[api:RequestProcessor]`
|
||||
* The [api:Injector] is first referenced, and asks the registered [api:RequestProcessor]
|
||||
to pre-process the request object. This allows for analysis of the current
|
||||
request, and allow filtering of parameters etc before any of the core of the
|
||||
application executes.
|
||||
* The request is handled and response checked
|
||||
* The `[api:RequestProcessor]` is called to post-process the request to allow
|
||||
* The [api:RequestProcessor] is called to post-process the request to allow
|
||||
further filtering before content is sent to the end user
|
||||
* The response is output
|
||||
|
||||
The framework provides the ability to hook into the request both before and
|
||||
after it is handled to allow developers to bind in their own custom pre- or
|
||||
post- request logic; see the `[api:RequestFilter]` to see how this can be used
|
||||
post- request logic; see the [api:RequestFilter] to see how this can be used
|
||||
to authenticate the request before the request is handled.
|
||||
|
||||
## Routing
|
||||
|
||||
You can influence the way URLs are resolved in the following ways
|
||||
|
||||
1. Adding rules to `[api:Director]` in `<yourproject>/_config/routes.yml`
|
||||
2. Adding rules to `[api:Director]` in `<yourproject>/_config.php (deprecated)
|
||||
3. Adding rules in your extended `[api:Controller]` class via the *$url_handlers*
|
||||
1. Adding rules to [api:Director] in `<yourproject>/_config/routes.yml`
|
||||
2. Adding rules to [api:Director] in `<yourproject>/_config.php (deprecated)
|
||||
3. Adding rules in your extended [api:Controller] class via the *$url_handlers*
|
||||
static variable
|
||||
|
||||
See [controller](/topics/controller) for examples and explanations on how the
|
||||
@ -46,7 +46,7 @@ rules get processed for those methods.
|
||||
|
||||
### Routing Rules
|
||||
|
||||
SilverStripe comes with certain rules which map a URI to a `[api:Controller]`
|
||||
SilverStripe comes with certain rules which map a URI to a [api:Controller]
|
||||
class (e.g. *dev/* -> DevelopmentAdmin). These routes are either stored in
|
||||
a routes.yml configuration file located a `_config` directory or inside a
|
||||
`_config.php` file (deprecated).
|
||||
@ -80,8 +80,8 @@ for $_REQUEST['ajax'].
|
||||
|
||||
## Links
|
||||
|
||||
* See `[api:ModelAsController]` class for details on controller/model-coupling
|
||||
* See [api:ModelAsController] class for details on controller/model-coupling
|
||||
* See [execution-pipeline](/reference/execution-pipeline) for custom routing
|
||||
|
||||
## API Documentation
|
||||
`[api:Director]`
|
||||
[api:Director]
|
||||
|
||||
@ -51,10 +51,10 @@ All requests go through `main.`php, which sets up the environment and then hands
|
||||
|
||||
## Director and URL patterns
|
||||
|
||||
main.php relies on `[api:Director]` to work out which controller should handle this request. `[api:Director]` will instantiate that
|
||||
controller object and then call `[api:Controller::run()]`.
|
||||
main.php relies on [api:Director] to work out which controller should handle this request. [api:Director] will instantiate that
|
||||
controller object and then call [api:Controller::run()].
|
||||
|
||||
In general, the URL is build up as follows: `page/action/ID/otherID` - e.g. http://www.mysite.com/mypage/addToCart/12.
|
||||
In general, the URL is build up as follows: `page/action/ID/otherID` - e.g. `http://www.mysite.com/mypage/addToCart/12`.
|
||||
This will add an object with ID 12 to the cart.
|
||||
|
||||
When you create a function, you can access the ID like this:
|
||||
@ -69,9 +69,9 @@ When you create a function, you can access the ID like this:
|
||||
|
||||
## Controllers and actions
|
||||
|
||||
`[api:Controller]`s are the building blocks of your application.
|
||||
[api:Controller]s are the building blocks of your application.
|
||||
|
||||
**See:** The API documentation for `[api:Controller]`
|
||||
**See:** The API documentation for [api:Controller]
|
||||
|
||||
You can access the following controller-method with /team/signup
|
||||
|
||||
|
||||
@ -1,72 +1,72 @@
|
||||
# Form Field Types
|
||||
|
||||
This is a highlevel overview of available `[api:FormField]` subclasses. An automatically generated list is available through our [API]
|
||||
This is a highlevel overview of available [api:FormField] subclasses. An automatically generated list is available through our [API]
|
||||
|
||||
## 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.
|
||||
* [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.
|
||||
|
||||
## Actions
|
||||
|
||||
* `[api:FormAction]`: Button element for forms, both for `<input type="submit">` and `<button>`.
|
||||
* `[api:ResetFormAction]`: Action that clears all fields on a form.
|
||||
* [api:FormAction]: Button element for forms, both for `<input type="submit">` and `<button>`.
|
||||
* [api:ResetFormAction]: Action that clears all fields on a form.
|
||||
|
||||
## Formatted Input
|
||||
|
||||
* `[api:AjaxUniqueTextField]`: Text field that automatically checks that the value entered is unique for the given set of fields in a given set of tables.
|
||||
* `[api:ConfirmedPasswordField]`: Two masked input fields, checks for matching passwords.
|
||||
* `[api:CountryDropdownField]`: A simple extension to dropdown field, pre-configured to list countries.
|
||||
* `[api:CreditCardField]`: Allows input of credit card numbers via four separate form fields, including generic validation of its numeric values.
|
||||
* `[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]`.
|
||||
* `[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:PhoneNumberField]`: Field for displaying phone numbers. It separates the number, the area code and optionally the country code and extension.
|
||||
* `[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, localized validation.
|
||||
* [api:AjaxUniqueTextField]: Text field that automatically checks that the value entered is unique for the given set of fields in a given set of tables.
|
||||
* [api:ConfirmedPasswordField]: Two masked input fields, checks for matching passwords.
|
||||
* [api:CountryDropdownField]: A simple extension to dropdown field, pre-configured to list countries.
|
||||
* [api:CreditCardField]: Allows input of credit card numbers via four separate form fields, including generic validation of its numeric values.
|
||||
* [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].
|
||||
* [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:PhoneNumberField]: Field for displaying phone numbers. It separates the number, the area code and optionally the country code and extension.
|
||||
* [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, localized validation.
|
||||
|
||||
## Structure
|
||||
|
||||
* `[api:CompositeField]`: Base class for all fields that contain other fields. Uses `<div>` in template, but
|
||||
* [api: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.
|
||||
* `[api:ToggleField]`: ReadonlyField with added toggle-capabilities - will preview the first sentence of the contained text-value, and show the full content by a javascript-switch.
|
||||
* [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.
|
||||
* [api:ToggleField]: ReadonlyField with added toggle-capabilities - will preview the first sentence of the contained text-value, and show the full content by a javascript-switch.
|
||||
|
||||
## Files
|
||||
|
||||
* `[api:FileField]`: Simple file upload dialog.
|
||||
* `[api:UploadField]`: File uploads through HTML5 features, including upload progress, preview and relationship management.
|
||||
* [api:FileField]: Simple file upload dialog.
|
||||
* [api:UploadField]: File uploads through HTML5 features, including upload progress, preview and relationship management.
|
||||
|
||||
## 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>`.
|
||||
* [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>`.
|
||||
|
||||
|
||||
## Utility
|
||||
|
||||
* `[api:DatalessField]` - Base class for fields which add some HTML to the form but don't submit any data or
|
||||
* [api: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]`.
|
||||
* `[api:LabelField]`: Simple label tag. This can be used to add extra text in your forms.
|
||||
* `[api:LiteralField]`: Renders arbitrary HTML into a form.
|
||||
* [api:HeaderField]: Renders a simple HTML header element.
|
||||
* [api:HiddenField].
|
||||
* [api:LabelField]: Simple label tag. This can be used to add extra text in your forms.
|
||||
* [api:LiteralField]: Renders arbitrary HTML into a form.
|
||||
|
||||
@ -182,19 +182,19 @@ Removing a component:
|
||||
:::php
|
||||
$config->removeComponentsByType('GridFieldToolbarHeader');
|
||||
|
||||
For more information, see the [API for GridFieldConfig](http://api.silverstripe.org/3.0/framework/GridFieldConfig.html).
|
||||
For more information, see [api:GridFieldConfig].
|
||||
|
||||
Here is a list of components for generic use:
|
||||
|
||||
- `[api:GridFieldToolbarHeader]`
|
||||
- `[api:GridFieldSortableHeader]`
|
||||
- `[api:GridFieldFilterHeader]`
|
||||
- `[api:GridFieldDataColumns]`
|
||||
- `[api:GridFieldDeleteAction]`
|
||||
- `[api:GridFieldViewButton]`
|
||||
- `[api:GridFieldEditButton]`
|
||||
- `[api:GridFieldPaginator]`
|
||||
- `[api:GridFieldDetailForm]`
|
||||
- [api:GridFieldToolbarHeader]
|
||||
- [api:GridFieldSortableHeader]
|
||||
- [api:GridFieldFilterHeader]
|
||||
- [api:GridFieldDataColumns]
|
||||
- [api:GridFieldDeleteAction]
|
||||
- [api:GridFieldViewButton]
|
||||
- [api:GridFieldEditButton]
|
||||
- [api:GridFieldPaginator]
|
||||
- [api:GridFieldDetailForm]
|
||||
|
||||
## Creating a custom GridFieldComponent
|
||||
|
||||
|
||||
@ -2,14 +2,14 @@
|
||||
|
||||
## Introduction
|
||||
|
||||
Represents an image object through the `[api:Image]` class, inheriting all base functionality from the `[api:File]` class with extra functionality including resizing.
|
||||
Represents an image object through the [api:Image] class, inheriting all base functionality from the [api:File] class with extra functionality including resizing.
|
||||
|
||||
## Usage
|
||||
|
||||
### Managing images through form fields
|
||||
|
||||
Images can be uploaded like any other file, through `[api:FileField]`.
|
||||
More advanced usage is possible through `[api:UploadField]`,
|
||||
Images can be uploaded like any other file, through [api:FileField].
|
||||
More advanced usage is possible through [api:UploadField],
|
||||
which provides thumbnails, a detail view of the image properties,
|
||||
and management of relationships to other DataObject instances.
|
||||
Allows upload of images through limiting file extensions with `setAllowedExtensions()`.
|
||||
@ -107,8 +107,8 @@ For output of an image tag with the image automatically resized to 80px width, y
|
||||
|
||||
### Form Upload
|
||||
|
||||
For usage on a website form, see `[api:FileField]`.
|
||||
If you want to upload images within the CMS, see `[api:UploadField]`.
|
||||
For usage on a website form, see [api:FileField].
|
||||
If you want to upload images within the CMS, see [api:UploadField].
|
||||
|
||||
### Clearing Thumbnail Cache
|
||||
|
||||
@ -122,4 +122,4 @@ image cache.
|
||||
http://www.mysite.com/images/flush
|
||||
|
||||
## API Documentation
|
||||
`[api:Image]`
|
||||
[api:Image]
|
||||
|
||||
@ -2,7 +2,7 @@
|
||||
|
||||
## Introduction
|
||||
|
||||
The `[api:Injector]` class is the central manager of inter-class dependencies
|
||||
The [api:Injector] class is the central manager of inter-class dependencies
|
||||
in the SilverStripe Framework. In its simplest form it can be considered as
|
||||
a replacement for Object::create and singleton() calls, but also offers
|
||||
developers the ability to declare the dependencies a class type has, or
|
||||
@ -181,4 +181,4 @@ classes.
|
||||
|
||||
By default, objects are managed like a singleton, in that there is only one
|
||||
object instance used for a named service, and all references to that service
|
||||
are returned the same object.
|
||||
are returned the same object.
|
||||
|
||||
@ -2,11 +2,11 @@
|
||||
|
||||
## Introduction
|
||||
|
||||
The `[api:Member]` class is used to represent user accounts on a SilverStripe site (including newsletter recipients).
|
||||
The [api: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 [api:Member] class comes with 2 static methods for getting information about the current logged in user.
|
||||
|
||||
**Member::currentUserID()**
|
||||
|
||||
@ -37,11 +37,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 [api:Member] class. It's better to use [api:DataExtension]
|
||||
(see below).
|
||||
</div>
|
||||
|
||||
You can defined subclasses of `[api:Member]` to add extra fields or functionality to the built-in membership system.
|
||||
You can defined subclasses of [api:Member] to add extra fields or functionality to the built-in membership system.
|
||||
|
||||
:::php
|
||||
class MyMember extends Member {
|
||||
@ -52,7 +52,7 @@ You can defined subclasses of `[api:Member]` to add extra fields or functionalit
|
||||
}
|
||||
|
||||
|
||||
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 [api:Object::useCustomClass()] in
|
||||
(project)/_config.php:
|
||||
|
||||
:::php
|
||||
@ -63,8 +63,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 [api:FieldList] object. You should generally start by calling
|
||||
parent::getCMSFields() and manipulate the [api:FieldList] from there.
|
||||
|
||||
:::php
|
||||
public function getCMSFields() {
|
||||
@ -78,11 +78,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 [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
|
||||
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 [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,
|
||||
and another subclass for the same email-address in the address-database.
|
||||
|
||||
## Member Role Extension
|
||||
@ -95,9 +95,9 @@ class. A better way is to use role extensions to add this behaviour.
|
||||
// OR
|
||||
Member::add_role('ForumRole');
|
||||
|
||||
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 [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.
|
||||
things, you should add appropriate [api:Permission::checkMember()] calls to the role's methods.
|
||||
|
||||
:::php
|
||||
class ForumRole extends DataExtension {
|
||||
@ -127,4 +127,4 @@ things, you should add appropriate `[api:Permission::checkMember()]` calls to th
|
||||
|
||||
## API Documentation
|
||||
|
||||
`[api:Member]`
|
||||
[api:Member]
|
||||
|
||||
@ -51,7 +51,7 @@ a search form, as well as get the searched results. Every DataObject can have it
|
||||
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 `[$searchable_fields](api:DataObject::$searchable_fields)`
|
||||
To remove, add or modify searchable fields, define a new [api:DataObject::$searchable_fields]
|
||||
static on your model class (see `[SearchContext](/reference/searchcontext)` docs for details).
|
||||
|
||||
:::php
|
||||
@ -65,14 +65,14 @@ static on your model class (see `[SearchContext](/reference/searchcontext)` docs
|
||||
}
|
||||
|
||||
For a more sophisticated customization, for example configuring the form fields
|
||||
for the search form, override `[api:DataObject->getCustomSearchContext()]` on your model class.
|
||||
for the search form, override [api:DataObject::getCustomSearchContext()] on your model class.
|
||||
|
||||
## Result Columns
|
||||
|
||||
The results are shown in a tabular listing, powered by the `[GridField](/reference/grid-field)`,
|
||||
more specifically the `[api:GridFieldDataColumns]` component.
|
||||
It 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]`.
|
||||
more specifically the [api:GridFieldDataColumns] component.
|
||||
It 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].
|
||||
|
||||
:::php
|
||||
class Product extends DataObject {
|
||||
@ -89,10 +89,10 @@ where you can add or remove columns. To change the title, use `[api:DataObject::
|
||||
|
||||
## Results Customization
|
||||
|
||||
The results are retrieved from `[api:SearchContext->getResults()]`,
|
||||
The results 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 can be customized by additional
|
||||
Results are a [api:DataList] instance, so can be customized by additional
|
||||
SQL filters, joins, etc (see [datamodel](/topics/datamodel) for more info).
|
||||
|
||||
For example, we might want to exclude all products without prices in our sample `MyAdmin` implementation.
|
||||
@ -133,7 +133,7 @@ For example, we might want to have a checkbox which limits search results to exp
|
||||
}
|
||||
}
|
||||
|
||||
To alter how the results are displayed (via `[api:GridField]`), you can also overload the `getEditForm()` method. For example, to add a new component.
|
||||
To alter how the results are displayed (via [api:GridField]), you can also overload the `getEditForm()` method. For example, to add a new component.
|
||||
|
||||
:::php
|
||||
class MyAdmin extends ModelAdmin {
|
||||
@ -148,12 +148,12 @@ To alter how the results are displayed (via `[api:GridField]`), you can also ove
|
||||
|
||||
## Managing Relationships
|
||||
|
||||
Has-one relationships are simply implemented as a `[api:DropdownField]` by default.
|
||||
Has-one relationships are simply implemented as a [api:DropdownField] by default.
|
||||
Consider replacing it with a more powerful interface in case you have many records
|
||||
(through customizing `[api:DataObject->getCMSFields]`).
|
||||
(through customizing [api:DataObject::getCMSFields]).
|
||||
|
||||
Has-many and many-many relationships are usually handled via the `[GridField](/reference/grid-field)` class,
|
||||
more specifically the `[api:GridFieldAddExistingAutocompleter]` and `[api:GridFieldRelationDelete]` components.
|
||||
Has-many and many-many relationships are usually handled via the [GridField](/reference/grid-field) class,
|
||||
more specifically the [api:GridFieldAddExistingAutocompleter] and [api:GridFieldRelationDelete] components.
|
||||
They provide a list/detail interface within a single record edited in your ModelAdmin.
|
||||
|
||||
## Permissions
|
||||
@ -169,19 +169,19 @@ more permission codes through the `ModelAdmin::$required_permission_codes` stati
|
||||
|
||||
## Data Import
|
||||
|
||||
The `ModelAdmin` class provides import of CSV files through the `[api:CsvBulkLoader]` API.
|
||||
The `ModelAdmin` class provides import of CSV files through the [api: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 autodetected. To override with a more specific importer implementation,
|
||||
use the `[api:ModelAdmin::$model_importers] static.
|
||||
use the [api:ModelAdmin::$model_importers] static.
|
||||
|
||||
## Data Export
|
||||
|
||||
Export is also available, although at the moment only to the CSV format,
|
||||
through a button at the end of a results list. You can also export search results.
|
||||
It is handled through the `[api:GridFieldExportButton]` component.
|
||||
It is handled through the [api:GridFieldExportButton] component.
|
||||
|
||||
To customize the exported columns, create a new method called `getExportFields` in your `ModelAdmin`:
|
||||
|
||||
@ -203,7 +203,7 @@ Dot syntax support allows you to select a field on a related `has_one` object.
|
||||
|
||||
Sometimes you'll work with ModelAdmins from other modules, e.g. the product management
|
||||
of an ecommerce module. To customize this, you can always subclass. But there's
|
||||
also another tool at your disposal: The `[api:Extension]` API.
|
||||
also another tool at your disposal: The [api:Extension] API.
|
||||
|
||||
:::php
|
||||
class MyAdminExtension extends Extension {
|
||||
@ -235,8 +235,8 @@ For an introduction how to customize the CMS templates, see our [CMS Architectur
|
||||
|
||||
* [GridField](../reference/grid-field): The UI component powering ModelAdmin
|
||||
* [Dataobject Relationship Management](/tutorials/dataobject-relationship-management)
|
||||
* `[api:SearchContext]`
|
||||
* [genericviews Module](http://silverstripe.org/generic-views-module)
|
||||
* [api:SearchContext]
|
||||
* `[genericviews Module](http://silverstripe.org/generic-views-module)`
|
||||
* [Presentation about ModelAdmin at SupperHappyDevHouse Wellington](http://www.slideshare.net/chillu/modeladmin-in-silverstripe-23)
|
||||
* [Reference: CMS Architecture](../reference/cms-architecture)
|
||||
* [Howto: Extend the CMS Interface](../howto/extend-cms-interface)
|
||||
|
||||
@ -52,7 +52,7 @@ From a block that shows a summary of the page edits if administrator, nothing if
|
||||
|
||||
|
||||
An additional global key is incorporated in the cache lookup. The default value for this is
|
||||
`$CurrentReadingMode, $CurrentUser.ID`, which ensures that the current `[api:Versioned]` state and user ID are
|
||||
`$CurrentReadingMode, $CurrentUser.ID`, which ensures that the current [api: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.
|
||||
|
||||
@ -68,7 +68,7 @@ user does not influence your template content, you can update this key as below;
|
||||
|
||||
Often you want to invalidate a cache when any in a set of objects change, or when the objects in a relationship change.
|
||||
To help 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 [api: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, that's easy
|
||||
|
||||
@ -22,7 +22,7 @@ You can use whatever codes you like, but for the sanity of developers and users,
|
||||
|
||||
## PermissionProvider
|
||||
|
||||
`[api:PermissionProvider]` is an interface which lets you define a method *providePermissions()*. This method should return a
|
||||
[api: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 (see
|
||||
[permissions:codes](/reference/permission)).
|
||||
|
||||
@ -71,4 +71,4 @@ information on request objects.
|
||||
|
||||
|
||||
## API Documentation
|
||||
`[api:Permission]`
|
||||
[api:Permission]
|
||||
|
||||
@ -8,7 +8,7 @@ hardcoding any references in the `<head>`-tag of your template, as it enables a
|
||||
|
||||
## Including inside PHP Code
|
||||
It is common practice to include most Requirements either in the *init()*-method of your [controller](/topics/controller), or
|
||||
as close to rendering as possible (e.g. in `[api:FormField]`
|
||||
as close to rendering as possible (e.g. in [api:FormField])
|
||||
|
||||
:::php
|
||||
Requirements::javascript("cms/javascript/LeftAndMain.js");
|
||||
@ -125,4 +125,4 @@ In your controller's init() function, add:
|
||||
Requirements::set_write_js_to_body(false);
|
||||
|
||||
## API Documentation
|
||||
`[api:Requirements]`
|
||||
[api:Requirements]
|
||||
|
||||
@ -2,13 +2,13 @@
|
||||
|
||||
## Introduction
|
||||
|
||||
`[api:RestfulService]` enables connecting to remote web services which supports REST interface and consume those web services
|
||||
(for example [Flickr](http://www.flickr.com/services/api/), [Youtube](http://code.google.com/apis/youtube/overview.html), Amazon and etc). `[api:RestfulService]` can parse the XML response (sorry no JSON support)
|
||||
[api:RestfulService] enables connecting to remote web services which supports REST interface and consume those web services
|
||||
(for example [Flickr](http://www.flickr.com/services/api/), [Youtube](http://code.google.com/apis/youtube/overview.html), Amazon and etc). [api:RestfulService] can parse the XML response (sorry no JSON support)
|
||||
returned from the web service. Further it supports caching of the response, and you can customize the cache interval.
|
||||
|
||||
To gain the functionality you can either create a new `[api:RestfulService]` object or create a class extending the
|
||||
RestfulService (see [flickrservice](http://silverstripe.org/flickr-module/) and
|
||||
[youtubeservice](http://silverstripe.org/youtube-gallery-module/) modules).
|
||||
To gain the functionality you can either create a new [api:RestfulService] object or create a class extending the
|
||||
RestfulService (see [flickrservice](http://addons.silverstripe.org/add-ons/silverstripe-labs/flickrservice) and
|
||||
[youtubeservice](https://github.com/silverstripe-labs/silverstripe-youtubeservice) modules).
|
||||
|
||||
|
||||
## Examples
|
||||
@ -113,7 +113,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]`
|
||||
If the web service returned an error (for example, API key not available or inadequate parameters) [api:RestfulService]
|
||||
could delgate the error handling to it's descendant class. To handle the errors define a function called errorCatch
|
||||
|
||||
:::php
|
||||
@ -140,9 +140,9 @@ If you want to bypass error handling on your sub-classes you could define that i
|
||||
|
||||
## Other Uses
|
||||
|
||||
### How to use `[api:RestfulService]` to easily embed an RSS feed
|
||||
### How to use [api:RestfulService] to easily embed an RSS feed
|
||||
|
||||
`[api:RestfulService]` can be used to easily embed an RSS feed (since it's also an xml response) from a site
|
||||
[api:RestfulService] can be used to easily embed an RSS feed (since it's also an xml response) from a site
|
||||
such as del.icio.us
|
||||
|
||||
Put something like this code in mysite/code/Page.php inside class Page_Controller
|
||||
@ -175,4 +175,4 @@ Put something like this code in `themes/<your-theme>/templates/Layout/HomePage.s
|
||||
|
||||
|
||||
## API Documentation
|
||||
`[api:RestfulService]`
|
||||
[api:RestfulService]
|
||||
|
||||
@ -2,25 +2,25 @@
|
||||
|
||||
## Introduction
|
||||
|
||||
Generating RSS/Atom-feeds is a matter of rendering a `[api:SS_List]` through
|
||||
the `[api:RSSFeed]` class.
|
||||
Generating RSS/Atom-feeds is a matter of rendering a [api:SS_List] through
|
||||
the [api:RSSFeed] class.
|
||||
|
||||
The `[api:RSSFeed]` class doesn't limit you to generating article based feeds,
|
||||
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
|
||||
any other custom [api: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 its advisable to just create feeds from sub
|
||||
classes of `[api:SiteTree]`.
|
||||
classes of [api:SiteTree].
|
||||
|
||||
If you wish to generate an RSS feed for `[api:DataObject]` instances, ensure they
|
||||
define an AbsoluteLink() method.
|
||||
If you wish to generate an RSS feed for [api:DataObject] instances, ensure they
|
||||
define an `AbsoluteLink()` method.
|
||||
|
||||
## Usage
|
||||
|
||||
:::php
|
||||
RSSFeed::linkToFeed($link, $title)
|
||||
|
||||
This line should go in your `[api:Controller]` subclass in the action you want
|
||||
This line should go in your [api:Controller] subclass in the action you want
|
||||
to include the HTML link.
|
||||
|
||||
:::php
|
||||
@ -34,7 +34,7 @@ to include the HTML link.
|
||||
$authorField
|
||||
);
|
||||
|
||||
Creates a new `[api:RSSFeed]` instance to be returned. The arguments notify
|
||||
Creates a new [api:RSSFeed] instance to be returned. The arguments notify
|
||||
SilverStripe what values to include in the feed.
|
||||
|
||||
## Examples
|
||||
@ -73,7 +73,7 @@ SilverStripe what values to include in the feed.
|
||||
|
||||
### Showing the 10 most recently updated pages
|
||||
|
||||
You can use `[api:RSSFeed]` to easily create a feed showing your latest Page
|
||||
You can use [api:RSSFeed] to easily create a feed showing your latest Page
|
||||
updates. Update mysite/code/Page.php to something like this:
|
||||
|
||||
:::php
|
||||
@ -99,7 +99,7 @@ updates. Update mysite/code/Page.php to something like this:
|
||||
### Rendering DataObjects in a RSSFeed
|
||||
|
||||
DataObjects can be rendered in the feed as well, however, since they aren't explicitly
|
||||
`[api:SiteTree]` subclasses we need to include a function `AbsoluteLink` to allow the
|
||||
[api:SiteTree] subclasses we need to include a function `AbsoluteLink` to allow the
|
||||
RSS feed to link through to the item.
|
||||
|
||||
If the items are all displayed on a single page you may simply hard code the link to
|
||||
@ -162,7 +162,7 @@ unique template (write your own XML in themes/yourtheme/templates/Students.ss)
|
||||
|
||||
## External Sources
|
||||
|
||||
`[api:RSSFeed]` only creates feeds from your own data. We've included the [SimplePie](http://simplepie.org) RSS-parser for
|
||||
[api:RSSFeed] only creates feeds from your own data. We've included the [SimplePie](http://simplepie.org) RSS-parser for
|
||||
accessing feeds from external sources.
|
||||
|
||||
|
||||
@ -172,4 +172,4 @@ accessing feeds from external sources.
|
||||
|
||||
## API Documentation
|
||||
|
||||
* `[api:RSSFeed]`
|
||||
* [api:RSSFeed]
|
||||
|
||||
@ -2,18 +2,18 @@
|
||||
|
||||
## Introduction
|
||||
|
||||
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,
|
||||
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 search parameters and an object class it acts on.
|
||||
|
||||
The default output of a `[api:SearchContext]` is either a `[api:SQLQuery]` object for further refinement, or a
|
||||
`[api:DataObject]` instance.
|
||||
The default output of a [api:SearchContext] is either a [api:SQLQuery] object for further refinement, or a
|
||||
[api:DataObject] instance.
|
||||
|
||||
In case you need multiple contexts, consider namespacing your request parameters by using `FieldList->namespace()` on
|
||||
the $fields constructor parameter.
|
||||
|
||||
`[api:SearchContext]` is mainly used by `[ModelAdmin](/reference/modeladmin)`, our generic data administration interface. Another
|
||||
implementation can be found in generic frontend search forms through the [genericviews](http://silverstripe.org/generic-views-module) module.
|
||||
[api:SearchContext] is mainly used by [api:ModelAdmin], our generic data administration interface. Another
|
||||
implementation can be found in generic frontend search forms through the `[genericviews](http://silverstripe.org/generic-views-module)` module.
|
||||
|
||||
## Usage
|
||||
|
||||
@ -25,7 +25,7 @@ Getting results
|
||||
|
||||
### Defining fields on your DataObject
|
||||
|
||||
See `[api:DataObject::$searchable_fields]`.
|
||||
See [api:DataObject::$searchable_fields].
|
||||
|
||||
### Customizing fields and filters
|
||||
|
||||
@ -180,10 +180,10 @@ Results.PaginationSummary(4) defines how many pages the search will show in the
|
||||
|
||||
## Available SearchFilters
|
||||
|
||||
See `[api:SearchFilter]` API Documentation
|
||||
See [api:SearchFilter] API Documentation
|
||||
|
||||
## API Documentation
|
||||
`[api:SearchContext]`
|
||||
[api:SearchContext]
|
||||
|
||||
## Related
|
||||
|
||||
|
||||
@ -90,4 +90,4 @@ file and add class's as you need them inside that for each report.
|
||||
* More examples.
|
||||
|
||||
## API Documentation
|
||||
`[api:ReportAdmin]`
|
||||
[api:ReportAdmin]
|
||||
|
||||
@ -2,12 +2,12 @@
|
||||
|
||||
## Introduction
|
||||
|
||||
The `[api:SiteConfig]` panel provides a generic interface for managing site wide settings or
|
||||
The [api:SiteConfig] panel provides a generic interface for managing site wide settings or
|
||||
functionality which is used throughout the site. Out of the box it provides 2 fields 'Site Name' and 'Site Tagline'.
|
||||
|
||||
## Accessing `[api:SiteConfig]` Options
|
||||
## Accessing [api:SiteConfig] Options
|
||||
|
||||
You can access `[api:SiteConfig]` options from any SS template by using the function $SiteConfig.FieldName
|
||||
You can access [api:SiteConfig] options from any SS template by using the function $SiteConfig.FieldName
|
||||
|
||||
:::ss
|
||||
$SiteConfig.Title
|
||||
@ -28,7 +28,7 @@ Or if you want to access variables in the PHP you can do
|
||||
$config->Title
|
||||
|
||||
|
||||
## Extending `[api:SiteConfig]`
|
||||
## Extending [api:SiteConfig]
|
||||
|
||||
To extend the options available in the panel you can define your own fields via an Extension.
|
||||
|
||||
@ -54,13 +54,13 @@ Then add a link to your extension in the _config.php file like below.
|
||||
Object::add_extension('SiteConfig', 'CustomSiteConfig');
|
||||
|
||||
|
||||
This tells SilverStripe to add the CustomSiteConfig extension to the `[api:SiteConfig]` class.
|
||||
This tells SilverStripe to add the CustomSiteConfig extension to the [api:SiteConfig] class.
|
||||
|
||||
After adding those two pieces of code, rebuild your database by visiting http://yoursite.com/dev/build and then reload
|
||||
After adding those two pieces of code, rebuild your database by visiting `http://yoursite.com/dev/build` and then reload
|
||||
the admin interface. You may need to reload it with a ?flush=1 on the end.
|
||||
|
||||
You can define as many extensions for `[api:SiteConfig]` as you need. For example if you are developing a module you can define
|
||||
You can define as many extensions for [api:SiteConfig] as you need. For example if you are developing a module you can define
|
||||
your own global settings for the dashboard.
|
||||
|
||||
## API Documentation
|
||||
`[api:SiteConfig]`
|
||||
[api:SiteConfig]
|
||||
|
||||
@ -36,7 +36,7 @@ might consist of more than one *URLSegment*).
|
||||
|
||||
### Versioning
|
||||
|
||||
The `SiteTree` class automatically has an extension applied to it: `[Versioned](api:Versioned)`.
|
||||
The `SiteTree` class automatically has an extension applied to it: [api:Versioned].
|
||||
This provides the basis for the CMS to operate on different stages,
|
||||
and allow authors to save their changes without publishing them to
|
||||
website visitors straight away.
|
||||
@ -67,7 +67,7 @@ Stage operations:
|
||||
* `$page->doRestoreToStage()`: Restore the content in the active copy of this SiteTree page to the stage site.
|
||||
|
||||
|
||||
Hierarchy operations (defined on `[api:Hierarchy]`:
|
||||
Hierarchy operations (defined on [api:Hierarchy]):
|
||||
|
||||
* `$page->liveChildren()`: Return results only from live table
|
||||
* `$page->stageChildren()`: Return results from the stage table
|
||||
@ -139,4 +139,4 @@ when navigating the tree or adding a new page:
|
||||
|
||||
You can also add custom "badges" to each page in the tree,
|
||||
which denote status. Built-in examples are "Draft" and "Deleted" flags.
|
||||
This is detailed in the ["Customize the CMS Tree" howto](/howto/customize-cms-tree).
|
||||
This is detailed in the ["Customize the CMS Tree" howto](/howto/customize-cms-tree).
|
||||
|
||||
@ -69,7 +69,7 @@ how to sanitize user input before using it in SQL queries.
|
||||
echo $row['BirthYear'];
|
||||
}
|
||||
|
||||
The result is an array lightly wrapped in a database-specific subclass of `[api:Query]`.
|
||||
The result is an array lightly wrapped in a database-specific subclass of [api:Query].
|
||||
This class implements the *Iterator*-interface, and provides convenience-methods for accessing the data.
|
||||
|
||||
### DELETE
|
||||
@ -139,5 +139,5 @@ An alternative approach would be a custom getter in the object definition.
|
||||
## Related
|
||||
|
||||
* [datamodel](/topics/datamodel)
|
||||
* `[api:DataObject]`
|
||||
* [api:DataObject]
|
||||
* [database-structure](database-structure)
|
||||
|
||||
@ -5,7 +5,7 @@
|
||||
Many sites get too much traffic to justify dynamically sending every request. Caching is needed. Static Publishing
|
||||
will generate static versions of your content (HTML) that can be served without ever hitting PHP or the Database.
|
||||
|
||||
See `[api:StaticExporter]` for a less flexible, but easier way of building a local static cache from all of
|
||||
See [api:StaticExporter] for a less flexible, but easier way of building a local static cache from all of
|
||||
your pages.
|
||||
|
||||
See [Partial-Caching](partial-caching) for a much more flexible way of building in caching without statically delivering
|
||||
@ -116,8 +116,7 @@ Put this in mysite/_config.php. This will create static content in a "cache/" s
|
||||
* Put this into your .htaccess. It will serve requests from the cache, statically, if the cache file exists. Replace
|
||||
**sitedir** with the a subdirectory that you would like to serve the site from (for example, in your dev environment).
|
||||
|
||||
[View .htaccess
|
||||
example](http://open.silverstripe.com/browser/modules/cms/trunk/code/staticpublisher/htaccess_example_rsyncsingleserver)
|
||||
`[View .htaccess example](http://open.silverstripe.com/browser/modules/cms/trunk/code/staticpublisher/htaccess_example_rsyncsingleserver)`
|
||||
|
||||
* We use a simple PHP script, static-main.php, to control cache lookup. This makes the .htaccess update simpler.
|
||||
|
||||
@ -232,8 +231,7 @@ tutorial](http://www.csua.berkeley.edu/~ranga/notes/ssh_nopass.html tutorial)).
|
||||
It will serve requests from the cache, statically, if the cache file exists. Replace **sitedir** with the a
|
||||
subdirectory that you would like to serve the site from (for example, in your dev environment).
|
||||
|
||||
[View .htaccess
|
||||
example](http://open.silverstripe.com/browser/modules/cms/trunk/code/staticpublisher/htaccess_example_rsyncmultiservers)
|
||||
`[View .htaccess example](http://open.silverstripe.com/browser/modules/cms/trunk/code/staticpublisher/htaccess_example_rsyncmultiservers)`
|
||||
|
||||
## Cache Control
|
||||
|
||||
@ -251,13 +249,12 @@ To enable cache control, specify "php" instead of "html" in the RsyncMultiHostPu
|
||||
|
||||
And use this slightly different .htaccess file. Make sure that index.php can be used as a directory index!
|
||||
|
||||
[View .htaccess
|
||||
example](http://open.silverstripe.com/browser/modules/cms/trunk/code/staticpublisher/htaccess_example_rsyncwithphp)
|
||||
`[View .htaccess example](http://open.silverstripe.com/browser/modules/cms/trunk/code/staticpublisher/htaccess_example_rsyncwithphp)`
|
||||
|
||||
## Deployment
|
||||
|
||||
Once you've set up your rewrite rules and defined which pages need caching, you can build the static HTML files. This is
|
||||
done by the `[api:RebuildStaticCacheTask]`
|
||||
done by the [api:RebuildStaticCacheTask]
|
||||
|
||||
Execution via URL
|
||||
|
||||
@ -276,8 +273,8 @@ the cache.
|
||||
|
||||
## Related
|
||||
|
||||
* `[api:StaticExporter]`
|
||||
* [api:StaticExporter]
|
||||
* [Partial-Caching](partial-caching)
|
||||
|
||||
## API Documentation
|
||||
* `[api:StaticPublisher]`
|
||||
* [api:StaticPublisher]
|
||||
|
||||
@ -2,10 +2,10 @@
|
||||
|
||||
## Introduction
|
||||
|
||||
`[api:TableField]` behaves in the same manner as `[api:TableListField]`, however allows the editing of existing and adding of
|
||||
[api:TableField] behaves in the same manner as [api:TableListField], however allows the editing of existing and adding of
|
||||
new rows. The data is saved back by the surrounding form-saving (mostly EditForm->save).
|
||||
|
||||
See `[api:TableListField]` for more documentation on the base-class
|
||||
See [api:TableListField] for more documentation on the base-class
|
||||
|
||||
## Usage
|
||||
|
||||
@ -44,7 +44,7 @@ is created.
|
||||
|
||||
### Row Transformation
|
||||
|
||||
You can apply a `[api:FormTransformation]` to any given field,
|
||||
You can apply a [api:FormTransformation] to any given field,
|
||||
based on a eval()ed php-rule. You can access all columns on the generated DataObjects here.
|
||||
|
||||
:::php
|
||||
@ -59,23 +59,23 @@ based on a eval()ed php-rule. You can access all columns on the generated DataOb
|
||||
### Required Fields
|
||||
|
||||
Due to the nested nature of this fields dataset, you can't set any required columns as usual with the
|
||||
`[api:RequiredFields]`** on the TableField-instance for this.
|
||||
Note: You still have to attach some form of `[api:Validator]` to the form to trigger any validation on this field.
|
||||
[api:RequiredFields]** on the TableField-instance for this.
|
||||
Note: You still have to attach some form of [api:Validator] to the form to trigger any validation on this field.
|
||||
|
||||
|
||||
### Nested Table Fields
|
||||
|
||||
When you have `[api:TableField]` inside a `[api:ComplexTableField]`, the parent ID may not be known in your
|
||||
getCMSFields() method. In these cases, you can set a value to '$RecordID' in your `[api:TableField]` extra data, and this
|
||||
When you have [api:TableField] inside a [api:ComplexTableField], the parent ID may not be known in your
|
||||
getCMSFields() method. In these cases, you can set a value to '$RecordID' in your [api:TableField] extra data, and this
|
||||
will be populated with the newly created record id upon save.
|
||||
|
||||
## Known Issues
|
||||
|
||||
* A `[api:TableField]` doesn't reload any submitted form-data if the saving is interrupted by a failed validation. After
|
||||
refreshing the form with the validation-errors, the `[api:TableField]` will be blank again.
|
||||
* You can't add **visible default data** to columns in a `[api:TableField]`, please use *setExtraData*
|
||||
* A [api:TableField] doesn't reload any submitted form-data if the saving is interrupted by a failed validation. After
|
||||
refreshing the form with the validation-errors, the [api:TableField] will be blank again.
|
||||
* You can't add **visible default data** to columns in a [api:TableField], please use *setExtraData*
|
||||
|
||||
|
||||
## API Documentation
|
||||
|
||||
`[api:TableField]`
|
||||
[api:TableField]
|
||||
|
||||
@ -6,13 +6,13 @@
|
||||
This field is deprecated in favour of the new [GridField](/reference/grid-field) API.
|
||||
</div>
|
||||
|
||||
Form field that embeds a list of `[api:DataObject]`s into a form, such as a member list or a file list.
|
||||
Form field that embeds a list of [api:DataObject]s into a form, such as a member list or a file list.
|
||||
Provides customizeable columns, record-deletion by ajax, paging, sorting, CSV-export, printing, input by
|
||||
`[api:DataObject]` or raw SQL.
|
||||
[api:DataObject] or raw SQL.
|
||||
|
||||
## Example
|
||||
|
||||
Here's an example of a full featured `[api:TableListField]` implementation. It features editing members in the database
|
||||
Here's an example of a full featured [api:TableListField] implementation. It features editing members in the database
|
||||
directly as a button on each record, as well as filtering, and sorting. It also makes use of the 'export' permission,
|
||||
allowing export of data as a CSV.
|
||||
|
||||
@ -94,7 +94,7 @@ For more information on each of the features used in the example, you can read b
|
||||
$customCsvQuery->select[] = "CONCAT(col1,col2) AS MyCustomSQLColumn";
|
||||
$myTableListField->setCustomCsvQuery($customQuery);
|
||||
|
||||
`[api:TableListField]` also tries to resolve Component-relations(has_one, has_many) and custom getters automatically:
|
||||
[api:TableListField] also tries to resolve Component-relations(has_one, has_many) and custom getters automatically:
|
||||
|
||||
:::php
|
||||
$myTableListField = new TableListField(
|
||||
@ -143,7 +143,7 @@ Example (sorting by "FirstName" column):
|
||||
);
|
||||
|
||||
|
||||
If you want to sort by custom getters in your `[api:DataObject]`, please reformulate them to a custom SQL column. This
|
||||
If you want to sort by custom getters in your [api:DataObject], please reformulate them to a custom SQL column. This
|
||||
restriction is needed to avoid performance-hits by caching and sorting potentially large datasets on PHP-level.
|
||||
|
||||
### Casting
|
||||
@ -159,7 +159,7 @@ Column-values can be casted, based on the casting-types available through DBObje
|
||||
|
||||
### Permissions
|
||||
|
||||
Permissions vary in different `[api:TableListField]`-implementations, and are evaluated in the template.
|
||||
Permissions vary in different [api:TableListField]-implementations, and are evaluated in the template.
|
||||
By default, all listed permissions are enabled.
|
||||
|
||||
:::php
|
||||
@ -241,7 +241,7 @@ implement averages etc.
|
||||
)
|
||||
);
|
||||
|
||||
In `[api:TableListField]`-implementation, these summaries also react to changes in input-fields by javascript.
|
||||
In [api:TableListField]-implementation, these summaries also react to changes in input-fields by javascript.
|
||||
Available methods:
|
||||
|
||||
* sum
|
||||
@ -249,7 +249,7 @@ Available methods:
|
||||
|
||||
### Grouping
|
||||
|
||||
Used to group by a specific column in the `[api:DataObject]` and create partial summaries.
|
||||
Used to group by a specific column in the [api:DataObject] and create partial summaries.
|
||||
Please use only together with addSummary().
|
||||
(Automatically disables sorting).
|
||||
|
||||
@ -261,7 +261,7 @@ Please use only together with addSummary().
|
||||
|
||||
### Custom Sorting
|
||||
|
||||
Please subclass `[api:TableListField]` to implement custom sorting, following the naming-convention
|
||||
Please subclass [api:TableListField] to implement custom sorting, following the naming-convention
|
||||
"`colFunction_<yourFunctionName>`".
|
||||
|
||||
:::php
|
||||
@ -289,4 +289,4 @@ You can exchange the used template, e.g. to change applied CSS-classes or the HT
|
||||
|
||||
## API Documentation
|
||||
|
||||
`[api:TableListField]`
|
||||
[api:TableListField]
|
||||
|
||||
@ -240,8 +240,8 @@ current position in the list and iteration:
|
||||
|
||||
### 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]`
|
||||
`<% loop %>` statements iterate over a [api:DataList] instance. As the
|
||||
template has access to the list object, templates can call [api:DataList]
|
||||
functions. For instance, see the following examples:
|
||||
|
||||
Providing a custom sort.
|
||||
@ -417,7 +417,7 @@ returns the number of items in the $Children collection.
|
||||
## Pagination
|
||||
|
||||
Lists can be paginated, and looped over to generate pagination. For this to
|
||||
work, the list needs to be wrapped in a `[api:PaginatedList]`. The process is
|
||||
work, the list needs to be wrapped in a [api:PaginatedList]. The process is
|
||||
explained in detail on the ["pagination" howto](/howto/pagination).
|
||||
|
||||
The list is split up in multiple "pages", each . Note that "page" is this context
|
||||
@ -441,7 +441,7 @@ By default, values are escaped as `XML`, which is equivalent to `HTML` for this
|
||||
There's some exceptions to this rule, see the ["security" topic](/topics/security).
|
||||
|
||||
In case you want to explicitly allow unescaped HTML input,
|
||||
the property can be cast as `[api:HTMLText]`.
|
||||
the property can be cast as [api:HTMLText].
|
||||
The following example takes the `Content` field in a `SiteTree` class,
|
||||
which is of this type. It forces the content into an explicitly escaped format.
|
||||
|
||||
@ -449,7 +449,7 @@ which is of this type. It forces the content into an explicitly escaped format.
|
||||
$Content.XML // transforms e.g. "<em>alert</em>" to "<em>alert</em>"
|
||||
|
||||
Apart from value formatting, there's many methods to transform them as well,
|
||||
For example, the built in `$Now` placeholder is an instance of `[api:Date]`,
|
||||
For example, the built in `$Now` placeholder is an instance of [api:Date],
|
||||
and returns the current date in a standard system format.
|
||||
Since its an object, you can use the helper methods to return other formats:
|
||||
|
||||
@ -528,8 +528,8 @@ Will give you the ability to call `$MyCustomValue` from anywhere in your templat
|
||||
I've got one thing to say to you: <i>$MyCustomValue</i>
|
||||
// output "I've got one thing to say to you: <i>Hi, this is my site</i>"
|
||||
|
||||
Your function could return a single value as above or it could be a subclass of `[api:ArrayData]` for example a
|
||||
`[api:DataObject]` with many values then each of these could be accessible via a control loop
|
||||
Your function could return a single value as above or it could be a subclass of [api:ArrayData] for example a
|
||||
[api:DataObject] with many values then each of these could be accessible via a control loop
|
||||
|
||||
:::php
|
||||
// ...
|
||||
@ -591,9 +591,9 @@ This is all very well and good, but how do the templates actually get called?
|
||||
|
||||
Templates do nothing on their own. Rather, they are used to render *a particular object*. All of the `<% if %>`, `<%control %>`,
|
||||
and variable codes are methods or parameters that are called *on that object*. All that is necessary is
|
||||
that the object is an instance of `[api:ViewableData]` (or one of its subclasses).
|
||||
that the object is an instance of [api:ViewableData] (or one of its subclasses).
|
||||
|
||||
The key is `[api:ViewableData::renderWith()]`. This method is passed a For example, within the controller's default action,
|
||||
The key is [api:ViewableData::renderWith()]. This method is passed a For example, within the controller's default action,
|
||||
there is an instruction of the following sort:
|
||||
|
||||
:::php
|
||||
@ -603,7 +603,7 @@ there is an instruction of the following sort:
|
||||
Here's what this line does:
|
||||
|
||||
* First `renderWith()` constructs a new object: `$template = new SSViewer("TemplateName");`
|
||||
* `[api:SSViewer]` will take the content of `TemplateName.ss`, and turn it into PHP code.
|
||||
* [api:SSViewer] will take the content of `TemplateName.ss`, and turn it into PHP code.
|
||||
* Then `renderWith()` passes the controller to `$template->process($controller);`
|
||||
* `SSViewer::process()` will execute the PHP code generated from `TemplateName.ss` and return the results.
|
||||
|
||||
@ -613,7 +613,7 @@ Here's what this line does:
|
||||
available template name.
|
||||
|
||||
Below is an example of how to implement renderWith. In the example below the page is rendered using the myAjaxTemplate
|
||||
if the page is called by an ajax function (using `[api:Director::is_ajax()]`). Note that the index function is called by
|
||||
if the page is called by an ajax function (using [api:Director::is_ajax()]). Note that the index function is called by
|
||||
default if it exists and there is no action in the url parameters.
|
||||
|
||||
:::php
|
||||
@ -639,7 +639,7 @@ default if it exists and there is no action in the url parameters.
|
||||
Fragment links are links with a "#" in them. A frequent use-case is to use fragment links to point to different
|
||||
sections of the current page. For example, we might have this in our template.
|
||||
|
||||
For, example, we might have this on http://www.example.com/my-long-page/
|
||||
For, example, we might have this on `http://www.example.com/my-long-page/`
|
||||
|
||||
:::ss
|
||||
<ul>
|
||||
@ -649,8 +649,8 @@ For, example, we might have this on http://www.example.com/my-long-page/
|
||||
|
||||
|
||||
So far, so obvious. However, things get tricky because of we have set our `<base>` tag to point to the root of your
|
||||
site. So, when you click the first link you will be sent to http://www.example.com/#section1 instead of
|
||||
http://www.example.com/my-long-page/#section1
|
||||
site. So, when you click the first link you will be sent to `http://www.example.com/#section1` instead of
|
||||
`http://www.example.com/my-long-page/#section1`
|
||||
|
||||
In order to prevent this situation, the SSViewer template renderer will automatically rewrite any fragment link that
|
||||
doesn't specify a URL before the fragment, prefixing the URL of the current page. For our example above, the following
|
||||
@ -678,9 +678,9 @@ you can use any public API on those classes, and [extend](/reference/dataextensi
|
||||
with your own. To get an overview on what's available to you,
|
||||
we recommend that you dive into the API docs for the following classes:
|
||||
|
||||
* `[api:Controller]`: Generic controller class
|
||||
* `[api:DataObject]`: Generic model class
|
||||
* `[api:ViewableData]`: Underlying object class for pretty much anything displayable
|
||||
* [api:Controller]: Generic controller class
|
||||
* [api:DataObject]: Generic model class
|
||||
* [api:ViewableData]: Underlying object class for pretty much anything displayable
|
||||
|
||||
## Designing reusable templates
|
||||
|
||||
@ -702,7 +702,7 @@ includes, rather than entire templates.
|
||||
|
||||
## Related
|
||||
|
||||
* [Built in page controls](/reference/built-in-page-controls)
|
||||
* `[Built in page controls](/reference/built-in-page-controls)`
|
||||
* [Page Type Templates](/topics/page-type-templates)
|
||||
* [Typography](/reference/typography)
|
||||
* [Themes](/topics/themes)
|
||||
|
||||
@ -88,7 +88,7 @@ OtherContent:
|
||||
### Removing the typography class
|
||||
|
||||
Sometimes, it's not enough to add a class, you also want to remove the typography class. You can use the
|
||||
`[api:HTMLEditorField]` method setCSSClass.
|
||||
[api:HTMLEditorField] method setCSSClass.
|
||||
|
||||
This example sets another CSS class typographybis:
|
||||
|
||||
@ -103,4 +103,4 @@ This example sets another CSS class typographybis:
|
||||
}
|
||||
|
||||
|
||||
**Note:** This functionality will be available in the version 2.0.2 of the CMS.
|
||||
**Note:** This functionality will be available in the version 2.0.2 of the CMS.
|
||||
|
||||
@ -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](/topics/debugging), 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 [api:HTTPRequest] to [api:Controller] to Template Rendering |
|
||||
|
||||
## Classes and Objects
|
||||
|
||||
@ -65,9 +65,9 @@ You can set an URL to redirect back to after a [Security](/topics/security) acti
|
||||
|
||||
| Site URL | | Action |
|
||||
| -------- | | ------ |
|
||||
| http://yoursite.com**/dev/build** | | Rebuild the entire database and manifest, see below for additional URL Variables |
|
||||
| http://yoursite.com**/admin/pages/publishall/** | | Publish all pages on the site |
|
||||
| http://yoursite.com**/anypage/images/flush** | | Creates new images for the page by deleting the resized ones and going back to the original to create new resized one |
|
||||
| **http://yoursite.com/dev/build** | | Rebuild the entire database and manifest, see below for additional URL Variables |
|
||||
| **http://yoursite.com/admin/pages/publishall/** | | Publish all pages on the site |
|
||||
| **http://yoursite.com/anypage/images/flush** | | Creates new images for the page by deleting the resized ones and going back to the original to create new resized one |
|
||||
|
||||
### /dev/build
|
||||
|
||||
|
||||
@ -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 [api: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 [api:Director] rule to the
|
||||
[api:CMSMain] controller (see [api: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 [api:LeftAndMain]. It's in [api: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.
|
||||
[api: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 [api:LeftAndMain]
|
||||
|
||||
@ -4,14 +4,14 @@
|
||||
|
||||
The framework uses caches to store infrequently changing values.
|
||||
By default, the storage mechanism is simply the filesystem, although
|
||||
other cache backends can be configured. All caches use the `[api:SS_Cache]` API.
|
||||
other cache backends can be configured. All caches use the [api:SS_Cache] API.
|
||||
|
||||
The most common caches are manifests of various resources:
|
||||
|
||||
* PHP class locations (`[api:SS_ClassManifest]`)
|
||||
* Template file locations and compiled templates (`[api:SS_TemplateManifest]`)
|
||||
* Configuration settings from YAML files (`[api:SS_ConfigManifest]`)
|
||||
* Language files (`[api:i18n]`)
|
||||
* PHP class locations ([api:SS_ClassManifest])
|
||||
* Template file locations and compiled templates ([api:SS_TemplateManifest])
|
||||
* Configuration settings from YAML files ([api:SS_ConfigManifest])
|
||||
* Language files ([api:i18n])
|
||||
|
||||
Flushing the various manifests is performed through a GET
|
||||
parameter (`flush=1`). Since this action requires more server resources than normal requests,
|
||||
@ -23,4 +23,4 @@ executing the action is limited to the following cases when performed via a web
|
||||
|
||||
## Custom Caches
|
||||
|
||||
See `[api:SS_Cache]`.
|
||||
See [api:SS_Cache].
|
||||
|
||||
@ -297,11 +297,11 @@ 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
|
||||
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.
|
||||
|
||||
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
|
||||
as a module by the [api:ManifestBuilder], which is required for features such as autoloading of classes and template
|
||||
detection to work.
|
||||
|
||||
## _config.php
|
||||
@ -359,12 +359,12 @@ Some constants are user-defineable within *_ss_environment.php*.
|
||||
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
|
||||
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.
|
||||
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 principles, 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`)
|
||||
- Group-related configuration like [api:HTMLEditorField] settings can be found in the "Security" section (`admin/security`)
|
||||
- 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)
|
||||
|
||||
## _ss_environment.php
|
||||
@ -374,8 +374,8 @@ See [environment-management](/topics/environment-management).
|
||||
|
||||
## User-level: Member-object
|
||||
|
||||
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.
|
||||
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.
|
||||
|
||||
## Permissions
|
||||
|
||||
@ -396,7 +396,7 @@ through the [commandline](../topics/commandline), where configuration defaults f
|
||||
SilverStripe can request more resources through `increase_memory_limit_to()` and `increase_time_limit_to()`.
|
||||
If you are concerned about resource usage on a dedicated server (without restrictions imposed through shared hosting providers), you can set a hard limit to these increases through
|
||||
`set_increase_memory_limit_max()` and `set_increase_time_limit_max()`.
|
||||
These values will just be used for specific scripts (e.g. `[api:Filesystem::sync()]`),
|
||||
These values will just be used for specific scripts (e.g. [api:Filesystem::sync()]),
|
||||
to raise the limits for all executed scripts please use `ini_set('memory_limit', <value>)`
|
||||
and `ini_set('max_execution_time', <value>)` in your own `_config.php`.
|
||||
|
||||
|
||||
@ -5,7 +5,7 @@ actions and url handling of aspects of your SilverStripe site.
|
||||
|
||||
## Usage
|
||||
|
||||
The following example is for a simple `[api:Controller]` class. If you're using
|
||||
The following example is for a simple [api:Controller] class. If you're using
|
||||
the cms module and looking at Page_Controller instances you won't need to setup
|
||||
your own routes since the cms module handles these routes.
|
||||
|
||||
@ -140,10 +140,10 @@ permission checks.
|
||||
|
||||
## URL Handling
|
||||
|
||||
In the above example the URLs were configured using the `[api:Director]` rules
|
||||
In the above example the URLs were configured using the [api:Director] rules
|
||||
in the **routes.yml** file. Alternatively you can specify these in your
|
||||
Controller class via the **$url_handlers** static array (which gets processed
|
||||
by the `[api:RequestHandler]`).
|
||||
by the [api:RequestHandler]).
|
||||
|
||||
This is useful when you want to subvert the fixed action mapping of `fastfood/order/*`
|
||||
to the function **order**. In the case below we also want any orders coming
|
||||
@ -160,7 +160,7 @@ through `/fastfood/drivethrough/` to use the same order function.
|
||||
|
||||
## URL Patterns
|
||||
|
||||
The `[api:RequestHandler]` class will parse all rules you specify against the
|
||||
The [api:RequestHandler] class will parse all rules you specify against the
|
||||
following patterns.
|
||||
|
||||
**A rule must always start with alphabetical ([A-Za-z]) characters or a $Variable
|
||||
@ -195,7 +195,7 @@ You can use the `debug_request=1` switch from the [urlvariabletools](/reference/
|
||||
|
||||
Controllers facilitate HTTP redirection.
|
||||
|
||||
Note: These methods have been formerly located on the `[api:Director]` class.
|
||||
Note: These methods have been formerly located on the [api:Director] class.
|
||||
|
||||
* `redirect("action-name")`: If there's no slash in the URL passed to redirect, then it is assumed that you want to go to a different action on the current controller.
|
||||
* `redirect("relative/url")`: If there is a slash in the URL, it's taken to be a normal URL. Relative URLs
|
||||
@ -208,10 +208,10 @@ either `301` for permanent redirects, or `302` for temporary redirects (default)
|
||||
|
||||
## API Documentation
|
||||
|
||||
`[api:Controller]`
|
||||
[api:Controller]
|
||||
|
||||
## Links
|
||||
|
||||
* `[api:Director]` class
|
||||
* [api:Director] class
|
||||
* [execution-pipeline](/reference/execution-pipeline)
|
||||
* [URL Handling in Controllers](http://maetl.net/silverstripe-url-handling) by maetl
|
||||
|
||||
@ -89,6 +89,6 @@ See [typography](/reference/typography) for more information.
|
||||
## Related ##
|
||||
|
||||
* [javascript](javascript)
|
||||
* ["Compass" module](http://silverstripe.org/compass-module/): Allows writing CSS in SASS/LESS syntax, with better code management through mixins, includes and variables
|
||||
* ["Compass" module](https://github.com/silverstripe-labs/silverstripe-compass): Allows writing CSS in SASS/LESS syntax, with better code management through mixins, includes and variables
|
||||
* [Reference: CMS Architecture](../reference/cms-architecture)
|
||||
* [Howto: Extend the CMS Interface](../howto/extend-cms-interface)
|
||||
|
||||
@ -1,26 +1,26 @@
|
||||
# Data Types and Casting
|
||||
|
||||
Properties on any SilverStripe object can be type casted automatically,
|
||||
by transforming its scalar value into an instance of the `[api:DBField]` class,
|
||||
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]` type, which has a `FirstSentence()` method to retrieve the first
|
||||
a [api:Text] type, which has a `FirstSentence()` method to retrieve the first
|
||||
sentence in a longer piece of text.
|
||||
|
||||
## 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 2 megabytes, 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 2 megabytes, 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
|
||||
* [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 2 megabytes, 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 2 megabytes, 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
|
||||
|
||||
## Casting arbitrary values
|
||||
|
||||
@ -31,7 +31,7 @@ from one value to another, e.g. to round a number.
|
||||
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 sophisticated helpers,
|
||||
The power of [api:DBField] comes with its more sophisticated helpers,
|
||||
like showing the time difference to the current date:
|
||||
|
||||
:::php
|
||||
@ -39,7 +39,7 @@ like showing the time difference to the current date:
|
||||
|
||||
## Casting ViewableData
|
||||
|
||||
Most objects in SilverStripe extend from `[api:ViewableData]`,
|
||||
Most objects in SilverStripe extend from [api:ViewableData],
|
||||
which means they know how to present themselves in a view context.
|
||||
Through a `$casting` array, arbitrary properties and getters can be casted:
|
||||
|
||||
@ -60,8 +60,8 @@ Through a `$casting` array, arbitrary properties and getters can be casted:
|
||||
|
||||
## Casting DataObject
|
||||
|
||||
The `[api:DataObject]` class uses `DBField` to describe the types of its
|
||||
properties which are persisted in database columns, through the `[$db](api:DataObject::$db)` property.
|
||||
The [api:DataObject] class uses `DBField` to describe the types of its
|
||||
properties which are persisted in database columns, through the [api:DataObject::$db] property.
|
||||
In addition to type information, the `DBField` class also knows how to
|
||||
define itself as a database column. See the ["datamodel" topic](/topics/datamodel#casting) for more details.
|
||||
|
||||
@ -83,8 +83,8 @@ Example: Flagging an object of type `MyObject` (see above) if it's date is in th
|
||||
|
||||
## Casting HTML Text
|
||||
|
||||
The database field types `[api:HTMLVarchar]` and `[api:Varchar]` are exactly the same in the database. However, the
|
||||
templating engine knows to escape the `[api:Varchar]` field and not the `[api:HTMLVarchar]` field. So, it's important you
|
||||
The database field types [api:HTMLVarchar] and [api:Varchar] are exactly the same in the database. However, the
|
||||
templating engine knows to escape the [api:Varchar] field and not the [api:HTMLVarchar] field. So, it's important you
|
||||
use the right field if you don't want to be putting $FieldType.XML everywhere.
|
||||
|
||||
If you're going to put HTML content into the field, please use the field type with the HTML prefix. Otherwise, you're
|
||||
@ -93,4 +93,4 @@ going to risk double-escaping your data, forgetting to escape your data, and gen
|
||||
## Related
|
||||
|
||||
* ["datamodel" topic](/topics/datamodel)
|
||||
* ["security" topic](/topics/security)
|
||||
* ["security" topic](/topics/security)
|
||||
|
||||
@ -7,12 +7,12 @@ following connections:
|
||||
* 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]`. Inheritance is supported in the data
|
||||
All data tables in SilverStripe are defined as subclasses of [api:DataObject]. Inheritance is supported in the data
|
||||
model: seperate tables will be linked together, the data spread across these tables. The mapping and saving/loading
|
||||
logic is handled by SilverStripe, you don't need to worry about writing SQL most of the time.
|
||||
|
||||
Most of the ORM customizations are possible through [PHP5 Object
|
||||
Overloading](http://www.onlamp.com/pub/a/php/2005/06/16/overloading.html) handled in the `[api:Object]`-class.
|
||||
Overloading](http://www.onlamp.com/pub/a/php/2005/06/16/overloading.html) handled in the [api:Object]-class.
|
||||
|
||||
See [database-structure](/reference/database-structure) for in-depth information on the database-schema,
|
||||
and the ["sql queries" topic](/reference/sqlquery) in case you need to drop down to the bare metal.
|
||||
@ -210,7 +210,7 @@ The where clauses showcased in the previous two sections (filter and exclude) sp
|
||||
matches by default. However, there are a number of suffixes that you can put on field names to change this
|
||||
behaviour `":StartsWith"`, `":EndsWith"`, `":PartialMatch"`, `":GreaterThan"`, `":LessThan"`, `":Negation"`.
|
||||
|
||||
Each of these suffixes is represented in the ORM as a subclass of `[api:SearchFilter]`. Developers can define
|
||||
Each of these suffixes is represented in the ORM as a subclass of [api:SearchFilter]. Developers can define
|
||||
their own SearchFilters if needing to extend the ORM filter and exclude behaviours.
|
||||
|
||||
The following is a query which will return everyone whose first name doesn't start with S, who has logged in
|
||||
@ -289,7 +289,7 @@ For example:
|
||||
|
||||
Passing a *$join* statement to DataObject::get will filter results further by the JOINs performed against the foreign
|
||||
table. **It will NOT return the additionally joined data.** The returned *$records* will always be a
|
||||
`[api:DataObject]`.
|
||||
[api:DataObject].
|
||||
|
||||
## Properties
|
||||
|
||||
@ -417,7 +417,7 @@ on the "Player"-table.
|
||||
);
|
||||
}
|
||||
|
||||
SilverStripe's `[api:SiteTree]` base-class for content-pages uses a 1-to-1 relationship to link to its
|
||||
SilverStripe's [api:SiteTree] base-class for content-pages uses a 1-to-1 relationship to link to its
|
||||
parent element in the tree:
|
||||
|
||||
:::php
|
||||
@ -514,7 +514,7 @@ accessors available on both ends.
|
||||
### 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,
|
||||
They are encapsulated by [api:HasManyList] and [api:ManyManyList], both of which provide very similar APIs,
|
||||
e.g. an `add()` and `remove()` method.
|
||||
|
||||
:::php
|
||||
@ -535,7 +535,7 @@ e.g. an `add()` and `remove()` method.
|
||||
You can use the flexible datamodel 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 [api:DataObject::$has_many] for more info on the described relations.
|
||||
|
||||
:::php
|
||||
class Team extends DataObject {
|
||||
@ -559,19 +559,19 @@ through [form validation](/topics/form-validation).
|
||||
While this is a useful approach, it can lead to data inconsistencies if the
|
||||
record is modified outside of the 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.
|
||||
SilverStripe provides the [api: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 hook through `[api:DataExtension]`.
|
||||
or use the hook through [api:DataExtension].
|
||||
|
||||
Invalid objects won't be able to be written - a [api:ValidationException]`
|
||||
Invalid objects won't be able to be written - a [api: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 [api:ValidationResult] object.
|
||||
You can append your own errors in there.
|
||||
|
||||
Example: Validate postcodes based on the selected country
|
||||
@ -615,7 +615,7 @@ This functionality is provided by the `SS_Map` class, which can be used to build
|
||||
$map = new SS_Map($members, 'ID', 'FirstName');
|
||||
|
||||
Note: You can also retrieve a single property from all contained records
|
||||
through [SS_List->column()](api:SS_List#_column).
|
||||
through [api:SS_List::column()].
|
||||
|
||||
## Data Handling
|
||||
|
||||
@ -737,8 +737,8 @@ See the ["sql queries" topic](/reference/sqlquery) for custom *INSERT*, *UPDATE*
|
||||
|
||||
## Extending DataObjects
|
||||
|
||||
You can add properties and methods to existing `[api:DataObjects]`s like `[api:Member]` (a core class) without
|
||||
hacking core code or subclassing. See `[api:DataExtension]` for a general description, and `[api:Hierarchy]` for
|
||||
You can add properties and methods to existing [api:DataObjects]s like [api:Member] (a core class) without
|
||||
hacking core code or subclassing. See [api:DataExtension] for a general description, and [api:Hierarchy] for
|
||||
the most popular examples.
|
||||
|
||||
## FAQ
|
||||
@ -746,7 +746,7 @@ the most popular examples.
|
||||
### What's the difference between DataObject::get() and a relation-getter?
|
||||
|
||||
You can work with both in pretty much the same way, but relationship-getters return a special type of collection:
|
||||
A `[api:HasManyList]` or a `[api:ManyManyList]` with relation-specific functionality.
|
||||
A [api:HasManyList] or a [api:ManyManyList] with relation-specific functionality.
|
||||
|
||||
:::php
|
||||
$myTeams = $myPlayer->Team(); // returns HasManyList
|
||||
|
||||
@ -32,7 +32,7 @@ use devmode on a public server very very carefully
|
||||
Test mode is designed for staging environments or other private collaboration sites before deploying a site live. You do
|
||||
not need to use test mode if you do not have a staging environment or a place for testing which is on a public server)
|
||||
|
||||
In this mode error messages are hidden from the user and it includes `[api:BasicAuth]` integration if you want to password
|
||||
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.php` file
|
||||
@ -142,6 +142,6 @@ development effort itself as "test-driven development".
|
||||
|
||||
#### Profiling
|
||||
|
||||
Silverstripe includes a profiling suite called [Profiler](http://www.adepteo.net/profiler/manual.html) from Carl Taylor
|
||||
Silverstripe includes a profiling suite called `[Profiler](http://www.adepteo.net/profiler/manual.html)` from Carl Taylor
|
||||
at Adepteo. You can use this withing your installation during development to find bottlenecks and more. You can enable
|
||||
the profiler by adding `?debug_profile=1` to your URL.
|
||||
|
||||
@ -78,7 +78,7 @@ Example Forum Documentation:
|
||||
|
||||
## PHP Include Paths
|
||||
|
||||
Due to the way `[api:ManifestBuilder]` recursively detects php-files and includes them through PHP5's
|
||||
Due to the way [api:ManifestBuilder] recursively detects php-files and includes them through PHP5's
|
||||
*__autoload()*-feature, you don't need to worry about include paths. Feel free to structure your php-code into
|
||||
subdirectories inside the *code*-directory.
|
||||
|
||||
|
||||
@ -116,4 +116,4 @@ The [newsletter module](http://silverstripe.org/newsletter-module) provides a UI
|
||||
|
||||
## API Documentation
|
||||
|
||||
`[api:Email]`
|
||||
[api:Email]
|
||||
|
||||
@ -36,11 +36,11 @@ warnings.
|
||||
An HTTP 500 error will be sent when there has been a fatal error on either a test or production site. You can make this
|
||||
friendlier - much like the 404 page, the error content can be edited within the CMS.
|
||||
|
||||
* Create a page of type `[api:ErrorPage]`
|
||||
* Create a page of type [api:ErrorPage]
|
||||
* Set the error code to 500
|
||||
* Publish the page.
|
||||
|
||||
**HOW IT WORKS: **The publication script for `[api:ErrorPage]` will write the full HTML content, including the template styling,
|
||||
**HOW IT WORKS: **The publication script for [api:ErrorPage] will write the full HTML content, including the template styling,
|
||||
to assets/error-500.html. The fatal error handler looks for the presence of this file, and if it exists, dumps the
|
||||
content. This means that database access isn't required to provide a 500 error page.
|
||||
|
||||
@ -85,4 +85,4 @@ You can send both fatal errors and warnings in your code to a specified email-ad
|
||||
// log errors and warnings
|
||||
SS_Log::add_writer(new SS_LogEmailWriter('admin@domain.com'), SS_Log::WARN, '<=');
|
||||
// or just errors
|
||||
SS_Log::add_writer(new SS_LogEmailWriter('admin@domain.com'), SS_Log::ERR);
|
||||
SS_Log::add_writer(new SS_LogEmailWriter('admin@domain.com'), SS_Log::ERR);
|
||||
|
||||
@ -6,10 +6,10 @@ but doesn't come with any built-in JavaScript validation
|
||||
|
||||
## Required Fields
|
||||
|
||||
Validators are implemented as an argument to the `[api:Form]` constructor,
|
||||
and are subclasses of the abstract `[api:Validator]` base class.
|
||||
Validators are implemented as an argument to the [api:Form] constructor,
|
||||
and are subclasses of the abstract [api:Validator] base class.
|
||||
The only implementation which comes with SilverStripe is
|
||||
the `[api:RequiredFields]` class, which ensures fields are filled out
|
||||
the [api:RequiredFields] class, which ensures fields are filled out
|
||||
when the form is submitted.
|
||||
|
||||
:::php
|
||||
@ -32,7 +32,7 @@ when the form is submitted.
|
||||
## Form Field Validation
|
||||
|
||||
Form fields are responsible for validating the data they process,
|
||||
through the `[api:FormField->validate()] method. There are many fields
|
||||
through the [api:FormField::validate()] method. There are many fields
|
||||
for different purposes (see ["form field types"](/reference/form-field-types) for a full list).
|
||||
|
||||
## Adding your own validation messages
|
||||
@ -128,7 +128,7 @@ but are just a starting point for custom validation with JavaScript.
|
||||
## Model Validation
|
||||
|
||||
An alternative (or additional) approach to validation is to place it directly
|
||||
on the model. SilverStripe provides a `[api:DataObject->validate()]` method for this purpose.
|
||||
on the model. SilverStripe provides a [api:DataObject::validate()] method for this purpose.
|
||||
Refer to the ["datamodel" topic](/topics/datamodel#validation-and-constraints) for more information.
|
||||
|
||||
## Subclassing Validator
|
||||
@ -141,4 +141,4 @@ errors.
|
||||
|
||||
## Related
|
||||
|
||||
* Model Validation with [api:DataObject->validate()]
|
||||
* Model Validation with [api:DataObject::validate()]
|
||||
|
||||
@ -73,7 +73,7 @@ or by defining `$allowed_actions` in your own `Form` class
|
||||
You'll notice that we've used a new notation for creating form fields, using `create()` instead of the `new` operator.
|
||||
These are functionally equivalent, but allows PHP to chain operations like `setTitle()` without assigning the field
|
||||
instance to a temporary variable. For in-depth information on the create syntax, see the [Injector](/reference/injector)
|
||||
documentation or the API documentation for `[api:Object]`::create().
|
||||
documentation or the API documentation for [api:Object::create()].
|
||||
</div>
|
||||
|
||||
## The Form
|
||||
@ -90,9 +90,9 @@ constructor takes the following arguments:
|
||||
* `$name`: This must be the name of the method on that controller that is called to return the form. The first two
|
||||
fields allow the form object to be re-created after submission. **It's vital that they are properly set - if you ever
|
||||
have problems with form action handler not working, check that these values are correct.**
|
||||
* `$fields`: A `[api:FieldList]` containing `[api:FormField]` instances make up fields in the form.
|
||||
* `$actions`: A `[api:FieldList]` containing the `[api:FormAction]` objects - the buttons at the bottom.
|
||||
* `$validator`: An optional `[api:Validator]` for validation of the form.
|
||||
* `$fields`: A [api:FieldList] containing [api:FormField] instances make up fields in the form.
|
||||
* `$actions`: A [api:FieldList] containing the [api:FormAction] objects - the buttons at the bottom.
|
||||
* `$validator`: An optional [api:Validator] for validation of the form.
|
||||
|
||||
Example:
|
||||
|
||||
@ -174,7 +174,7 @@ data.
|
||||
|
||||
## The FormField classes
|
||||
|
||||
There are many classes extending `[api:FormField]`. There is a full overview at
|
||||
There are many classes extending [api:FormField]. There is a full overview at
|
||||
[form field types](/reference/form-field-types).
|
||||
|
||||
|
||||
@ -256,7 +256,7 @@ First of all, you need to create your form on it's own class, that way you can d
|
||||
}
|
||||
}
|
||||
|
||||
`MyForm->forTemplate()` tells the `[api:Form]` class to render with a template of return value of `$this->class`, which in this case
|
||||
`MyForm->forTemplate()` tells the [api:Form] class to render with a template of return value of `$this->class`, which in this case
|
||||
is *MyForm*. If the template doesn't exist, then it falls back to using Form.ss.
|
||||
|
||||
*MyForm.ss* should then be placed into your *templates/Includes* directory for your project. Here is an example of
|
||||
@ -296,7 +296,7 @@ in this case `EmailField->Field()` or `PasswordField->Field()` which returns an
|
||||
for the type of field. Pass in the name of the field as the first parameter, as done above, to render it into the
|
||||
template.
|
||||
|
||||
To find more methods, have a look at the `[api:Form]` class and `[api:FieldList]` class as there is a lot of different
|
||||
To find more methods, have a look at the [api:Form] class and [api:FieldList] class as there is a lot of different
|
||||
methods of customising the form templates. An example is that you could use `<% loop $Fields %>` instead of specifying
|
||||
each field manually, as we've done above.
|
||||
|
||||
@ -314,10 +314,10 @@ Will be rendered as:
|
||||
:::html
|
||||
<input type="text" name="MyText" class="text largeText" id="MyForm_MyCustomForm_MyText" data-validation-regex="[\d]*">
|
||||
|
||||
Each form field is rendered into a form via the `[FormField->FieldHolder()](api:FormField)` method, which includes
|
||||
Each form field is rendered into a form via the [api:FormField::FieldHolder()] method, which includes
|
||||
a container `<div>` as well as a `<label>` element (if applicable).
|
||||
|
||||
You can also render each field without these structural elements through the `[FormField->Field()](api:FormField)`
|
||||
You can also render each field without these structural elements through the [api:FormField::Field()]
|
||||
method. In order to influence the form rendering, overloading these two methods is a good start.
|
||||
|
||||
In addition, most form fields are rendered through SilverStripe templates, e.g. `TextareaField` is rendered via
|
||||
@ -371,7 +371,7 @@ Adds a new text field called FavouriteColour next to the Content field in the CM
|
||||
|
||||
## API Documentation
|
||||
|
||||
* `[api:Form]`
|
||||
* `[api:FormField]`
|
||||
* `[api:FieldList]`
|
||||
* `[api:FormAction]`
|
||||
* [api:Form]
|
||||
* [api:FormField]
|
||||
* [api:FieldList]
|
||||
* [api:FormAction]
|
||||
|
||||
@ -16,7 +16,7 @@ This page aims to describe the low-level functionality of the i18n-API. It targe
|
||||
* want to make their PHP-code (e.g. form labels) i18n-ready
|
||||
|
||||
Please note that this project scope currently **doesn't include full support for format conversion in dates or
|
||||
currencies**. Check our [roadmap](http://open.silverstripe.com/roadmap).
|
||||
currencies**. Check our `[roadmap](http://open.silverstripe.com/roadmap)`.
|
||||
|
||||
|
||||
## Usage
|
||||
@ -28,7 +28,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 you
|
||||
To set the locale you just need to call [api:i18n::set_locale()] passing, as a parameter, the name of the locale that you
|
||||
want to set.
|
||||
|
||||
:::php
|
||||
@ -44,7 +44,7 @@ available locales.
|
||||
|
||||
### 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 [api:i18n::get_locale()].
|
||||
|
||||
### Declaring the content language in HTML {#declaring_the_content_language_in_html}
|
||||
|
||||
@ -70,9 +70,10 @@ to write your own logic for any frontend output.
|
||||
i18n::set_date_format('dd.MM.YYYY');
|
||||
i18n::set_time_format('HH:mm');
|
||||
|
||||
Most localization routines in SilverStripe use the [Zend_Date API](http://framework.zend.com/manual/en/zend.date.html).
|
||||
Most localization routines in SilverStripe use the
|
||||
`[Zend_Date API](http://framework.zend.com/manual/1.12/en/zend.date.overview.html)`.
|
||||
This means all formats are defined in
|
||||
[ISO date format](http://framework.zend.com/manual/en/zend.date.constants.html#zend.date.constants.selfdefinedformats),
|
||||
`[ISO date format](http://framework.zend.com/manual/1.12/en/zend.date.constants.html)`,
|
||||
not PHP's built-in [date()](http://nz.php.net/manual/en/function.date.php).
|
||||
|
||||
### i18n in URLs
|
||||
@ -204,10 +205,10 @@ You'll need to install PHPUnit to run the text collector (see [testing-guide](/t
|
||||
## Language definitions
|
||||
|
||||
Each module can have one language table per locale, stored by convention in the `lang/` subfolder.
|
||||
The translation is powered by [Zend_Translate](http://framework.zend.com/manual/en/zend.translate.html),
|
||||
The translation is powered by `[Zend_Translate](http://framework.zend.com/manual/en/zend.translate.html)`,
|
||||
which supports different translation adapters, dealing with different storage formats.
|
||||
|
||||
By default, SilverStripe 3.x uses a YAML format (through the [Zend_Translate_RailsYAML adapter](https://github.com/chillu/zend_translate_railsyaml)).
|
||||
By default, SilverStripe 3.x uses a YAML format (through the `[Zend_Translate_RailsYAML adapter](https://github.com/chillu/zend_translate_railsyaml)`).
|
||||
|
||||
Example: framework/lang/en.yml (extract)
|
||||
|
||||
@ -322,4 +323,4 @@ Example Translation Table (mymodule/javascript/lang/de_DE.js)
|
||||
* [Help to translate](/misc/contributing/translation) - Instructions for online collaboration to translate core
|
||||
* [Help to translate](/misc/translation-process) - Instructions for adding translation to your own modules
|
||||
* [http://www.i18nguy.com/](http://www.i18nguy.com/)
|
||||
* [balbus.tk i18n notes](http://www.balbus.tk/internationalize)
|
||||
* `[balbus.tk i18n notes](http://www.balbus.tk/internationalize)`
|
||||
|
||||
@ -9,9 +9,9 @@ practices can be applied to other libraries as well.
|
||||
|
||||
## File Inclusion
|
||||
|
||||
SilverStripe-driven code should use the `[api:Requirements]` class to manage clientside dependencies like CSS and JavaScript
|
||||
SilverStripe-driven code should use the [api:Requirements] class to manage clientside dependencies like CSS and JavaScript
|
||||
files, rather than including `<script>` and `<link>` tags in your templates. This has the advantage that a registry
|
||||
of requirements can be built up from different places outside of the main controller, for example included `[api:FormField]`
|
||||
of requirements can be built up from different places outside of the main controller, for example included [api:FormField]
|
||||
instances.
|
||||
|
||||
See [requirements](/reference/requirements) documentation.
|
||||
@ -123,7 +123,7 @@ Main advantages over simpler jQuery plugins are:
|
||||
* Constructor/Destructor hooks
|
||||
* Focus management and mouse interaction
|
||||
|
||||
See the [official developer guide](http://jqueryui.com/docs/Developer_Guide) and other
|
||||
See the `[official developer guide](http://jqueryui.com/docs/Developer_Guide)` and other
|
||||
[tutorials](http://bililite.com/blog/understanding-jquery-ui-widgets-a-tutorial/) to get started.
|
||||
|
||||
Example: Highlighter
|
||||
@ -369,7 +369,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 [api:Form] SilverStripe class, which is built solely around
|
||||
this inflexible concept.
|
||||
|
||||
Example: Autocomplete input field loading page matches through AJAX
|
||||
@ -440,7 +440,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 [api: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.
|
||||
|
||||
@ -568,7 +568,7 @@ Example: jQuery.entwine
|
||||
It is important to verify that your code actually does what it says, and the best way to ensure this are **automated
|
||||
tests**. For jQuery, we use two different tools with different uses: **unit testing** with
|
||||
[QUnit](http://docs.jquery.com/QUnit) (also used by the jQuery team for the core libraries), and **behaviour driven
|
||||
testing** with [JSpec](http://visionmedia.github.com/jspec/). There are overlaps between the two solutions, if in doubt
|
||||
testing** with `[JSpec](http://visionmedia.github.com/jspec/)`. There are overlaps between the two solutions, if in doubt
|
||||
start with JSpec, as it provides a much more powerful testing framework.
|
||||
|
||||
Example: QUnit test (from [jquery.com](http://docs.jquery.com/QUnit#Using_QUnit)):
|
||||
@ -581,7 +581,7 @@ Example: QUnit test (from [jquery.com](http://docs.jquery.com/QUnit#Using_QUnit)
|
||||
});
|
||||
|
||||
|
||||
Example: JSpec Shopping cart test (from [visionmedia.github.com](http://visionmedia.github.com/jspec/))
|
||||
Example: JSpec Shopping cart test (from `[visionmedia.github.com](http://visionmedia.github.com/jspec/)`)
|
||||
|
||||
describe 'ShoppingCart'
|
||||
before_each
|
||||
|
||||
@ -6,7 +6,7 @@ A module is, quite simply, a collection of classes, templates, and other resourc
|
||||
directory. In a default SilverStripe download, even resources in 'framework' and 'mysite' are treated in exactly the
|
||||
same as every other module.
|
||||
|
||||
SilverStripe's `[api:ManifestBuilder]` will find any class, css or template files anywhere under the site's main
|
||||
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
|
||||
?flush=1 on the end of the URL, all the module's new behaviour will be incorporated to your site:
|
||||
@ -17,7 +17,7 @@ Object::useCustomClass(), and the like. So, by unpacking a module into site's m
|
||||
it.
|
||||
* You can provide additional director rules to define your own controller for particular URLs.
|
||||
|
||||
For more information on creating modules, see [module-development](/topics/module-development).
|
||||
For more information on creating modules, see `[module-development](/topics/module-development)`.
|
||||
|
||||
## Types of Modules
|
||||
|
||||
@ -33,7 +33,7 @@ instead make it easier for developers to build other applications.
|
||||
|
||||
## Finding Modules
|
||||
|
||||
* [Official module list on silverstripe.org](http://silverstripe.org/modules)
|
||||
* `[Official module list on silverstripe.org](http://silverstripe.org/modules)`
|
||||
* [Packagist.org "silverstripe" tag](https://packagist.org/search/?tags=silverstripe)
|
||||
* [Github.com "silverstripe" search](https://github.com/search?q=silverstripe&ref=commandbar)
|
||||
|
||||
@ -77,7 +77,7 @@ which is required for its operation. In this case, we recommend upgrading to a n
|
||||
### From an Archive Download
|
||||
|
||||
Alternatively, you can download the archive file from the
|
||||
[modules page](http://www.silverstripe.org/modules)
|
||||
`[modules page](http://www.silverstripe.org/modules)`
|
||||
and extract it to the root folder mentioned above.
|
||||
Github also provides archive downloads which are generated automatically for every tag/version.
|
||||
|
||||
|
||||
@ -155,12 +155,12 @@ If "Menu Title" is left blank by the CMS author, it'll just default to "Title".
|
||||
$LinkingMode
|
||||
|
||||
Each menu item we loop over knows its location on the website, so can generate a link to it.
|
||||
This happens through the `[api:SiteTree->Link()]` method behind the scenes.
|
||||
This happens through the [api:SiteTree::Link()] method behind the scenes.
|
||||
We're not using the direct database property `SiteTree.URLSegment` here
|
||||
because pages can be nested, so the link needs to be generated on the fly.
|
||||
In the template syntax, there's no distinction between a method and a property though.
|
||||
The link is relative by default (see `<% base_tag %>`),
|
||||
you can get an absolute one including the domain through [$AbsoluteLink](api:SiteTree->AbsoluteLink())`.
|
||||
you can get an absolute one including the domain through [api:SiteTree::AbsoluteLink()].
|
||||
|
||||
In addition, each menu item gets some context information relative
|
||||
to the page you're currently viewing, contained in the `$LinkingMode` placeholder.
|
||||
@ -206,7 +206,7 @@ folder to customize its output. Here's the default template:
|
||||
<% end_if %>
|
||||
|
||||
For more customization options like limiting the amount of breadcrumbs,
|
||||
take a look at `[api:SiteTree->Breadcrumbs()]`.
|
||||
take a look at [api:SiteTree::Breadcrumbs()].
|
||||
|
||||
### SiteConfig: Global settings
|
||||
|
||||
@ -279,7 +279,7 @@ you can use any public API on those classes, and [extend](/reference/dataextensi
|
||||
with your own. To get an overview on what's available to you,
|
||||
we recommend that you dive into the API docs for the following classes:
|
||||
|
||||
* `[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
|
||||
* [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
|
||||
|
||||
@ -72,8 +72,8 @@ Note: To modify fields in the "Settings" tab, you need to use `updateSettingsFie
|
||||
|
||||
### removeFieldFromTab()
|
||||
|
||||
Overloading `getCMSFields()` you can call `removeFieldFromTab()` on a `[api:FieldList]` object. For example, if you don't
|
||||
want the MenuTitle field to show on your page, which is inherited from `[api:SiteTree]`.
|
||||
Overloading `getCMSFields()` you can call `removeFieldFromTab()` on a [api:FieldList] object. For example, if you don't
|
||||
want the MenuTitle field to show on your page, which is inherited from [api:SiteTree].
|
||||
|
||||
:::php
|
||||
class StaffPage extends Page {
|
||||
|
||||
@ -9,8 +9,8 @@ you can effectively select and upload files.
|
||||
|
||||
## Usage
|
||||
|
||||
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 [api:HTMLEditorField] form field class which encapsulates most of the required functionality.
|
||||
It is usually added through the [api:DataObject::getCMSFields()] method:
|
||||
|
||||
:::php
|
||||
class MyObject extends DataObject {
|
||||
@ -24,10 +24,10 @@ It is usually added through the `[api:DataObject->getCMSFields()]` method:
|
||||
## Configuration
|
||||
|
||||
To keep the JavaScript editor configuration manageable and extensible,
|
||||
we've wrapped it in a PHP class called `[api:HtmlEditorConfig]`.
|
||||
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).
|
||||
There can be multiple configs, which should always be created / accessed using `[api:HtmlEditorConfig::get].
|
||||
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.
|
||||
|
||||
@ -45,9 +45,9 @@ Example: Remove some buttons for more advanced formatting
|
||||
|
||||
## Image and Media Insertion
|
||||
|
||||
The `[api:HtmlEditorField]` API also handles inserting images and media
|
||||
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),
|
||||
files on the webserver filesystem (through the [api:File] and [api:Image] APIs),
|
||||
as well as hotlinking files from the web.
|
||||
|
||||
## oEmbed: Embedding media through external services
|
||||
@ -57,7 +57,7 @@ around the web, allowing easy representation of files just by referencing a webs
|
||||
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]`.
|
||||
oEmbed powers the "Insert from web" feature available through [api: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). To refresh a cache, append `?flush=1` to a URL.
|
||||
@ -91,22 +91,22 @@ 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 [api:HtmlEditorField_Toolbar] 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 [api:Member::getHtmlEditorConfigForCMS()].
|
||||
The group assignment is done through the "Security" interface for each [api: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 [api:HtmlEditorField_Toolbar] class.
|
||||
In the CMS, those dialogs are automatically instanciated, but in your own interfaces outside
|
||||
of the CMS you have to take care of instanciation yourself:
|
||||
|
||||
@ -141,7 +141,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 [api:HtmlEditorConfig] is currently hardwired to support TinyMCE,
|
||||
so its up to you to either convert existing configuration as applicable,
|
||||
or start your own configuration.
|
||||
|
||||
|
||||
@ -7,14 +7,14 @@ See [Site Search](/tutorials/site-search) for details.
|
||||
|
||||
## Searching for DataObjects
|
||||
|
||||
The `[api:SearchContext]` class provides a good base implementation that you can hook into your own controllers.
|
||||
A working implementation of searchable DataObjects can be seen in the `[ModelAdmin](/reference/modeladmin)` class.
|
||||
The [api:SearchContext] class provides a good base implementation that you can hook into your own controllers.
|
||||
A working implementation of searchable DataObjects can be seen in the [api:ModelAdmin] class.
|
||||
|
||||
[SearchContext](/reference/searchcontext) goes into more detail about setting up a default search form for `[api:DataObject]`s.
|
||||
[SearchContext](/reference/searchcontext) goes into more detail about setting up a default search form for [api:DataObject]s.
|
||||
|
||||
### Fulltext search on DataObjects
|
||||
|
||||
The `[api:MySQLDatabase]` class now defaults to creating tables using the InnoDB storage engine. As Fulltext search in MySQL
|
||||
The [api:MySQLDatabase] class now 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.
|
||||
|
||||
@ -28,8 +28,8 @@ You can do so by adding this static variable to your class definition:
|
||||
## Searching for Documents
|
||||
|
||||
SilverStripe does not have a built-in method to search through file content (e.g. in PDF or DOC format).
|
||||
You can either extract any textual file content into the `[File](api:File)->Content` property, or use a
|
||||
dedicated search service like the [sphinx module](http://silverstripe.org/sphinx-module).
|
||||
You can either extract any textual file content into the [api:File] *Content* property, or use a
|
||||
dedicated search service like the [sphinx module](http://addons.silverstripe.org/add-ons/silverstripe/fulltextsearch).
|
||||
|
||||
## Related
|
||||
|
||||
@ -37,6 +37,6 @@ dedicated search service like the [sphinx module](http://silverstripe.org/sphinx
|
||||
* [RestfulServer module](https://github.com/silverstripe/silverstripe-restfulserver)
|
||||
* [Site Search](/tutorials/site-search)
|
||||
* [SearchContext](/reference/searchcontext)
|
||||
* [genericviews module](http://silverstripe.org/generic-views-module)
|
||||
* [sphinx module](http://silverstripe.org/sphinx-module)
|
||||
* [lucene module](http://silverstripe.org/lucene-module)
|
||||
* `[genericviews module](http://silverstripe.org/generic-views-module)`
|
||||
* [sphinx module](http://addons.silverstripe.org/add-ons/silverstripe/fulltextsearch)
|
||||
* [lucene module](https://code.google.com/archive/p/lucene-silverstripe-plugin)
|
||||
|
||||
@ -3,7 +3,7 @@
|
||||
## Introduction
|
||||
|
||||
This page details notes on how to ensure that we develop secure SilverStripe applications.
|
||||
See our "[Release Process](/misc/release-process#security-releases) on how to report security issues.
|
||||
See our [Release Process](/misc/release-process#security-releases) on how to report security issues.
|
||||
|
||||
## SQL Injection
|
||||
|
||||
@ -15,10 +15,10 @@ See [http://shiflett.org/articles/sql-injection](http://shiflett.org/articles/sq
|
||||
### Automatic escaping
|
||||
|
||||
SilverStripe automatically escapes data in SQL statements wherever possible,
|
||||
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)`.
|
||||
through database-specific methods (see [api:MySQLDatabase::addslashes()]).
|
||||
For [api:MySQLDatabase], this will be [mysql_real_escape_string()](http://php.net/manual/en/function.mysql-real-escape-string.php).
|
||||
|
||||
* Most `[api:DataList]` accessors (see escaping note in method documentation)
|
||||
* Most [api:DataList] accessors (see escaping note in method documentation)
|
||||
* DataObject::get_by_id()
|
||||
* DataObject::update()
|
||||
* DataObject::castedUpdate()
|
||||
@ -129,8 +129,8 @@ for in-depth information about "Cross-Site-Scripting".
|
||||
|
||||
### Escaping model properties
|
||||
|
||||
`[api:SSViewer]` (the SilverStripe template engine) automatically takes care of escaping HTML tags from specific
|
||||
object-properties by [casting](/topics/datamodel#casting) its string value into a `[api:DBField]` object.
|
||||
[api:SSViewer] (the SilverStripe template engine) automatically takes care of escaping HTML tags from specific
|
||||
object-properties by [casting](/topics/datamodel#casting) its string value into a [api:DBField] object.
|
||||
|
||||
PHP:
|
||||
|
||||
@ -213,7 +213,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 [api:Convert] class has utilities for this, mainly *Convert::raw2xml()* and *Convert::raw2att()* (which is
|
||||
also used by *XML* and *ATT* in template code).
|
||||
|
||||
PHP:
|
||||
|
||||
@ -2,7 +2,7 @@
|
||||
|
||||
## Overview
|
||||
|
||||
The `[api:ShortcodeParser]` API is simple parser that allows you to map specifically
|
||||
The [api: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.
|
||||
@ -21,15 +21,15 @@ Here's some syntax variations:
|
||||
|
||||
## Usage
|
||||
|
||||
In its most basic form, you can invoke the `[api:ShortcodeParser]` directly:
|
||||
In its most basic form, you can invoke the [api:ShortcodeParser] directly:
|
||||
|
||||
:::php
|
||||
ShortcodeParser::get_active()->parse($myvalue);
|
||||
|
||||
In addition, shortcodes are automatically parsed on any database field which is declared
|
||||
as `[api:HTMLValue]` or `[api:HTMLText]`, when rendered into a template.
|
||||
as [api:HTMLValue] or [api:HTMLText], 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.
|
||||
and any other [api:DataObject::$db] definitions of these types.
|
||||
|
||||
In order to allow shortcodes in your own template placeholders,
|
||||
ensure they're casted correctly:
|
||||
|
||||
@ -2,7 +2,7 @@
|
||||
|
||||
Functional tests test your controllers. The core of these are the same as unit tests:
|
||||
|
||||
* Create a subclass of `[api:SapphireTest]` in the `mysite/tests` or `(module)/tests` folder.
|
||||
* Create a subclass of [api:SapphireTest] in the `mysite/tests` or `(module)/tests` folder.
|
||||
* Define static $fixture_file to point to a database YAML file.
|
||||
* Create methods that start with "test" to create your tests.
|
||||
* Assertions are used to work out if a test passed or failed.
|
||||
@ -48,7 +48,7 @@ URLs. Here is an example from the subsites module:
|
||||
We are using a new static method here: **Director::test($url, $postVars, $sessionObj)**
|
||||
|
||||
Director::test() lets us execute a URL and see what happens. It bypasses HTTP, instead relying on the cleanly
|
||||
encapsulated execution model of `[api:Controller]`.
|
||||
encapsulated execution model of [api:Controller].
|
||||
|
||||
It takes 3 arguments:
|
||||
|
||||
@ -56,7 +56,7 @@ It takes 3 arguments:
|
||||
* $postVars: Post variables to pass to the URL
|
||||
* $sessionObj: A Session object representing the current session.
|
||||
|
||||
And it returns an `[api:HTTPResponse]` object, which will give you the response headers (including redirection), status code,
|
||||
And it returns an [api:HTTPResponse] object, which will give you the response headers (including redirection), status code,
|
||||
and body.
|
||||
|
||||
We can use string processing on the body of the response to then see if it fits with our expectations.
|
||||
@ -65,4 +65,4 @@ If you're testing for natural language responses like error messages, make sure
|
||||
the *_t()* method to avoid tests failing when i18n is enabled.
|
||||
|
||||
Note that for a more highlevel testing approach, SilverStripe also supports
|
||||
[behaviour-driven testing through Behat](https://github.com/silverstripe-labs/silverstripe-behat-extension). It interacts directly with your website or CMS interface by remote controlling an actual browser, driven by natural language assertions.
|
||||
[behaviour-driven testing through Behat](https://github.com/silverstripe-labs/silverstripe-behat-extension). It interacts directly with your website or CMS interface by remote controlling an actual browser, driven by natural language assertions.
|
||||
|
||||
@ -1,6 +1,6 @@
|
||||
# How To Create a SilverStripe Test
|
||||
|
||||
A unit test class will test the behaviour of one of your `[api:DataObjects]`. This simple fragment of `[api:SiteTreeTest]`
|
||||
A unit test class will test the behaviour of one of your [api:DataObjects]. This simple fragment of [api:SiteTreeTest]
|
||||
provides us the basics of creating unit tests.
|
||||
|
||||
:::php
|
||||
@ -39,14 +39,14 @@ provides us the basics of creating unit tests.
|
||||
|
||||
There are a number of points to note in this code fragment:
|
||||
|
||||
* Your test is a **subclass of SapphireTest**. Both unit tests and functional tests are a subclass of `[api:SapphireTest]`.
|
||||
* Your test is a **subclass of SapphireTest**. Both unit tests and functional tests are a subclass of [api:SapphireTest].
|
||||
* **static $fixture_file** is defined. The testing framework will automatically set up a new database for **each** of
|
||||
your tests. The initial database content will be sourced from the YML file that you list in $fixture_file. The property can take an array of fixture paths.
|
||||
* Each **method that starts with the word "test"** will be executed by the TestRunner. Define as many as you like; the
|
||||
database will be rebuilt for each of these.
|
||||
* **$this->objFromFixture($className, $identifier)** can be used to select one of the objects named in your fixture
|
||||
file. To identify to the object, we provide a class name and an identifier. The identifier is specified in the YML
|
||||
file but not saved in the database anywhere. objFromFixture() looks the `[api:DataObject]` up in memory rather than using the
|
||||
file but not saved in the database anywhere. objFromFixture() looks the [api: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.
|
||||
|
||||
## Assertion commands
|
||||
@ -57,8 +57,8 @@ fails if and only if one or more of the assertions fail.
|
||||
See [the PHPUnit manual](http://www.phpunit.de/manual/current/en/api.html#api.assert)
|
||||
for a listing of all PHPUnit's built-in assertions.
|
||||
|
||||
The `[api:SapphireTest]` class comes with additional assertions which are more
|
||||
specific to the framework, e.g. `[assertEmailSent](api:SapphireTest->assertEmailSent())`
|
||||
The [api:SapphireTest] class comes with additional assertions which are more
|
||||
specific to the framework, e.g. [api:SapphireTest::assertEmailSent()]
|
||||
which can simulate sending emails through the `Email->send()` API without actually
|
||||
using a mail server (see the [testing emails](email-sending)) guide.
|
||||
|
||||
@ -66,4 +66,4 @@ using a mail server (see the [testing emails](email-sending)) guide.
|
||||
|
||||
Often you need to test your functionality with some existing data, so called "fixtures".
|
||||
These records are inserted on a fresh test database automatically.
|
||||
[Read more about fixtures](fixtures).
|
||||
[Read more about fixtures](fixtures).
|
||||
|
||||
@ -15,7 +15,7 @@ send emails in your SilverStripe application. Here is a simple example of how y
|
||||
$e->send();
|
||||
|
||||
|
||||
Normally, the send() method would send an email using PHP's mail() function. However, if you are running a `[api:SapphireTest]`
|
||||
Normally, the send() method would send an email using PHP's mail() function. However, if you are running a [api:SapphireTest]
|
||||
test, then it holds off actually sending the email, and instead lets you assert that an email was sent using this method.
|
||||
|
||||
:::php
|
||||
|
||||
@ -3,7 +3,7 @@
|
||||
## Overview
|
||||
|
||||
Often you need to test your functionality with some existing data, so called "fixtures".
|
||||
The `[api:SapphireTest]` class already prepares an empty database for you,
|
||||
The [api:SapphireTest] class already prepares an empty database for you,
|
||||
and you have various ways to define those fixtures.
|
||||
|
||||
## YAML Fixtures
|
||||
@ -95,7 +95,7 @@ set of test instances every time.
|
||||
### Why Factories?
|
||||
|
||||
Manually defined fixture provide full flexibility, but very little in terms of structure and convention.
|
||||
Alternatively, you can use the `[api:FixtureFactory]` class, which allows you
|
||||
Alternatively, you can use the [api:FixtureFactory] class, which allows you
|
||||
to set default values, callbacks on object creation, and dynamic/lazy value setting.
|
||||
By the way, the `SapphireTest` YAML fixtures rely on internally on this class as well.
|
||||
|
||||
@ -225,4 +225,4 @@ By default, blueprint names equal the class names they manage.
|
||||
// $myPageObj->MyProperty = My Default Value
|
||||
// $myPageObj->MyOtherProperty = My Custom Value
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
@ -75,7 +75,7 @@ All command-line arguments are documented on
|
||||
### Via the "sake" Wrapper on Command Line
|
||||
|
||||
The [sake](/topics/commandline) executable that comes with SilverStripe can trigger a customized
|
||||
"[api:TestRunner]" class that handles the PHPUnit configuration and output formatting.
|
||||
[api:TestRunner] class that handles the PHPUnit configuration and output formatting.
|
||||
While the custom test runner a handy tool, its also more limited than using `phpunit` directly,
|
||||
particularly around formatting test output.
|
||||
|
||||
@ -104,7 +104,7 @@ access to the command line, you can also run tests through the browser.
|
||||
|
||||
## 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 [api: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
|
||||
|
||||
@ -50,7 +50,7 @@ When called through a web browser, it prompts for a fixture file
|
||||
which it creates a new database for, and sets it as the current database
|
||||
in this browser session until you call `dev/tests/endsession`.
|
||||
|
||||
For more advanced users, you can also have a look in the `[api:YamlFixture]`
|
||||
For more advanced users, you can also have a look in the [api:YamlFixture]
|
||||
class to see what's going on behind the scenes.
|
||||
|
||||
## My database server is cluttered with `tmpdb...` databases
|
||||
|
||||
@ -217,12 +217,12 @@ Maybe even a nice link saying Website Powered by SilverStripe to show your suppo
|
||||
A bunch of resources feel free to use to make your template awesome
|
||||
|
||||
* [http://kuler.adobe.com](http://kuler.adobe.com) - Kuler is a great color scheming tool
|
||||
* [http://blog.html.it/layoutgala/](http://blog.html.it/layoutgala/) - 40 super cool CSS layouts for you to use
|
||||
* `[http://blog.html.it/layoutgala/](http://blog.html.it/layoutgala/)` - 40 super cool CSS layouts for you to use
|
||||
* [http://designmeltdown.com](http://designmeltdown.com) - Great gallery of websites. Browse through and get inspired.
|
||||
* [http://validator.w3.org/](http://validator.w3.org/) - Your template must pass 'or get near' validation.
|
||||
* [http://famfamfam.com/lab/icons/](http://famfamfam.com/lab/icons/) - free, beautiful icons.
|
||||
* [http://cssremix.com](http://cssremix.com) - Another CSS site gallery for inspiration.
|
||||
* [http://www.maxdesign.com.au/presentation/process/](http://www.maxdesign.com.au/presentation/process/) - a good process for creating a design
|
||||
* `[http://cssremix.com](http://cssremix.com)` - Another CSS site gallery for inspiration.
|
||||
* `[http://www.maxdesign.com.au/presentation/process/](http://www.maxdesign.com.au(http://www.maxdesign.com.au/presentation/process/)` - a good process for creating a design
|
||||
|
||||
## Reference
|
||||
|
||||
@ -244,7 +244,7 @@ Note: This only applies for CSS and template files. PHP files **do not** get ove
|
||||
|
||||
### Requirements
|
||||
|
||||
The `[api:Requirements::themedCSS()]` function will
|
||||
The [api:Requirements::themedCSS()] function will
|
||||
do the search specified above. This avoids the need to type a full path to the css file, and also provides better
|
||||
ambiguity for themes.
|
||||
|
||||
|
||||
@ -6,7 +6,7 @@ Themes can be used to kick start your SilverStripe projects, and generally make
|
||||
|
||||
## Downloading
|
||||
|
||||
Head to the [ Themes ](http://www.silverstripe.org/themes) area of the website to check out the wide range of themes
|
||||
Head to the `[ Themes ](http://www.silverstripe.org/themes)` area of the website to check out the wide range of themes
|
||||
the community has built. Each theme has a page with links you can use to preview and download it. The theme is provided
|
||||
as a .tar.gz file.
|
||||
|
||||
|
||||
@ -13,8 +13,8 @@ The versioning happens automatically on read and write.
|
||||
If you are using the SilverStripe ORM to perform these operations,
|
||||
you don't need to alter your existing calls.
|
||||
|
||||
Versioning in SilverStripe is handled through the `[api:Versioned]` class.
|
||||
It's a `[api:DataExtension]`, which allow it to be applied to any `[api:DataObject]` subclass.
|
||||
Versioning in SilverStripe is handled through the [api:Versioned] class.
|
||||
It's a [api:DataExtension], which allow it to be applied to any [api:DataObject] subclass.
|
||||
|
||||
## Configuration
|
||||
|
||||
@ -73,7 +73,7 @@ Caution: The record is retrieved as a `DataObject`, but saving back modification
|
||||
via `write()` will create a new version, rather than modifying the existing one.
|
||||
|
||||
In order to get a list of all versions for a specific record,
|
||||
we need to generate specialized `[api:Versioned_Version]` objects,
|
||||
we need to generate specialized [api:Versioned_Version] objects,
|
||||
which expose the same database information as a `DataObject`,
|
||||
but also include information about when and how a record was published.
|
||||
|
||||
@ -87,10 +87,10 @@ but also include information about when and how a record was published.
|
||||
The usual call to `DataObject->write()` will write to whatever stage is currently
|
||||
active, as defined by the `Versioned::current_stage()` global setting.
|
||||
Each call will automatically create a new version in the `<class>_versions` table.
|
||||
To avoid this, use `[writeWithoutVersion()](api:Versioned->writeWithoutVersion())` instead.
|
||||
To avoid this, use [api:Versioned::writeWithoutVersion()] instead.
|
||||
|
||||
To move a saved version from one stage to another,
|
||||
call `[writeToStage(<stage>)](api:Versioned->writeToStage())` on the object.
|
||||
call [api:Versioned::writeToStage()] on the object.
|
||||
The process of moving a version to a different stage is also called "publishing",
|
||||
so we've created a shortcut for this: `publish(<from-stage>, <to-stage>)`.
|
||||
|
||||
@ -129,7 +129,7 @@ to run on a certain stage.
|
||||
|
||||
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()]`).
|
||||
across an inherited table scheme (see [api: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:
|
||||
|
||||
@ -1,3 +1,3 @@
|
||||
# Widgets
|
||||
|
||||
[Widgets](http://silverstripe.org/widgets) are small pieces of functionality such as showing the latest Comments or Flickr Photos. Since SilverStripe 3.0, they have been moved into a standalone module at [github.com/silverstripe/silverstripe-widgets](https://github.com/silverstripe/silverstripe-widgets).
|
||||
`[Widgets](http://silverstripe.org/widgets)` are small pieces of functionality such as showing the latest Comments or Flickr Photos. Since SilverStripe 3.0, they have been moved into a standalone module at [github.com/silverstripe/silverstripe-widgets](https://github.com/silverstripe/silverstripe-widgets).
|
||||
|
||||
@ -408,7 +408,7 @@ In the next tutorial, [Extending a Basic Site](extending-a-basic-site), we will
|
||||
|
||||
## Books on SilverStripe
|
||||
|
||||
* [Official book on SilverStripe in English](http://www.silverstripe.org/silverstripe-book).
|
||||
* [Official book on SilverStripe in German](http://www.silverstripe.org/das-silverstripe-buch).
|
||||
* `[Official book on SilverStripe in English](http://www.silverstripe.org/silverstripe-book)`.
|
||||
* `[Official book on SilverStripe in German](http://www.silverstripe.org/das-silverstripe-buch)`.
|
||||
|
||||
|
||||
``
|
||||
|
||||
@ -152,7 +152,7 @@ Its 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, 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 [api: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.
|
||||
@ -419,4 +419,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 [api:GridFieldPaginator] component
|
||||
|
||||
@ -29,11 +29,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 [api: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 [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.
|
||||
|
||||
### View
|
||||
|
||||
@ -42,7 +42,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 [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.
|
||||
|
||||
|
||||
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.
|
||||
@ -88,7 +88,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 [api: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.
|
||||
|
||||
@ -155,7 +155,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 [api:FieldList] object.
|
||||
|
||||
:::php
|
||||
$fields->addFieldToTab('Root.Main', new TextField('Author'), 'Content');
|
||||
@ -163,15 +163,17 @@ 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 [api: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]`.
|
||||
There are many more fields available in the default installation, listed in ["form field types"](/reference/form-field-types).
|
||||
We have added two fields: A simple [api:TextField] and a
|
||||
[api:DateField]. There are many more fields available in the default
|
||||
installation, listed in
|
||||
["form field types"](/reference/form-field-types).
|
||||
|
||||
:::php
|
||||
return $fields;
|
||||
@ -223,7 +225,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 [api:DateField] documentation for more configuration options.
|
||||
|
||||
:::php
|
||||
$fields->addFieldToTab('Root.Main', new TextField('Author','Author Name'), 'Content');
|
||||
@ -260,13 +262,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 [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
|
||||
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.
|
||||
|
||||
|
||||
|
||||
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 [api:Date] 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.
|
||||
|
||||
@ -296,7 +298,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 [api:HTMLText] field gives us a nice summary of the article. The function strips all tags from the paragraph extracted.
|
||||
|
||||
|
||||
|
||||
@ -385,7 +387,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. Create the following function in the
|
||||
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. Create the following function in the
|
||||
*ArticleHolder_Controller*:
|
||||
|
||||
:::php
|
||||
@ -397,7 +399,7 @@ An RSS feed is something that no news section should be without. SilverStripe ma
|
||||
|
||||
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 [api:RSSFeed]
|
||||
|
||||
|
||||
|
||||
@ -463,7 +465,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 [api: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.
|
||||
|
||||
@ -477,7 +479,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 [api:Image] class.
|
||||
|
||||
**themes/simple/templates/Layout/StaffHolder.ss**
|
||||
|
||||
@ -501,7 +503,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 *SetWidth* method of the `[api:Image]` class
|
||||
This template is very similar to the *ArticleHolder* template. The *SetWidth* method of the [api: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.
|
||||
|
||||
|
||||
@ -71,11 +71,11 @@ Let's step through this code.
|
||||
|
||||
|
||||
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 [api:FieldList] and passing our fields as arguments.
|
||||
The first field is a [api: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 [api:OptionsetField]. This is a dropdown, and takes a third argument - an
|
||||
array mapping the values to the options listed in the dropdown.
|
||||
|
||||
:::php
|
||||
@ -87,14 +87,14 @@ array mapping the values to the options listed in the dropdown.
|
||||
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 [api: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 [api: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.
|
||||
@ -167,8 +167,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](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 [api:DataObject].
|
||||
If you recall, in the [second tutorial](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:
|
||||
|
||||
**mysite/code/BrowserPollSubmission.php**
|
||||
|
||||
@ -197,7 +197,7 @@ If we then rebuild the database ([http://localhost/your_site_name/dev/build](htt
|
||||
}
|
||||
|
||||
|
||||
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 [api: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.
|
||||
|
||||
@ -229,7 +229,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 [api:Session] class handles all session variables in SilverStripe. First modify the 'doBrowserPoll' to set the session variable 'BrowserPollVoted' when a user votes.
|
||||
|
||||
**mysite/code/HomePage.php**
|
||||
|
||||
@ -268,7 +268,7 @@ 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 [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.
|
||||
|
||||
Create the function 'BrowserPollResults' on the *HomePage_Controller* class.
|
||||
|
||||
@ -295,7 +295,7 @@ This code introduces a few new concepts, so let's step through it.
|
||||
:::php
|
||||
$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 [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).
|
||||
|
||||
:::php
|
||||
$total = $submissions->Count();
|
||||
@ -313,9 +313,9 @@ We get the total number of submissions, which is needed to calculate the percent
|
||||
}
|
||||
|
||||
|
||||
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 [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.
|
||||
|
||||
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 [api: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.
|
||||
|
||||
@ -89,7 +89,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 [api:PaginatedList]
|
||||
class.
|
||||
|
||||
*themes/simple/templates/Layout/Page_results.ss*
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user