silverstripe-framework/docs/en/04_Changelogs/4.3.0.md

4.3.0

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.

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.

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:

SilverStripe\Forms\GridField\GridFieldFilterHeader:
  force_legacy: true

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.

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.

SilverStripe\Core\Injector\Injector:
  SilverStripe\CMS\Controllers\CMSPageHistoryController:
    factory:
      App\MySite\MyCustomControllerFactory

Implementing a Factory with the Injector.

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.

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".