mirror of
https://github.com/silverstripe/silverstripe-framework
synced 2024-10-22 14:05:37 +02:00
70 lines
2.9 KiB
Markdown
70 lines
2.9 KiB
Markdown
# 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.
|
||
|
||
```diff
|
||
-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:
|
||
|
||
```php
|
||
// 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/](changelog))
|
||
|
||
## 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.
|
||
|
||
```php
|
||
// 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.
|
||
|
||
```php
|
||
$cache = SS_Cache::factory('myapp', 'Output', array('disable-segmentation' => true));
|
||
```
|
||
|