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

3.7.0 (unreleased)

SilverStripe 3.7 and PHP 7.2 and Object subclasses

For Project Code

SilverStripe 3.7 now supports PHP 7.2, which is exciting, but PHP 7.2 introduces an object keyword. To use it, you can replace any uses of Object with SS_Object in your own project code.

-class MyClass extends Object
+class MyClass extends SS_Object
{
	public function myFunction()
	{
-		$foo = Object::has_extension('MyExtension');
+		$foo = SS_Object::has_extension('MyExtension');
	}
}

You are also reliant on any SilverStripe modules directly using Object to upgrade their codebase. Matches for SS_Object in the module codebase will tell you it's been upgraded. A search for extends Object or Object:: isn't fool proof, but will give you an indication that the module still needs to be upgraded. If in doubt, check the module README.

For Module Authors

If you are publishing a 3.x-compatible module that directly references the Object class, we recommend that you replace all references to Object with SS_Object, and add the following line to your module's _config.php in order to support both current SilverStripe 3.x and SilverStripe 3.7 releases running on PHP 7.2:

// Ensure compatibility with PHP 7.2 ("object" is a reserved word),
// with SilverStripe 3.6 (using Object) and SilverStripe 3.7 (using SS_Object)
if (!class_exists('SS_Object')) class_alias('Object', 'SS_Object');

Don't forget to mention explicit PHP 7.2 and SilverStripe 3.7 compatibility in your module README.

Note that in SilverStripe 4.x, the Object class was deleted so there isn’t an SS_Object class there either (see https://docs.silverstripe.org/en/4/changelogs/4.0.0/)

Versioned cache segmentation

SS_Cache now maintains separate cache pools for each versioned stage. This prevents developers from caching draft data and then accidentally exposing it on the live stage without potentially required authorisation checks. Unless you rely on caching across stages, you don't need to change your own code for this change to take effect. Note that cache keys will be internally rewritten, causing any existing cache items to become invalid when this change is deployed.

// Before:
$cache = SS_Cache::factory('myapp');
Versioned::set_reading_mode('Stage.Stage');
$cache->save('Some draft content. Not for public viewing yet.', 'my_key');
Versioned::set_reading_mode('Stage.Live');
$cache->load('my_key'); // 'Some draft content. Not for public viewing yet'

// After:
$cache = SS_Cache::factory('myapp');
Versioned::set_reading_mode('Stage.Stage');
$cache->save('Some draft content. Not for public viewing yet.', 'my_key');
Versioned::set_reading_mode('Stage.Live');
$cache->load('my_key'); // null

Data that is not content sensitive can be cached across stages by simply opting out of the segmented cache with the disable-segmentation argument.

$cache = SS_Cache::factory('myapp', 'Output', array('disable-segmentation' => true));