tonyair/silverstripe-framework
1
0
Fork 0
mirror of https://github.com/silverstripe/silverstripe-framework synced 2024-10-22 14:05:37 +02:00
Code Issues Projects Releases Wiki Activity

Consistent anchors in changelog headliens

Browse Source
This commit is contained in:
Ingo Schommer 2017-10-24 22:41:18 +13:00
parent 19d33f4de7
commit 69f16c605c
1 changed files with 23 additions and 23 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

46
docs/en/04_Changelogs/4.0.0.md
View File

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