mirror of
https://github.com/silverstripe/silverstripe-framework
synced 2024-10-22 14:05:37 +02:00
Consistent anchors in changelog headliens
This commit is contained in:
parent
19d33f4de7
commit
69f16c605c
@ -73,7 +73,7 @@ The below sections describe how to go about updating an existing site to be prep
|
|||||||
Most of these upgrading tasks will involve manual code review, although in some cases there are
|
Most of these upgrading tasks will involve manual code review, although in some cases there are
|
||||||
some automated processes that users can run.
|
some automated processes that users can run.
|
||||||
|
|
||||||
### Composer dependency update
|
### <a name="deps"></a>Composer dependency update
|
||||||
|
|
||||||
As a first step, you need to update your composer dependencies.
|
As a first step, you need to update your composer dependencies.
|
||||||
The easiest way is to start with a new `composer.json` file
|
The easiest way is to start with a new `composer.json` file
|
||||||
@ -133,7 +133,7 @@ you should raise an issue on the repository asking for 4.0 compatibility.
|
|||||||
For now, you should attempt to continue the upgrade without the module
|
For now, you should attempt to continue the upgrade without the module
|
||||||
and temporarily disable its functionality.
|
and temporarily disable its functionality.
|
||||||
|
|
||||||
### Install the upgrader tool
|
### <a name="upgrader-tool"></a>Install the upgrader tool
|
||||||
|
|
||||||
A lot of upgrade work can be automated, and we've written an
|
A lot of upgrade work can be automated, and we've written an
|
||||||
[upgrader tool](https://github.com/silverstripe/silverstripe-upgrader/) for this purpose.
|
[upgrader tool](https://github.com/silverstripe/silverstripe-upgrader/) for this purpose.
|
||||||
@ -143,7 +143,7 @@ Install it via composer:
|
|||||||
composer global require silverstripe/upgrader
|
composer global require silverstripe/upgrader
|
||||||
```
|
```
|
||||||
|
|
||||||
### index.php and .htaccess rewrites
|
### <a name="index-php-rewrites"></a>index.php and .htaccess rewrites
|
||||||
|
|
||||||
The location of SilverStripe's "entry file" has changed. Your project and server environment will need
|
The location of SilverStripe's "entry file" has changed. Your project and server environment will need
|
||||||
to adjust the path to this file from `framework/main.php` to `index.php`.
|
to adjust the path to this file from `framework/main.php` to `index.php`.
|
||||||
@ -165,7 +165,7 @@ for a clean installation. If you have applied customisations to your `.htaccess`
|
|||||||
file (e.g. a custom `main.php`, HTTP header configuration, deny file access),
|
file (e.g. a custom `main.php`, HTTP header configuration, deny file access),
|
||||||
you'll need to manually reapply these to the copied default file.
|
you'll need to manually reapply these to the copied default file.
|
||||||
|
|
||||||
### Renamed and namespaced classes
|
### <a name="namespaced-classes"></a>Renamed and namespaced classes
|
||||||
|
|
||||||
Nearly all core PHP classes have been namespaced. For example, `DataObject` is now called `SilverStripe\ORM\DataObject`.
|
Nearly all core PHP classes have been namespaced. For example, `DataObject` is now called `SilverStripe\ORM\DataObject`.
|
||||||
The below tasks describe how to upgrade an existing site to remain compatible with the newly upgraded classes.
|
The below tasks describe how to upgrade an existing site to remain compatible with the newly upgraded classes.
|
||||||
@ -253,7 +253,7 @@ To access environment variables you can use the `SilverStripe\Core\Environment::
|
|||||||
|
|
||||||
See [Environment Management docs](/getting-started/environment_management/) for full details.
|
See [Environment Management docs](/getting-started/environment_management/) for full details.
|
||||||
|
|
||||||
### Migrate File DataObject
|
### <a name="migrate-file"></a>Migrate File DataObject
|
||||||
|
|
||||||
Since the structure of `File` dataobjects has changed, a new task `MigrateFileTask`
|
Since the structure of `File` dataobjects has changed, a new task `MigrateFileTask`
|
||||||
has been added to assist in migration of legacy files (see [file migration documentation](/developer_guides/files/file_migration)).
|
has been added to assist in migration of legacy files (see [file migration documentation](/developer_guides/files/file_migration)).
|
||||||
@ -272,7 +272,7 @@ SilverStripe\Assets\FileMigrationHelper:
|
|||||||
delete_invalid_files: false
|
delete_invalid_files: false
|
||||||
```
|
```
|
||||||
|
|
||||||
### Get upgrade tips on your code
|
### <a name="inspect-hints"></a>Get upgrade tips on your code
|
||||||
|
|
||||||
While there's some code we can automatically rewrite, other uses of changed SilverStripe APIs aren't that obvious.
|
While there's some code we can automatically rewrite, other uses of changed SilverStripe APIs aren't that obvious.
|
||||||
You can use our heuristics to get some hints on where you need to review code manually.
|
You can use our heuristics to get some hints on where you need to review code manually.
|
||||||
@ -286,7 +286,7 @@ This task should be run *after* `upgrade-code upgrade`.
|
|||||||
These hints only cover a part of the upgrade work,
|
These hints only cover a part of the upgrade work,
|
||||||
but can serve as a good indicator for where to start.
|
but can serve as a good indicator for where to start.
|
||||||
|
|
||||||
### Rewrite literal table names
|
### <a name="literal-table-names"></a>Rewrite literal table names
|
||||||
|
|
||||||
In 3.x the class name of any DataObject matched the table name, but in 4.x all classes are namespaced, and it is
|
In 3.x the class name of any DataObject matched the table name, but in 4.x all classes are namespaced, and it is
|
||||||
necessary to map between table and class for querying the database.
|
necessary to map between table and class for querying the database.
|
||||||
@ -309,7 +309,7 @@ public function countDuplicates($model, $fieldToCheck)
|
|||||||
}
|
}
|
||||||
```
|
```
|
||||||
|
|
||||||
### Rewrite literal class names
|
### <a name="literal-class-names"></a>Rewrite literal class names
|
||||||
|
|
||||||
You'll need to update any strings that represent class names and make sure they're fully
|
You'll need to update any strings that represent class names and make sure they're fully
|
||||||
qualified. In particular, relationship definitions such as `has_one` and `has_many` will need
|
qualified. In particular, relationship definitions such as `has_one` and `has_many` will need
|
||||||
@ -339,7 +339,7 @@ In the context of YAML, the magic constant `::class` does not apply. Fully quali
|
|||||||
property: value
|
property: value
|
||||||
```
|
```
|
||||||
|
|
||||||
### Move controllers to their own files
|
### <a name="controllers-own-files"></a>Move controllers to their own files
|
||||||
|
|
||||||
The convention for naming controllers is now `[MyPageType]Controller`, where it used to be `[MyPageType]_Controller`. This change was made to be more compatible with the PSR-2 standards.
|
The convention for naming controllers is now `[MyPageType]Controller`, where it used to be `[MyPageType]_Controller`. This change was made to be more compatible with the PSR-2 standards.
|
||||||
|
|
||||||
@ -349,7 +349,7 @@ other thirdparty code that extend `PageController` are likely to assume that cla
|
|||||||
|
|
||||||
By default, a controller for a page type *must* reside in the same namespace as its page. To use different logic, override `SiteTree::getControllerName()`.
|
By default, a controller for a page type *must* reside in the same namespace as its page. To use different logic, override `SiteTree::getControllerName()`.
|
||||||
|
|
||||||
### Template locations and references
|
### <a name="template-locations"></a>Template locations and references
|
||||||
|
|
||||||
Templates are now more strict about their locations.
|
Templates are now more strict about their locations.
|
||||||
Case is now also checked on case-sensitive filesystems.
|
Case is now also checked on case-sensitive filesystems.
|
||||||
@ -370,7 +370,7 @@ if the former is not present.
|
|||||||
|
|
||||||
Please refer to our [template syntax](/developer_guides/templates/syntax) for details.
|
Please refer to our [template syntax](/developer_guides/templates/syntax) for details.
|
||||||
|
|
||||||
### Config settings should be set to `private static`
|
### <a name="private-static"></a>Config settings should be set to `private static`
|
||||||
|
|
||||||
Class configuration defined as `static` properties need to be marked as `private` to take effect:
|
Class configuration defined as `static` properties need to be marked as `private` to take effect:
|
||||||
|
|
||||||
@ -451,7 +451,7 @@ To ensure consistency, we've also deprecated support for path constants:
|
|||||||
* Deprecated `THEMES_DIR` and `THEMES_PATH`
|
* Deprecated `THEMES_DIR` and `THEMES_PATH`
|
||||||
* Deprecated `MODULES_PATH` and `MODULES_DIR`
|
* Deprecated `MODULES_PATH` and `MODULES_DIR`
|
||||||
|
|
||||||
### Adapt tooling to modules in vendor folder
|
### <a name="vendor-folder"></a>Adapt tooling to modules in vendor folder
|
||||||
|
|
||||||
SilverStripe modules can now be installed like any other composer package: In the `vendor/` folder
|
SilverStripe modules can now be installed like any other composer package: In the `vendor/` folder
|
||||||
instead of the webroot. Modules need to opt in to this behaviour after they've ensured
|
instead of the webroot. Modules need to opt in to this behaviour after they've ensured
|
||||||
@ -530,7 +530,7 @@ SilverStripe\Core\Injector\Injector:
|
|||||||
`WebDesignGroup\ShopSite\Logging\ErrorPageFormatter` should be a class that
|
`WebDesignGroup\ShopSite\Logging\ErrorPageFormatter` should be a class that
|
||||||
implements the `Monolog\Formatter\FormatterInterface` interface.
|
implements the `Monolog\Formatter\FormatterInterface` interface.
|
||||||
|
|
||||||
### Upgrade `mysite/_config.php`
|
### <a name="config-php"></a>Upgrade `mysite/_config.php`
|
||||||
|
|
||||||
The globals `$database` and `$databaseConfig` are deprecated. You should upgrade your
|
The globals `$database` and `$databaseConfig` are deprecated. You should upgrade your
|
||||||
site `_config.php` files to use the [.env configuration](#env)
|
site `_config.php` files to use the [.env configuration](#env)
|
||||||
@ -646,7 +646,7 @@ In some places it may still be necessary to access the session object where no r
|
|||||||
In rare cases it is still possible to access the request of the current controller via
|
In rare cases it is still possible to access the request of the current controller via
|
||||||
`Controller::curr()->getRequest()` to gain access to the current session.
|
`Controller::curr()->getRequest()` to gain access to the current session.
|
||||||
|
|
||||||
### Extensions are now singletons
|
### <a name="extensions-singletons"></a>Extensions are now singletons
|
||||||
|
|
||||||
Extensions are now all singletons, meaning that state stored as protected vars
|
Extensions are now all singletons, meaning that state stored as protected vars
|
||||||
within extensions are now shared across all object instances that use this extension.
|
within extensions are now shared across all object instances that use this extension.
|
||||||
@ -705,7 +705,7 @@ class MyClass extends DataObject {
|
|||||||
}
|
}
|
||||||
```
|
```
|
||||||
|
|
||||||
### Static references to asset paths
|
### <a name="static-asset-paths"></a>Static references to asset paths
|
||||||
|
|
||||||
All static files (images, javascript, stylesheets, fonts) used for the CMS and forms interfaces
|
All static files (images, javascript, stylesheets, fonts) used for the CMS and forms interfaces
|
||||||
in `framework` and `cms` have moved locations. These assets are now placed in a `client/` subfolder,
|
in `framework` and `cms` have moved locations. These assets are now placed in a `client/` subfolder,
|
||||||
@ -918,7 +918,7 @@ In templates this can also be invoked as below:
|
|||||||
<%t MyObject.PLURALS 'An item|{count} items' count=$Count %>
|
<%t MyObject.PLURALS 'An item|{count} items' count=$Count %>
|
||||||
```
|
```
|
||||||
|
|
||||||
### Removed Member.DateFormat and Member.TimeFormat database settings
|
### <a name="member-date-time-fields"></a>Removed Member.DateFormat and Member.TimeFormat database settings
|
||||||
|
|
||||||
We're using [native HTML5 date and time pickers](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input/date)
|
We're using [native HTML5 date and time pickers](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input/date)
|
||||||
in `DateField` and `TimeField` now ([discussion](https://github.com/silverstripe/silverstripe-framework/issues/6626)),
|
in `DateField` and `TimeField` now ([discussion](https://github.com/silverstripe/silverstripe-framework/issues/6626)),
|
||||||
@ -956,7 +956,7 @@ Depending on your server configuration, it may also be necessary to adjust your
|
|||||||
permissions. Please see the [common installation problems](/getting_started/installation/common_problems)
|
permissions. Please see the [common installation problems](/getting_started/installation/common_problems)
|
||||||
guide for configuration instruction.
|
guide for configuration instruction.
|
||||||
|
|
||||||
### Image handling
|
### <a name="image-handling"></a>Image handling
|
||||||
|
|
||||||
As all image-specific manipulations has been refactored from `Image` into an `ImageManipulations` trait, which
|
As all image-specific manipulations has been refactored from `Image` into an `ImageManipulations` trait, which
|
||||||
is applied to both `File` and `DBFile`. These both implement a common interface `AssetContainer`, which
|
is applied to both `File` and `DBFile`. These both implement a common interface `AssetContainer`, which
|
||||||
@ -1043,7 +1043,7 @@ You can disable File versioning by adding the following to your `_config.php`
|
|||||||
SilverStripe\Assets\File::remove_extension('Versioned');
|
SilverStripe\Assets\File::remove_extension('Versioned');
|
||||||
```
|
```
|
||||||
|
|
||||||
### Custom image manipulations
|
### <a name="image-manipulations"></a>Custom image manipulations
|
||||||
|
|
||||||
As file storage and handling has been refactored into the abstract interface, many other components which were
|
As file storage and handling has been refactored into the abstract interface, many other components which were
|
||||||
once specific to Image.php have now been moved into a shared `ImageManipulation` trait. Manipulations of file content,
|
once specific to Image.php have now been moved into a shared `ImageManipulation` trait. Manipulations of file content,
|
||||||
@ -1211,7 +1211,7 @@ class MyTask extends BuildTask
|
|||||||
}
|
}
|
||||||
```
|
```
|
||||||
|
|
||||||
### Moved ErrorPage into a new module
|
### <a name="errorpage"></a>Moved ErrorPage into a new module
|
||||||
|
|
||||||
ErrorPage has been moved to a separate [silverstripe/errorpage module](http://addons.silverstripe.org/add-ons/silverstripe/errorpage)
|
ErrorPage has been moved to a separate [silverstripe/errorpage module](http://addons.silverstripe.org/add-ons/silverstripe/errorpage)
|
||||||
to allow for alternative approaches to managing error responses.
|
to allow for alternative approaches to managing error responses.
|
||||||
@ -1225,7 +1225,7 @@ By default, SilverStripe will display a plaintext "not found" message when the m
|
|||||||
Check the [module upgrading guide](http://addons.silverstripe.org/add-ons/silverstripe/errorpage)
|
Check the [module upgrading guide](http://addons.silverstripe.org/add-ons/silverstripe/errorpage)
|
||||||
for more configuration API changes on the `ErrorPage` class.
|
for more configuration API changes on the `ErrorPage` class.
|
||||||
|
|
||||||
### Server configuration files for assets
|
### <a name="assets-server-config"></a>Server configuration files for assets
|
||||||
|
|
||||||
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:
|
||||||
@ -1656,7 +1656,7 @@ class GalleryPage extends Page
|
|||||||
}
|
}
|
||||||
```
|
```
|
||||||
|
|
||||||
### Class name remapping
|
### <a name="class-name-remapping"></a>Class name remapping
|
||||||
|
|
||||||
If you've namespaced one of your custom page types, you may notice a message in the CMS
|
If you've namespaced one of your custom page types, you may notice a message in the CMS
|
||||||
telling you it's obsolete. This is likely because the `ClassName`
|
telling you it's obsolete. This is likely because the `ClassName`
|
||||||
@ -1680,7 +1680,7 @@ SilverStripe\ORM\DatabaseAdmin:
|
|||||||
The next time you run a dev/build the class name for all `GalleryPage` pages will
|
The next time you run a dev/build the class name for all `GalleryPage` pages will
|
||||||
be automatically updated to the new `WebDesignGroup\ShopSite\GalleryPage`
|
be automatically updated to the new `WebDesignGroup\ShopSite\GalleryPage`
|
||||||
|
|
||||||
### PSR-2 Coding Standard compliance
|
### <a name="psr2"></a>PSR-2 Coding Standard compliance
|
||||||
|
|
||||||
You can use the [php codesniffer](https://github.com/squizlabs/PHP_CodeSniffer) tool
|
You can use the [php codesniffer](https://github.com/squizlabs/PHP_CodeSniffer) tool
|
||||||
to not only detect and lint PSR-2 coding errors, but also do some minimal automatic
|
to not only detect and lint PSR-2 coding errors, but also do some minimal automatic
|
||||||
@ -1698,7 +1698,7 @@ code style migration.
|
|||||||
Repeat the final step and manually repair suggested changes, as necessary,
|
Repeat the final step and manually repair suggested changes, as necessary,
|
||||||
until you no longer have any linting issues.
|
until you no longer have any linting issues.
|
||||||
|
|
||||||
### PSR-4 autoloading for project code
|
### <a name="psr4"></a>PSR-4 autoloading for project code
|
||||||
|
|
||||||
While not critical to an upgrade, SilverStripe 4.0 has adopted the [PS-4 autoloading](http://www.php-fig.org/psr/psr-4/)
|
While not critical to an upgrade, SilverStripe 4.0 has adopted the [PS-4 autoloading](http://www.php-fig.org/psr/psr-4/)
|
||||||
standard for the core modules, so it's probably a good idea to be consistent.
|
standard for the core modules, so it's probably a good idea to be consistent.
|
||||||
|
Loading…
Reference in New Issue
Block a user