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.

Comments

Nick Lewis’s picture

Yvan, 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]

Nick Lewis’s picture

This comment is just noise, see patch below.

Nick Lewis’s picture

Status: Active » Needs work
StatusFileSize
new10.54 KB

Attached 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

Nick Lewis’s picture

StatusFileSize
new11.49 KB

Sorry, 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.