mirror of
https://github.com/silverstripe/silverstripe-framework
synced 2024-10-22 14:05:37 +02:00
86 lines
4.0 KiB
Markdown
86 lines
4.0 KiB
Markdown
# 4.3.0
|
|
|
|
## Overview {#overview}
|
|
|
|
- `DataList::column()` now returns all values and not just "distinct" values from a column as per the API docs
|
|
- `DataList`, `ArrayList` and `UnsavedRalationList` all have `columnUnique()` method for fetching distinct column values
|
|
- Take care with `stageChildren()` overrides. `Hierarchy::numChildren() ` results will only make use of `stageChildren()` customisations that are applied to the base class and don't include record-specific behaviour.
|
|
- New React-based search UI for the CMS, Asset-Admin, GridFields and ModelAdmins.
|
|
- A new `GridFieldLazyLoader` component can be added to `GridField`. This will delay the fetching of data until the user access the container Tab of the GridField.
|
|
- `SilverStripe\VersionedAdmin\Controllers\CMSPageHistoryViewerController` is now the default CMS history controller and `SilverStripe\CMS\Controllers\CMSPageHistoryController` has been deprecated.
|
|
- It's now possible to avoid storing GridField data in session. See [the documentation on GridField](../developer_guides/forms/field_types/gridfield/#saving-the-gridfield-state).
|
|
|
|
## Upgrading {#upgrading}
|
|
|
|
### Fetching distinct column values on DataList
|
|
|
|
Prior to this release `DataList` would erroneously return a distinct list of values from a column on an object.
|
|
If this behaviour is still required, please use `columnUnique()` instead.
|
|
|
|
### Using legacy GridField search API
|
|
|
|
GridFields now default to using the new search UI which uses [SilverStripe's FormSchema API](api:SilverStripe\Forms\Schema\FormSchema).
|
|
|
|
If you would rather continue using the old search API, you can remove the default `GridFieldFilterHeader` from your GridField configuration and replace with one whose _legacy_ flag has been enabled.
|
|
|
|
To enable the legacy search API on a `GridFieldFilterHeader`, you can either:
|
|
* set the `useLegacyFilterHeader` property to `true`,
|
|
* or pass `true` to the first argument of its constructor.
|
|
|
|
To force the legacy search API on all instances of `GridFieldFilterHeader`, you can set it in your [configuration file](../developer_guides/configuration):
|
|
```yml
|
|
SilverStripe\Forms\GridField\GridFieldFilterHeader:
|
|
force_legacy: true
|
|
```
|
|
|
|
```php
|
|
public function getCMSFields()
|
|
{
|
|
$fields = parent::getCMSFields();
|
|
|
|
// Configure grid field to use legacy search API
|
|
$config = new GridFieldConfig_RecordEditor();
|
|
$config->getComponentsByType(GridFieldFilterHeader::class)->useLegacyFilterHeader = true;
|
|
|
|
$grid = GridField::create('Companies', 'Companies', DataList::create(Company::class), $config);
|
|
$fields->addFieldToTab('Root.Company', $grid);
|
|
|
|
return $fields;
|
|
}
|
|
|
|
```
|
|
|
|
### Keep using the legacy `CMSPageHistoryController`
|
|
|
|
To keep using the old CMS history controller for every page type, add the following entry to your YML config.
|
|
|
|
```yml
|
|
SilverStripe\Core\Injector\Injector:
|
|
SilverStripe\CMS\Controllers\CMSPageHistoryController:
|
|
class: SilverStripe\CMS\Controllers\CMSPageHistoryController
|
|
```
|
|
|
|
If you want to use both CMS history controllers in different contexts, you can implement your own _Factory_ class.
|
|
```yml
|
|
SilverStripe\Core\Injector\Injector:
|
|
SilverStripe\CMS\Controllers\CMSPageHistoryController:
|
|
factory:
|
|
App\MySite\MyCustomControllerFactory
|
|
```
|
|
|
|
[Implementing a _Factory_ with the Injector](/developer_guides/extending/injector/#factories).
|
|
|
|
### Using the history viewer for custom DataObjects
|
|
|
|
For information on how to implement the history viewer UI in your own versioned DataObjects, please refer to
|
|
[the Versioning documentation](../developer_guides/model/versioning).
|
|
|
|
### Tests with dynamic extension customisations
|
|
|
|
In SilverStripe 4.2, some unit tests that modify an extension class with PHP configuration manifest customisations
|
|
may have passed and may now fail in SilverStripe 4.3. This behaviour is inconsistent, is not a recommended approach
|
|
to customising extensions and should be avoided in all SilverStripe 4.x releases.
|
|
|
|
For information on how to customise extensions, see
|
|
["Extending Extensions"](../developer_guides/extending/extensions#extendingextensions).
|