This feature needs to be optional, as there are plenty of use cases where the current behavior (crops being global for every instance of the $file->fid) is useful. Planning on doing work on this soon.
| Comment | File | Size | Author |
|---|---|---|---|
| #4 | epsacrop-revision-support-1497484.patch | 11.49 KB | Nick Lewis |
| #3 | epsacrop-revision-support-1497484.patch | 10.54 KB | Nick Lewis |
Comments
Comment #1
Nick Lewis commentedYvan, wanted to get your 2 cents on what I'm thinking:
1. function epsacrop_ajax($op, $fid) - this seems like the place that the patch starts... we gotta send it a nid/vid from somewhere. This is where we will.
2. function epsacrop_crop_image(stdClass $image, $settings) This is where it gets tricky. We assume that the $file->fid's path is all we need to find the crop settings, when in fact (especially with media.module) its common for the same piece of content to share the same fid. We are completely blind to any concept of nid/vid.
The path of least resistance is to figure out how to encode nid/vid (or entity ids for that matter) into the cropped image in such a way that that we can use the data to serve different crops per node/revision.
We already have entity/bundle info I suppose, so that's less of a challenge.
Also:
Super old related Issues:
1. #918780: Revision support?
2. {#1110676]
Comment #2
Nick Lewis commentedThis comment is just noise, see patch below.
Comment #3
Nick Lewis commentedAttached is a first pass. Never the less, this patcch adds revision support for images, captions, media fields, and all. You'd want to setup the media library to hide any "revision files".
The patch makes some stupid assumptions.
1. you are using media 7.x.2.x.
2. the field in question is field_image
3. You are using workbench_moderation
Comment #4
Nick Lewis commentedSorry, forgot to add the db_update function to allow unsigned values. This issue is related to this one too: #1241976: Mention the File Entity Revisions module in the projects page as a companion module.