Detail links in changelogs

This commit is contained in:
Ingo Schommer 2017-10-24 22:33:20 +13:00
parent a08c1f42d9
commit ff0b648d75

View File

@ -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. `<h1>$Title</h1>`) 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
### <a name="template-casting"></a>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