Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

EZP-30857: Fixed assessment of image removal feasibility #3056

Merged

Conversation

alongosz
Copy link
Member

@alongosz alongosz commented Aug 5, 2020

Question Answer
JIRA issue EZP-30857
Alternative to #2835
Required by #3057
Bug/Improvement yes
Target version 7.5, ezplatform-kernel:1.1+
BC breaks no
Doc needed no

When removing a Content item (or its Version) with a changed Image Field Type file, the file associated with a previous Version was not deleted from a file system.

This happened because relation of ezimagefile.contentobject_attribute_id to ezcontentobject_attribute.id does not contain Version number (attribute - a.k.a. Field - ID is the same for every Version).
One of the approaches would be to introduce versioning for ezimagefile (#2835). This however always causes issues due to BC break on schema.

Instead, I'm proposing an alternative - change of assessment if image can be removed based on ezimage data_text XML, which contains proper URI for a given Version. Instead of getting a count against a product of ezimagefile and ezcontentobject_attribute, data is fetched and processed to find the actual file system file URI for a given Version.

The count cannot work because the resulting Cartesian product (slice/intersection of data) is incorrect - joins file paths for all Versions with a Field. The join itself is kept to make sure we're joining existing ezimage entry (7dca764).

Additionally, I've discovered that image variations (aliases) are not removed at all. It didn't work because a produced file path was in the form of ../var/site/storage/images/_aliases/medium/var/site/storage/images/....
Fixed it by applying removal service on a relative original binay file identifier (41a0e43).

I've discovered two other CS and DX issues, but for now I'll make follow-up PRs. Moreover we deal here with a responsibility mixup - Doctrine Gateway should not process XML but just return data. That however is a candidate for ezplatform-kernel:master - see ezsystems/ezplatform-kernel#96.

QA

  • Filesystem state before/after Content & Version removal as described in the JIRA ticket.
  • Regression against EZP-30857.
  • Image variations (aliases) removal (can be generated by e.g. embedding image into a content - image and content removal did not delete variations).

Note: Physical files can be found (and should not be found after deleting) by the following command:

find web/var/site/storage -type f

TODO:

Copy link
Member

@mnocon mnocon left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Tested together with #3057

@alongosz alongosz merged commit 0e9fab1 into ezsystems:7.5 Aug 13, 2020
@alongosz alongosz deleted the fix-7.5/ezp-30857-remove-deleted-image-file branch August 13, 2020 12:41
@cmateo
Copy link

cmateo commented Mar 4, 2021

So, now the images are deleted from disk. But that will apply on future action of removing content. What about images that were not previously deleted ?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
5 participants