Deploying content deletes existing attached media files

[ovekaaven]

Describe the bug

If I export/deploy a new version of a content item with attached media from our staging server (without also exporting media), and import it into the production server, then all media files already attached to the content item gets deleted from the production server.

This is annoying if the new version did not change these media files, then they are just gone for no good reason, and we keep having to re-deploy the media files.

Orchard Core version

Currently on 2.0.2, but I think this bug has existed forever.

To Reproduce

1. On the source site, create and publish a content item with some attached media.
2. Deploy this onto the target site, along with the necessary media.
3. On the source site, publish a new version of the item, with no changes to the media.
4. Deploy this onto the target (only export the content item, not the media, i.e., what the "Export Content to Deployment Target" feature does).
5. Notice that, on the target, the attached media is no longer there.

Expected behavior

Existing attached media should still be there after a new content version is deployed. Or even better, Orchard Core could automatically export any attached media when exporting content items.

Either way, it should not be necessary to separately deploy a huge media database every time the text of some content item is updated through the import system, or at least the relevant media ought not to be missing on the production server while such a media database deployment is in progress.

Cause

After digging through the code, I think the problem starts in DefaultContentManager.CreateContentItemVersionAsync. When creating a published content item, it calls RemoveVersionsAsync, which creates a RemoveContentContext with NoActiveVersionLeft == true (even though a new active version is about to be created). Then AttachedMediaFieldContentHandler.RemovedAsync looks at NoActiveVersionLeft, sees that it's true, and deletes the attached media folder.

So a possible fix may be to set NoActiveVersionLeft to false instead, but I have no idea about the repercussions of doing so. There might have been a reason for setting it to true in the first place?

[github-actions]

We triaged this issue and set the milestone according to the priority we think is appropriate (see the docs on how we triage and prioritize issues).

This indicates when the core team may start working on it. However, if you'd like to contribute, we'd warmly welcome you to do that anytime. See our guide on contributions here.