EZP-21324: Fixed missing references to copied image attributes #792
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
added 22 commits
October 16, 2013 10:51
- eZImageType::postStore() adds references from ezimage attributes - An update script (update/common/5.3/restoreimageslinks.php will add missing relations for existing data
Also changed removeAlias code. Should now check correctly: - only remove ezimagealias entries when they're not used anymore (handles duplicates if any) - only removed files when not used anymore. This means that we accept that when a copy of a content with an image is made, we accept that archived versions in the copy will reference the same file than archive versions in the copy source.
Doesn't accept an eZContentObjectAttribute argument anymore. The method is always invoked on the instance it must be modified.
fetchListByFilePath now uses asObject=false, since it doesn't really make sense to return incomplete objects (due to the duplicates inserted in ezimagefile)
We just don't use it anymore. removeAliases() does the job. The only difference is that removeAliases() will set the attribute's XML to an empty value, while removeAllAliases() won't, meaning that the change will create a light overhead on the database.
testRemoveCopy also checks that the deleted attributes are no longer referenced by any ezimagefile record
`eZImageType::postStore()` won't add duplicates to ezimagefile anymore.
Now tests that all alias files are effectively removed from ezimagefile. Current fails on one of the V1 aliases.
Tests the case where the published version of an image has more aliases than the archived versions: during copy(), references to those aliases are created by eZImageType::postStore(), but are copied to new references instead of being removed, since the attribute is not the image owner. These ezimagefile entries are orphan ones, and aren't removed when the object is deleted.
|
Note: the failure above shouldn't be related to this PR (StaleCache thing). |
| $aliasList = $this->aliasList(); | ||
| $alternativeText = false; | ||
| if ( $aliasFile == '' ) | ||
| throw new InvalidArgumentException( "Expecting image file path" ); |
There was a problem hiding this comment.
So we use exceptions now in legacy ? 😉
|
Wow, this is speleology ! Review ping @andrerom @dpobel @yannickroger @pspanja |
|
After todos are completed +1 |
|
+1 |
| continue; | ||
|
|
||
| // Creates ezimagefile entries | ||
| foreach ( $doc->xpath( "//*/@url" ) as $url ) |
There was a problem hiding this comment.
"//@url" might be more efficient to handle?
| return; | ||
|
|
||
| // Creates ezimagefile entries | ||
| foreach ( $doc->xpath( "//*/@url" ) as $url ) |
There was a problem hiding this comment.
"//@url" might be more efficient to handle?
There was a problem hiding this comment.
Well, it comes from your patch, so...
There was a problem hiding this comment.
I missed reviewing my own work ;)
|
Looks good so far, todos aside: +1 |
1 task
|
Replaced by #825. |
1 task
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
See http://jira.ez.no/browse/EZP-21324
Replaced by #825
This PR fixes a use-case where image files from content A might be deleted when content B is deleted.
Use-case
The consequence is that when B version 1 gets deleted (either manually, or because the version limit gets reached, or when B is deleted, the image used by A (both versions) will get deleted.
Fix
The PR fixes:
Changes
Removal of aliases has been totally refactored, and should work fine with the way we store data now.
purgeAliases(), used by eZCache, has been refactored to use the same code (with tests).TODO
removeAliases()code (used when a specific version is removed)eZImageFile::fetchListByFilePath()(group by error)removeAllAliases()code (used when a complete content object is removed)ezimagefilerecords are left behind