From ff0b648d758e61969b71c73c8b1f2f620b9e7e3e Mon Sep 17 00:00:00 2001 From: Ingo Schommer Date: Tue, 24 Oct 2017 22:33:20 +1300 Subject: [PATCH] Detail links in changelogs --- docs/en/04_Changelogs/4.0.0.md | 32 ++++++++++++++++---------------- 1 file changed, 16 insertions(+), 16 deletions(-) diff --git a/docs/en/04_Changelogs/4.0.0.md b/docs/en/04_Changelogs/4.0.0.md index 22108c5b9..f5e91e4b2 100644 --- a/docs/en/04_Changelogs/4.0.0.md +++ b/docs/en/04_Changelogs/4.0.0.md @@ -31,12 +31,11 @@ guide developers in preparing existing 3.x code for compatibility with 4.0 classes are now namespaced, and some have been renamed. This has major implications for arrangement of templates, as well as other references to classes via string literals or configuration. Automatic upgrading tools have been developed to cope with the bulk of these changes (see - [upgrading notes](#upgrading)). Some classes have been rearranged so that each file contains only one class definition. It is recommended that user code follow the same convention. - For example, page types and their controllers should longer be collated in a single file. + [upgrading notes](#upgrading)). * Object class has been replaced with traits ([details](object-replace)). * Asset storage has been abstracted, and a new concept of `DBFile` references via database column references now exists in addition to references via the existing `File` dataobject. File security and protected files - are now a core feature. + are now a core feature ([details](#asset-storage)) * A new front-end development process has been developed for the construction of javascript based components, prominently featuring ReactJS to develop highly functional CMS content areas. A new standard form schema API has been developed to allow back-end PHP constructed forms to scaffold themselves within ReactJS @@ -44,26 +43,27 @@ guide developers in preparing existing 3.x code for compatibility with 4.0 * CMS CSS has been re-developed using Bootstrap v4 as a base ([blog post](https://www.silverstripe.org/blog/a-frameworks-framework-why-silverstripe-4-will-use-bootstrap/)) * Asset admin has been replaced with a purely ReactJS powered upgrade, and split out - module called [asset-admin](https://github.com/silverstripe/silverstripe-asset-admin/). You'll need to add this to your `composer.json` to retain file management capabilities for your CMS authors. + module called [asset-admin](https://github.com/silverstripe/silverstripe-asset-admin/). * Versioning is now a much more powerful feature, with the addition of campaigns to allow batches of related - or inter-dependent objects to be published as a single act. Dependencies between versioned objects can be + or inter-dependent objects to be published as a single "changeset" ([details](#changeset)). +* Dependencies between versioned objects can be declared using the new ownership API, so that developers can ensure that relational consistency is - maintained during publishing. This new system can be managed via the new "Campaigns" CMS section ([blog post](https://www.silverstripe.org/blog/campaigns-in-silverstripe-4/)) + maintained during publishing ([details](#ownership)) + This new system can be managed via the new "Campaigns" CMS section ([blog post](https://www.silverstripe.org/blog/campaigns-in-silverstripe-4/)) * Template variable casting (e.g. `

$Title

`) is enforced by default, which will ensure safe HTML encode - unless explicitly opted out. + unless explicitly opted out ([details](#template-casting)) * Themes are now configured to cascade, where you can specify a list of themes, and have the template engine search programatically through a prioritised list when resolving template and CSS file paths. -* Removed module path constants (e.g. `FRAMWORK_PATH`) and support for hardcoded file paths (e.g. `mysite/css/styles.css`) -* i18n Updated to use symfony/translation over zend Framework 1. Zend_Translate has been removed. -* Replaced `Zend_Cache` and the `Cache` API with a PSR-16 implementation (symfony/cache) -* _ss_environment.php files have been removed in favour of `.env` and "real" environment variables. -* admin has been moved to a new module [silverstripe/admin](https://github.com/silverstripe/silverstripe-admin). -* Behat support updated to v3. See the - [behat extension](https://github.com/silverstripe/silverstripe-behat-extension) for more information. +* Removed module path constants (e.g. `FRAMEWORK_PATH`) and support for hardcoded file paths (e.g. `mysite/css/styles.css`) ([details](#module-paths)) +* Replaced Zend_Translate with symfony/translation ([details](#i18n)) +* Replaced `Zend_Cache` and the `Cache` API with a PSR-16 implementation (symfony/cache) ([details](#cache)) +* `_ss_environment.php` files have been removed in favour of `.env` and "real" environment variables ([details](#env)). +* Behat support updated to v3 ( + [details](https://github.com/silverstripe/silverstripe-behat-extension)) * The `GDBackend` and `ImagickBackend` classes have been replaced by a unified `InterventionBackend` which uses the [intervention/image](https://github.com/intervention/image) library to power manipualations. * Dependencies can managed via [recipe-plugin](https://github.com/silverstripe/recipe-plugin). See [recipe-core](https://github.com/silverstripe/recipe-core) and [recipe-cms](https://github.com/silverstripe/recipe-cms) as examples. -* Authentication has been upgraded to a modular approach using re-usable interfaces and easier to hook in to LoginHandlers. +* Authentication has been upgraded to a modular approach using re-usable interfaces and easier to hook in to LoginHandlers ([details](#custom-authenticators)). * Core modules are installed in the `vendor/` folder by default (other modules can opt-in, see [guide](/developer_guides/extending/how_tos/publish_a_module)) * Renamed constant for temp folder from `TEMP_FOLDER` to `TEMP_PATH` for naming consistency with other path variables and constants @@ -743,7 +743,7 @@ framework/thirdparty/jquery/jquery.js => framework/admin/thirdparty/jquery/jquer If you have customised the CMS UI (via JavaScript or CSS), please read our guide to [customise the admin interface](/developer_guides/customising_the_admin_interface/). -### Explicit text casting on template variables +### Explicit text casting on template variables Now whenever a `$Variable` is used in a template, regardless of whether any casts or methods are suffixed to the reference, it will be cast to either an explicit DBField for that field, or