silverstripe-framework/docs/en/04_Changelogs/4.6.0.md

4.6.0 (Unreleased)

Overview

• MySQL tables are auto-converted from MyISAM to InnoDB
• Editing files directly in the insert-media modal
• MIME Type validation now a core module
• Solr no longer indexes draft/restricted content

MySQL tables are auto-converted from MyISAM to InnoDB

Beginning with 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 is the new default storage engine, replacing the older MyISAM 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:

• Adding the FulltextSearchable extension to a DataObject, as described in our search docs
• Defining 'type' => 'fulltext' in DataObject::$db column definitions
• Implementing DBIndexable 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 choosing a more powerful search addon (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 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:

use SilverStripe\ORM\Connect\MySQLSchemaManager;
use SilverStripe\ORM\DataObject;

class MyDataObject extends DataObject
{
    private static $create_table_options = [
            MySQLSchemaManager::ID => 'ENGINE=MyISAM'
    ];
}

Editing files directly in the Insert Media modal

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.

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.

Implementing the new Edit Details UI required filtering the fields generated in File::getCMSFields() into two Forms. The implementation in 4.6.0 does not expose a clear API to custom fields for differentiating between the Forms, 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 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

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 in the Silverstripe CMS doc for all the details.

Solr no longer indexes draft/restricted content

At the time of this release a new version of the popular silverstripe/fulltextsearch module is also available, introducing more secure defaults. Most notably, draft and restricted content will no longer be indexed by default, due to a canView() check being performed against an anonymous user prior to (re)indexing. Restricted content means that it has a permission level of either 'Logged-in users' or 'Only these groups'.

If your project uses this module, after upgrading your website, ensure that you run the Solr_Reindex task on your production environment to remove previously indexed content that should no longer be there.

If your website requires draft or restricted content to be indexed, you can opt-out of the new secure defaults on a per-model basis.

This is a great opportunity to make sure that any custom indexes/search controllers in your project are correctly filtering results based on permissions and search visibility, which you can now achieve via a unified method (see SilverStripe\FullTextSearch\Search\Services\SearchableService::isSearchable().)

The silverstripe/fulltextsearch module readme provides additional information.

Regressions

• File section, icons broken until page is refreshed