mirror of
https://github.com/silverstripe/silverstripe-framework
synced 2024-06-28 15:39:40 +02:00
Consistent anchors in changelog headliens
This commit is contained in:
Ingo Schommer
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
|
||||
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.
|
||||
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
|
||||
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
|
||||
[upgrader tool](https://github.com/silverstripe/silverstripe-upgrader/) for this purpose.
|
||||
|
|
@ -143,7 +143,7 @@ Install it via composer:
|
|||
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
|
||||
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),
|
||||
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`.
|
||||
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.
|
||||
|
||||
### Migrate File DataObject
|
||||
### <a name="migrate-file"></a>Migrate File DataObject
|
||||
|
||||
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)).
|
||||
|
|
@ -272,7 +272,7 @@ SilverStripe\Assets\FileMigrationHelper:
|
|||
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.
|
||||
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,
|
||||
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
|
||||
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
|
||||
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
|
||||
```
|
||||
|
||||
### 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.
|
||||
|
||||
|
|
@ -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()`.
|
||||
|
||||
### Template locations and references
|
||||
### <a name="template-locations"></a>Template locations and references
|
||||
|
||||
Templates are now more strict about their locations.
|
||||
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.
|
||||
|
||||
### 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:
|
||||
|
||||
|
|
@ -451,7 +451,7 @@ To ensure consistency, we've also deprecated support for path constants:
|
|||
* Deprecated `THEMES_DIR` and `THEMES_PATH`
|
||||
* 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
|
||||
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
|
||||
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
|
||||
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
|
||||
`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
|
||||
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
|
||||
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 %>
|
||||
```
|
||||
|
||||
### 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)
|
||||
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)
|
||||
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
|
||||
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');
|
||||
```
|
||||
|
||||
### 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
|
||||
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)
|
||||
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)
|
||||
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
|
||||
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
|
||||
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
|
||||
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
|
||||
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,
|
||||
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/)
|
||||
standard for the core modules, so it's probably a good idea to be consistent.
|
||||
|
|
|
|||
Loading…
Reference in New Issue
Block a user