In some occasions it's useful to do something BEFORE the object is destroyed. For example, when you delete/destroy a file that incidentally is a profile picture (so, deleting an entity from the File application), the People application could have an hook to easily re-generate the involved profile picture, saving a new builtin image for the involved user. This should be done BEFORE the file is destroyed, since otherwise it's not possible to access all the files metadata and file attachments.
So, with a "Pre-Destruction" engine, we would have enough creative space to fix T16074, e.g. fix this when you destroy a file picture:
Why a "Pre-Destruction Engine"?
At the moment, re-generating a new profile picture seems NOT possible with the common "Destruction Engine", because to inspect the file attachments, we must be able to query them, but these are destroyed in a very early phase and it seems not possible to change the current behavior (and anyway it's probably too much risky to change this behavior it). https://we.phorge.it/T16074#22606
So, adding a new "Before Destruction" engine would give 100% backward compatibility, while introducing a super-handy pre-deletion hook to do things.
This hook is introduced to satisfy this specific profile-picture re-generation need after command line destruction, but note that this workflow could be even more useful in the future, when authors could potentially manage their own profile pictures and could delete them from the web with the already-existing Delete button (that now does not work - T15407), which then will cause destruction, and this should not cause 404 errors on that user page.
Nonsense additional use cases maybe relevant in the future, thanks to a brand-new "Before Destruction" engine:
- an extension could decide to define extra validations before destroying an object, and it could throw a custom exception if something is wrong, so, effectively impeding deletion. For example you could finally sell an extension named "Avoid Midnight Destructions Extension®" that effectively disables CLI destruction during small hours.
- (add something esoteric here?)
Proposed Implementation
BEFORE the object is destroyed permamently, so, BEFORE this line:
We could do a thing very similar to the already existing "Destruction Engine":
So we will introduce a "Pre-Destruction Engine", that will guarantee that something is fired BEFORE destroyObjectPermanently() is fired.
Seems simple and fun and safe, to add new features like T16074 but without years of nonsense super-mega refactors (that could potentially lead to a "Before Destruction Engine" anyway).