File history record not showing after updating class_for_file_extension config

[mikenuguid]

Module version(s) affected

2.2.3

Description

Hi Team,

I am not 100% sure if my understanding of this is accurate or is this a legit bug.

On File::get_class_for_file_extension(), it says Caution: Changes to mapping doesn't apply to existing file records in the database.. My interpretation for this is that the current or existing file record properties should not change even after updating the class_for_file_extension config i.e. if the extension was previously supported by SilverStripe\Assets\Image it should remain intact even after updating the extension to a new type say Model\Image. However, after updating this config, I could see that the version record for the existing file was updated to the new subclass.

This creates an issue when viewing the history records for the (existing) file because it doesn't fetch the previous versions from the previous class. This is what I see on on File_versions table after updating the config. Previously, it was SilverStripe\Assets\Image but get updated to Model\Image after changing the mapping config.

I want to double check if this is the intention for this confirg or is this a bug?

How to reproduce

1. Upload a file (image) on the CMS
2. Make sure to update the file to add new records on its history
3. Add a subclass for SilverStripe\Assets\Image

<?php

namespace Model;

use SilverStripe\Assets\Image as SilverstripeImage;

class Image extends SilverstripeImage
{
}

4. Update the class_for_file_extension config, make sure the extension is identical to the file uploaded e.g. png

---
Name: app_extensions
After:
  - '#assetsflysystem'
  - '#assetscore'
---
SilverStripe\Assets\File:
  class_for_file_extension:
    png: 'Model\Image'

5. Select the file uploaded on the asset admin. Then, unpublish then re-publish it.
6. Refresh the CMS and try to load the history tab
7. Returns error 500

Possible Solution

No possible solution in mind until there's clarity whether this is a bug or current expectation.

Additional Context

This could be related to a bug I reported on asset-admin, where a sub-class gets converted to a generic File::class. The difference is that the above converts existing record to a new class based on the new config mapping.

Validations

• Check that there isn't already an issue that reports the same bug
• Double check that your reproduction steps work in a fresh installation of silverstripe/installer (with any code examples you've provided)

[GuySartorelli]

Caution: Changes to mapping doesn't apply to existing file records in the database.

I interpret that to mean "data that is currently in the database won't be altered on flush if the configuration changes" - i.e. you may have records in the DB with a class name that doesn't match what your configuration says it should be, and that you may want to set up a BuildTask to update existing data to match your new configuration when you change it.

I don't think that warning was meant to imply the class reference won't be updated next time you save that record.