tonyair/silverstripe-framework
1
0
Fork 0
mirror of https://github.com/silverstripe/silverstripe-framework synced 2024-09-27 20:06:52 +02:00
Code Issues Projects Releases Wiki Activity

Merge pull request #5159 from robbieaverill/patch-2

Browse Source 
Updated 4.0.0 changelog
This commit is contained in:
Damian Mooyman 2016-03-09 10:22:02 +13:00
commit 26cd1a2d5f
1 changed files with 13 additions and 13 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

26
docs/en/04_Changelogs/4.0.0.md
View File

@ -12,7 +12,7 @@
* `DataObject::ClassName` field has been refactored into a `DBClassName` type field.
* Image manipulations have been moved into a new `[api:ImageManipulation]` trait.
* `CMSFileAddController` removed.
* UploadField::setAllowedFileCategories('image') now excludes non-resizeable images. 'unresizeable_image' is
* `UploadField::setAllowedFileCategories('image')` now excludes non-resizeable images. 'unresizeable_image' is
can be used to validate these types.
* `Image_Backend` API now loads and saves from `AssetContainer` instances rather than local files.
* The following File categories have been renamed: 'zip' to 'archive', 'doc' to 'document', and 'mov' to 'video'
@ -32,7 +32,7 @@
* Updated PHPUnit from 3.7 to 4.8 ([upgrade notes](https://github.com/sebastianbergmann/phpunit/wiki/Release-Announcement-for-PHPUnit-4.0.0#backwards-compatibility-issues)).
Please remove any PHPUnit related `require_once()` calls (e.g. in `FeatureContext`
definitions of the [behat-extension](https://github.com/silverstripe-labs/silverstripe-behat-extension) module).
Run `composer require --dev 'phpunit/phpunit:~4.8' on existing projects to pull in the new dependency.
Run `composer require --dev 'phpunit/phpunit:~4.8'` on existing projects to pull in the new dependency.
* `Object::invokeWithExtensions` now has the same method signature as `Object::extend` and behaves the same way.
## New API
@ -64,9 +64,9 @@
* `HtmlEditorField::setEditorConfig` may now take an instance of a `HtmlEditorConfig` class, as well as a
standard config identifier name.
* A lot of standard versioned API has been refactored from `SiteTree` into `Versioned` extension. Now
all versioned DataObjects have canPublish(), canArchive(), canUnpublish(), doPublish(), doArchive()
doUnpublish(), isPublished() and isonDraft() out of the box. However, do*() methods will no longer
automatically check can*() permissions, and must be done by usercode before invocation.
all versioned DataObjects have `canPublish()`, `canArchive()`, `canUnpublish()`, `doPublish()`, `doArchive()`
`doUnpublish()`, `isPublished()` and `isonDraft()` out of the box. However, `do*()` methods will no longer
automatically check `can*()` permissions, and must be done by usercode before invocation.
* GridField edit form now has improved support for versioned DataObjects, with basic publishing
actions available when editing records.
@ -323,8 +323,8 @@ E.g.
### Upgrading code that writes to `File` dataobjects, or writes files to the 'assets' folder
In the past all that was necessary to write a `File` dataobject to the database was to ensure a physical file
existed in the assets folder, and that the Filename of the dataobject was set to the same location.
In the past all that was necessary to write a `File` DataObject to the database was to ensure a physical file
existed in the assets folder, and that the Filename of the DataObject was set to the same location.
Since the storage of physical files is no longer a standard location, it's necessary to delegate the writing of such
files to the asset persistence layer. As a wrapper for an individual file, you can use any of the `setFrom*`
@ -364,10 +364,10 @@ stored in the assets folder.
There are other important considerations in working with File dataobjects which differ from legacy:
* File synchronisation is no longer automatic. This is due to the fact that there is no longer a 1-to-1 relationship
between physical files and File dataobjects.
* Folder dataobjects are now purely logical dataobjects, and perform no actual filesystem folder creation on write.
between physical files and File DataObjects.
* Folder DataObjects are now purely logical DataObjects, and perform no actual filesystem folder creation on write.
* All Files are versioned, which means that by default, new File records will not be visibile
to the public site. You will need to make sure to invoke ->doPublish() on any File dataobject
to the public site. You will need to make sure to invoke `->doPublish()` on any File DataObject
you wish visitors to be able to see.
You can disable File versioning by adding the following to your _config.php
@ -433,7 +433,7 @@ After:
There are a few differences in this new API:
* The extension is no longer specific to dataobjects, so it uses the generic 'Extension' class instead of 'DataExtension'
* The extension is no longer specific to DataObjects, so it uses the generic 'Extension' class instead of 'DataExtension'
* This extension is added to both `DBFile` and `File`, or order to make this manipulation available to non-dataobject
file references as well, but it could be applied to either independently.
* A helper method `variantName` is invoked in order to help generate a unique variant key. Custom code may use another
@ -568,7 +568,7 @@ E.g.
### Upgrading asset web.config, .htaccess, or other server configuration
Server configuration files for /assets are no longer static, and are regenerated via a set of
Server configuration files for `/assets` are no longer static, and are regenerated via a set of
standard silverstripe templates on flush. These templates include:
* `Assets_HTAccess.ss`: Template for public permissions on the Apache server.
@ -579,7 +579,7 @@ standard silverstripe templates on flush. These templates include:
You will need to make sure that these files are writable via the web server, and that any necessary
configuration customisation is done via overriding these templates.
If upgrading from an existing installation, make sure to invoke ?flush=all at least once.
If upgrading from an existing installation, make sure to invoke `?flush=all` at least once.
See [/developer_guides/files/file_security] for more information.