mirror of
https://github.com/silverstripe/silverstripe-framework
synced 2024-10-22 14:05:37 +02:00
DOC Update change log to reference updated migration task (#8945)
* DOC Update change log to reference updated migration task * Update docs/en/04_Changelogs/4.4.0.md
This commit is contained in:
parent
4155b9f483
commit
54cb591f54
@ -11,6 +11,27 @@
|
|||||||
|
|
||||||
## Upgrading {#upgrading}
|
## Upgrading {#upgrading}
|
||||||
|
|
||||||
|
### Adopting to new `_resources` directory
|
||||||
|
|
||||||
|
The name of the directory where vendor module resources are exposed can now be configured by defining a `extra.resources-dir` key in your `composer.json` file. If the key is not set, it will automatically default to `resources`. New projects will be preset to `_resources`.
|
||||||
|
This will avoid potential conflict with SiteTree URL Segments.
|
||||||
|
|
||||||
|
1. Update your `.gitignore` file to ignore the new `_resources` directory. This file is typically located in the root of your project or in the `public` folder.
|
||||||
|
2. Add a new `extra.resources-dir` key to your composer file.
|
||||||
|
```js
|
||||||
|
{
|
||||||
|
// ...
|
||||||
|
"extra": {
|
||||||
|
// ...
|
||||||
|
"resources-dir": "_resources"
|
||||||
|
}
|
||||||
|
}
|
||||||
|
```
|
||||||
|
3. Expose your vendor assets by running `composer vendor-expose`.
|
||||||
|
4. Remove the old `resources` folder. This folder will be located in the `public` folder if you have adopted the public web root, or in the root of your project if you haven't.
|
||||||
|
|
||||||
|
You may also need to update your server configuration if you have applied special conditions to the `resources` path.
|
||||||
|
|
||||||
### Optional migration to hash-less public asset URLs {#hashless-urls}
|
### Optional migration to hash-less public asset URLs {#hashless-urls}
|
||||||
|
|
||||||
SilverStripe 4.x introduced an [asset abstraction](https://docs.silverstripe.org/en/4/developer_guides/files/file_storage/)
|
SilverStripe 4.x introduced an [asset abstraction](https://docs.silverstripe.org/en/4/developer_guides/files/file_storage/)
|
||||||
@ -34,7 +55,7 @@ The original "hashed" file paths continue to work through redirects.
|
|||||||
In order to opt-in to moving these files, run the following command:
|
In order to opt-in to moving these files, run the following command:
|
||||||
|
|
||||||
```
|
```
|
||||||
TODO File migration task command
|
vendor/bin/sake dev/tasks/MigrateFileTask
|
||||||
```
|
```
|
||||||
|
|
||||||
Note that you can run this task without CLI access by installing and configuring
|
Note that you can run this task without CLI access by installing and configuring
|
||||||
@ -42,27 +63,6 @@ the [queuedjobs](https://github.com/symbiote/silverstripe-queuedjobs) module.
|
|||||||
|
|
||||||
Further information is provided in the [Hash-less Public Asset URLs FAQ](#hashless-faq) below.
|
Further information is provided in the [Hash-less Public Asset URLs FAQ](#hashless-faq) below.
|
||||||
|
|
||||||
### Adopting to new `_resources` directory
|
|
||||||
|
|
||||||
The name of the directory where vendor module resources are exposed can now be configured by defining a `extra.resources-dir` key in your `composer.json` file. If the key is not set, it will automatically default to `resources`. New projects will be preset to `_resources`.
|
|
||||||
This will avoid potential conflict with SiteTree URL Segments.
|
|
||||||
|
|
||||||
1. Update your `.gitignore` file to ignore the new `_resources` directory. This file is typically located in the root of your project or in the `public` folder.
|
|
||||||
2. Add a new `extra.resources-dir` key to your composer file.
|
|
||||||
```js
|
|
||||||
{
|
|
||||||
// ...
|
|
||||||
"extra": {
|
|
||||||
// ...
|
|
||||||
"resources-dir": "_resources"
|
|
||||||
}
|
|
||||||
}
|
|
||||||
```
|
|
||||||
3. Expose your vendor assets by running `composer vendor-expose`.
|
|
||||||
4. Remove the old `resources` folder. This folder will be located in the `public` folder if you have adopted the public web root, or in the root of your project if you haven't.
|
|
||||||
|
|
||||||
You may also need to update your server configuration if you have applied special conditions to the `resources` path.
|
|
||||||
|
|
||||||
### Hash-less Public Asset URLs FAQ {#hashless-faq}
|
### Hash-less Public Asset URLs FAQ {#hashless-faq}
|
||||||
|
|
||||||
#### How are files named and renamed?
|
#### How are files named and renamed?
|
||||||
@ -73,9 +73,9 @@ Here's an example of how file names changed during an initial 4.x migration, and
|
|||||||
* File migrated under SS 4.x with `legacy_filenames=false`: `assets/[content-hash]/myfile.pdf` (Regression: links to `assets/myfile.pdf` no longer work)
|
* File migrated under SS 4.x with `legacy_filenames=false`: `assets/[content-hash]/myfile.pdf` (Regression: links to `assets/myfile.pdf` no longer work)
|
||||||
* File migrated under SS 4.x with `legacy_filenames=true`: `assets/myfile.pdf`
|
* File migrated under SS 4.x with `legacy_filenames=true`: `assets/myfile.pdf`
|
||||||
* File with updated file content under SS 4.x: `assets/[new-content-hash]/myfile.pdf` (Regression: links to `assets/[content-hash]/myfile.pdf` no longer work)
|
* File with updated file content under SS 4.x: `assets/[new-content-hash]/myfile.pdf` (Regression: links to `assets/[content-hash]/myfile.pdf` no longer work)
|
||||||
* File with hotfix applied (SS 4.2.3): `assets/[new-content-hash]/myfile.pdf` (redirects to `assets/myfile.pdf`)
|
* File with hotfix applied (SS 4.2.3): `assets/myfile.pdf` and `assets/[old-content-hash]/myfile.pdf` redirects to `assets/[new-content-hash]/myfile.pdf`
|
||||||
* File with full fix applied (SS 4.3.x) : `assets/myfile.pdf` (no redirect required)
|
* File with full fix applied (SS 4.3.x) : `assets/myfile.pdf` and `assets/[old-content-hash]/myfile.pdf` redirects to `assets/[new-content-hash]/myfile.pdf`
|
||||||
* Newly uploaded file with full fix applied: `assets/my-other-file.pdf` (no redirect required)
|
* Newly uploaded file with full fix applied (SS 4.4.0): `assets/my-other-file.pdf` (no redirect required)
|
||||||
|
|
||||||
More details on how files are stored can be found in the
|
More details on how files are stored can be found in the
|
||||||
["File Storage" guide](/developer_guides/files/file_storage).
|
["File Storage" guide](/developer_guides/files/file_storage).
|
||||||
@ -91,7 +91,13 @@ If you have a high traffic site with lots of direct references to asset URLs
|
|||||||
we recommend that you configure HTTP caching for these redirects
|
we recommend that you configure HTTP caching for these redirects
|
||||||
in your webserver (e.g. through `.htaccess`).
|
in your webserver (e.g. through `.htaccess`).
|
||||||
|
|
||||||
The redirect code can be configured via `FlysystemAssetStore.redirect_response_code`.
|
The redirect code can be configured via `FlysystemAssetStore.permanent_redirect_response_code`.
|
||||||
|
|
||||||
|
If you upgrade an older SilverStripe 4 project to SilverStripe 4.4 and choose not to run the file migration task,
|
||||||
|
your files will still be stored under an "hash" folder. Browsers who try to access this file via the "hashless" url will
|
||||||
|
be redirected to the "hash" URL with a `302 Temporary Redirect`.
|
||||||
|
|
||||||
|
The temporary redirect code can be configured via `FlysystemAssetStore.redirect_response_code`.
|
||||||
|
|
||||||
#### Do I need to regenerate HTML with existing links to assets?
|
#### Do I need to regenerate HTML with existing links to assets?
|
||||||
|
|
||||||
@ -120,12 +126,16 @@ this can lead to improved search engine rankings (since existing files under new
|
|||||||
|
|
||||||
#### Can I migrate away from the legacy_filenames=true option?
|
#### Can I migrate away from the legacy_filenames=true option?
|
||||||
|
|
||||||
Technically yes, but there’s no official migration script for it.
|
Yes. Simply disable `legacy_filenames` in your YML configuration, then run the `MigrateFileTask`. This will normalise
|
||||||
|
the path of all existing assets.
|
||||||
|
|
||||||
#### Can I still choose legacy_filenames=true when starting new upgrades?
|
#### Can I still choose legacy_filenames=true when starting new upgrades?
|
||||||
|
|
||||||
Technically yes, but you need to be aware of the tradeoffs.
|
Technically yes, but you need to be aware of the tradeoffs. Once the regression has been fixed, we don’t see the need
|
||||||
Once the regression has been fixed, we don’t see the need for people to choose this option any more.
|
for people to choose this option any more.
|
||||||
|
|
||||||
|
SilverStripe 4.4, ignores the `legacy_filenames` in most situation. Enabling `legacy_filenames` on a fresh SilverStripe
|
||||||
|
4.4 installation will have no affect.
|
||||||
|
|
||||||
#### How do I test that the fix has worked on my site?
|
#### How do I test that the fix has worked on my site?
|
||||||
|
|
||||||
@ -133,8 +143,9 @@ Before applying the upgrade and migration script:
|
|||||||
Find an existing published and draft file. Get the link by clicking on the preview in `admin/assets`.
|
Find an existing published and draft file. Get the link by clicking on the preview in `admin/assets`.
|
||||||
It should link to `assets/[hash]/myfile.pdf`.
|
It should link to `assets/[hash]/myfile.pdf`.
|
||||||
|
|
||||||
After applying the upgrade and migration script, you can test that it applied correctly.
|
After applying the upgrade and migration task, you can test that it applied correctly.
|
||||||
Please perform these tests on a test or UAT environment, since your local environment might have different routing conditions.
|
Please perform these tests on a test or UAT environment, since your local environment might have different routing
|
||||||
|
conditions.
|
||||||
|
|
||||||
* Check that the file still routes correctly with the hash in place (should redirect)
|
* Check that the file still routes correctly with the hash in place (should redirect)
|
||||||
* Remove `[hash]/`, and check that it still routes correctly (should not redirect)
|
* Remove `[hash]/`, and check that it still routes correctly (should not redirect)
|
||||||
|
Loading…
Reference in New Issue
Block a user