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

Merge pull request #9558 from creative-commoners/pulls/4.6/improve-upgrade-notes

Browse Source 
4.6.0 changelog improvements
This commit is contained in:
Serge Latyntsev 2020-06-26 07:31:28 +12:00 committed by GitHub
commit 0de4ab1390
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 43 additions and 32 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

75
docs/en/04_Changelogs/4.6.0.md
View File

@ -9,40 +9,38 @@
## MySQL tables are auto-converted from MyISAM to InnoDB {#myisam}
Beginning with [4.4.0](https://docs.silverstripe.org/en/4/changelogs/4.4.0/),
our minimum requirement for MySQL is 5.6 (since MySQL 5.5 end of life reached in December 2018).
Starting with MySQL 5.6, [InnoDB](https://dev.mysql.com/doc/refman/5.6/en/innodb-introduction.html)
is the new default storage engine,
replacing the older [MyISAM](https://dev.mysql.com/doc/refman/5.6/en/myisam-storage-engine.html) engine.
our minimum requirement for MySQL is 5.6 (since MySQL 5.5 end of life reached in
December 2018). Starting with MySQL 5.6, [InnoDB](https://dev.mysql.com/doc/refman/5.6/en/innodb-introduction.html)
is the new default storage engine, replacing the older [MyISAM](https://dev.mysql.com/doc/refman/5.6/en/myisam-storage-engine.html)
engine.
Silverstripe CMS already creates InnoDB tables by default,
mainly in order to benefit from their better support for database transactions.
Before MySQL 5.6, InnoDB didn't have a `FULLTEXT` search index,
requiring us to enforce the MyISAM engine when devs opted into this index type
in their particular setup. There are a few ways in which this opt-in can happen:
Silverstripe CMS already creates InnoDB tables by default, mainly in order to
benefit from their better support for database transactions. Before MySQL 5.6,
InnoDB didn't have a `FULLTEXT` search index, requiring us to enforce the MyISAM
engine when devs opted into this index type in their particular setup. There are
a few ways in which this opt-in can happen:
* Adding the [FulltextSearchable](https://github.com/silverstripe/silverstripe-framework/blob/4/src/ORM/Search/FulltextSearchable.php)
extension to a DataObject, as described in our
[search docs](https://docs.silverstripe.org/en/4/developer_guides/search/fulltextsearch/)
extension to a DataObject, as described in our [search docs](https://docs.silverstripe.org/en/4/developer_guides/search/fulltextsearch/)
* Defining `'type' => 'fulltext'` in `DataObject::$db` column definitions
* Implementing [DBIndexable](https://github.com/silverstripe/silverstripe-framework/blob/4/src/ORM/FieldType/DBIndexable.php)
on a custom `DBField` subclass.
* Setting `'ENGINE=MyISAM'` in `DataObject::$create_table_options`
This search index is not required to enable simple text search
in the "Pages" section of the CMS, or any ModelAdmin implementations.
We generally recommend to choose a more powerful
[search addon](https://addons.silverstripe.org/add-ons?search=fulltext&type=&sort=downloads)
This search index is not required to enable simple text search in the "Pages"
section of the CMS, or any ModelAdmin implementations. We generally recommend
choosing a more powerful [search addon](https://addons.silverstripe.org/add-ons?search=fulltext&type=&sort=downloads)
(e.g. based on Solr or ElasticSearch) for website frontend search use cases.
As of 4.6.0, a `dev/build` will automatically switch MyISAM tables to InnoDB,
which automatically recreates any indexes required. If you have large indexes,
this can extend the duration if this task. As usual, back up your database
before upgrading, and test upgrades on non-production systems first.
Our tests indicate that indexes with thousands of records and screen pages
worth of content (15MB index size) are converted in a few seconds.
this can extend the duration of this task. As usual, back up your database
before upgrading, and test upgrades on non-production systems first. Our tests
indicate that indexes with thousands of records and screen pages worth of
content (15MB index size) are converted in a few seconds.
In order to opt out of this change, you can set the engine explicitly
for your DataObject implementations:
In order to opt out of this change, you can set the engine explicitly for your
DataObject implementations:
```php
use SilverStripe\ORM\Connect\MySQLSchemaManager;
@ -56,24 +54,37 @@ class MyDataObject extends DataObject
}
```
## Editing files directly in the insert-media modal{#in-modal-editing}
## Editing files directly in the Insert Media modal {#in-modal-editing}
Editors can now directly edit file details when selecting a file in an UploadField or when inserting media in a
HTMLEditorField. The "image placement" and "file link" forms that show when inserting an image or a link in an
HTMLEditorField have been simplified.
Authors can now directly edit file details when selecting a file in an
`UploadField` or when inserting media in a `HTMLEditorField`. The "image
placement" and "file link" forms that show when inserting an image or a link in
an `HTMLEditorField` have been simplified.
This does mean that the order and structure of fields have changed somewhat. If you have customised the forms in the
asset administration area or in the "Insert Media Modal", you should do some regression testing when upgrading to
make sure your customisations still work as expected.
If you have customised the fields in the asset administration UI or Insert Media
modal, you will need to do some regression testing when upgrading, and will
likely need to make some minor adjustments to your code.
If your project uses the popular [jonom/focuspoint](https://github.com/jonom/silverstripe-focuspoint) community
module, you should upgrade it as well.
Implementing the new Edit Details UI required filtering the fields generated in
`File::getCMSFields()` into two `Form`s. The implementation in 4.6.0 does not
expose a clear API to custom fields for differentiating between the `Form`s, and
by default any fields added via an extension will appear in both views. For the
time being, a simple way to resolve this is to check for the presence of the
`Editor.Details.Title` field and add your field based on this. See the community
module [jonom/focuspoint](https://github.com/jonom/silverstripe-focuspoint/pull/78/files#diff-cc697eb8345aa25a5f88c89d1a87ff6aR27-R34)
for an example implementation, and ensure you update this module during your
upgrade to 4.6.0 if you have it installed.
We intend to improve this pattern in a future release of Silverstripe CMS.
## MIME Type validation now a core module {#mime-validator}
`silverstripe/mimevalidator` is now a core module and will ship by default on new projects. Projects referencing `silverstripe/recipe-core` will automatically install `silverstripe/mimevalidator` when they upgrade to 4.6.0.
`silverstripe/mimevalidator` is now a core module and will ship by default on
new projects. Projects referencing `silverstripe/recipe-core` will automatically
install `silverstripe/mimevalidator` when they upgrade to 4.6.0.
Read [Allowed file types](Developer_Guides/Files/Allowed_file_types) in the Silverstripe CMS doc for all the details.
Read [Allowed file types](Developer_Guides/Files/Allowed_file_types) in the
Silverstripe CMS doc for all the details.
<!--- Changes below this line will be automatically regenerated -->