In the storage_core_bridge_storage_generate() styled images are being generated with a source based on the getUri() output of the storage object's parent. This works fine initially but some modules and image effects expects a source image path that be used to identify the original image.
Since the only available data in the function is the storage object and its parent, and I couldn't find any methods for getting the drupal URI from a storage object, the URI is looked up from the DB based on the ID of the storage object.
Also, the StorageTempURI class has been modified to support temp URIs that holds a reference back to the original URI. As long as the StorageTempURI is treated as an object, the getOriginalURI() method can be called. But the path of the temp file is also adjusted to match the original URI, so even if the StorageTempURI object is converted into a string (the temporary:// URI), that string can be converted back to the original URI by using StorageTempURI::decodeTempURI($temp_uri).
Comments
Comment #1
esbenvb commentedThis is the patch containing the changes.
Remember to do the right attributions when porting patches, as mentioned on http://drupal.org/user/989064
Comment #2
esbenvb commentedThis patch is an example of where this can be useful.
http://drupal.org/node/1943166
Comment #3
jbrown commentedThanks for this - I'll take a closer look at it.
Comment #4
esbenvb commentedI've removed some of the fancy stuff with temp paths matching original URL as it was not used anyway and i suspect that it is causing trouble...
Comment #5
thijsvdanker commentedI've tested it and it works great, thanks esbenv!
I can't say I've reviewed it.. my knowledge of storage api is too limited to know if it's the most suitable solution :)
Comment #6
dwatts3624 commentedI've tested this (re. the manualcrop application) and everything works great!
Comment #7
josh.fabeanI tested this as of today (May 13 2015) and patch in comment #4 works great on latest dev build. Any reason why this isn't patched on the module yet this would save people time and frustration.
Comment #8
perignon commentedHasn't been on the radar since I took over as a co-maintainer. I been working backwards trying to see if there is any traction on old issues.
Comment #9
perignon commentedHrm.. patch has to be re-rolled.
Comment #10
perignon commentedYikes... I attempted a branching re-roll to 7.x-1.6 and it wasn't pretty. I had to trash it. This may require a manual re-coding type of re-roll.
Comment #11
queenvictoria commentedI've rerolled this against -dev trying to fix another issue. It didn't fix my issue but it should apply cleanly and didn't break anything (more than it was already anyway).
Comment #12
perignon commented@queenvictoria. Thanks for the work. I will work on getting it applied toward the end of the week. Out on vacation at the moment.
Comment #14
perignon commentedCommitted. Needs a little testing out of the dev branch then we can mark this as fixed.
Comment #15
jonhattangetOriginalURI() method seems unneccesary. It is not used anywhere.
Comment #16
perignon commentedI'll check that out. Removing unused code is always welcomed with this elephant of a module.