Updated 4.0.0 changelog

Backtick mania
This commit is contained in:
Robbie Averill 2016-03-09 09:37:06 +13:00
parent 016ea2efb1
commit 9379914038

View File

@ -12,7 +12,7 @@
* `DataObject::ClassName` field has been refactored into a `DBClassName` type field. * `DataObject::ClassName` field has been refactored into a `DBClassName` type field.
* Image manipulations have been moved into a new `[api:ImageManipulation]` trait. * Image manipulations have been moved into a new `[api:ImageManipulation]` trait.
* `CMSFileAddController` removed. * `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. can be used to validate these types.
* `Image_Backend` API now loads and saves from `AssetContainer` instances rather than local files. * `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' * 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)). * 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` 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). 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. * `Object::invokeWithExtensions` now has the same method signature as `Object::extend` and behaves the same way.
## New API ## New API
@ -64,9 +64,9 @@
* `HtmlEditorField::setEditorConfig` may now take an instance of a `HtmlEditorConfig` class, as well as a * `HtmlEditorField::setEditorConfig` may now take an instance of a `HtmlEditorConfig` class, as well as a
standard config identifier name. standard config identifier name.
* A lot of standard versioned API has been refactored from `SiteTree` into `Versioned` extension. Now * A lot of standard versioned API has been refactored from `SiteTree` into `Versioned` extension. Now
all versioned DataObjects have canPublish(), canArchive(), canUnpublish(), doPublish(), doArchive() all versioned DataObjects have `canPublish()`, `canArchive()`, `canUnpublish()`, `doPublish()`, `doArchive()`
doUnpublish(), isPublished() and isonDraft() out of the box. However, do*() methods will no longer `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. 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 * GridField edit form now has improved support for versioned DataObjects, with basic publishing
actions available when editing records. 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 ### 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 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. 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 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*` 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: 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 * 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. between physical files and File DataObjects.
* Folder dataobjects are now purely logical dataobjects, and perform no actual filesystem folder creation on write. * 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 * 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 wish visitors to be able to see.
You can disable File versioning by adding the following to your _config.php 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: 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 * 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. 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 * 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 ### 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: standard silverstripe templates on flush. These templates include:
* `Assets_HTAccess.ss`: Template for public permissions on the Apache server. * `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 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. 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. See [/developer_guides/files/file_security] for more information.