File sub-class (child class) is transformed into generic File when saved or published from the CMS

[mikenuguid]

Module version(s) affected

1.13.12

Description

Issue

A sub-class of File gets transformed into generic File if saved and published from the asset admin.

Description

I have a current use case where I am associating a specific set of file extension e.g. pdf to both generic File::class and its subclass, say ChildFile::class. ChildFile has extra properties that are incompatible with the generic File::class so they both need to co-exist.

There is a config class_for_file_extension which is used for mapping the file extension to a new File class. However, I cannot use this since the ChildFile is not backward compatible with generic File (and I want the current file types associated with File to continually work).

From what I could see, there is a check on the saveOrPublish() method responsible for this transformation:

if (!is_a($currentClass, $newClass ?? '', true) || ($currentClass !== $newClass && $newClass === File::class)) {
    $record = $record->newClassInstance($newClass);

    // update the allowed category for the new file extension
    $category = File::get_app_category($extension);
    $record->File->setAllowedCategories($category);
}

From the comments:

The class will not change if the current class is a subclass of the new class.
An exception is if new class is the generic File::class

I am wondering why the need to exempt the generic File::class (while if it is Image::class and there is a subclass of it say, ChildImage::class, both Image and ChildImage can be both associated with image types/extensions without the ChildImage forced to transform to Image)?

How to reproduce

How to replicate

1. Create a subclass of File, say ChildFile
2. Create a ChildFile record and save a .pdf file to it. Publish it.
3. View the ChildFile record on the CMS
4. Unpublish the ChildFile then Publish it
5. The class of the record is now File (instead of ChildFile)

Possible Solution

One way is to remove the second check for the $newClass if it's a File::class, to allow the $currentClass (being a subclass of FIle) to associate itself with file types meant for File::class

if (!is_a($currentClass, $newClass ?? '', true)) {
    $record = $record->newClassInstance($newClass);

    // update the allowed category for the new file extension
    $category = File::get_app_category($extension);
    $record->File->setAllowedCategories($category);
}

Additional Context

No response

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)