I noticed in the manualcrop database table that only the fid and isid are being stored (plus cropping info). That causes issues if you have two fields on the same node that uses the same fid and isid. So changing one ends up impacting the other as well. The use case is if a user wants to have two different crops of the same image on one node. I actually ran into this as I was testing and learning manualcrop.

Would it be possible to store the field id as well? I believe that would give you the required uniqueness for manualcrop info and avoid this issue.

Comments

dkingofpa’s picture

dkingofpa commented

An added benefit of storing the field id is that if a field is deleted, I believe you could also clean up the manualcrop entries at the same time. Not sure how that would impact the Reuse manualcrop image style effect.

matthijs’s picture

matthijs
Primary language Dutch
commented

Hi,

Thanks for your input, storing the fid should be possible, but and image style URI doesn't contain any field information what would mean that the module has to hook into all functions (formatters e.a.) that build image URI's.

It's hard to estimate, but I think this would be a lot of work for such a "small feature". Off course I could add the column and add some basic support (default formatters), but this can cause a lot of questions from users who's use case isn't supported...

Any suggestions?

Matthijs

dkingofpa’s picture

dkingofpa commented
Title: Two fields on one node using the same file and image style interfere with each other » manualcrops that are applied to the same file and image style interfere with each other

Actually, after thinking about it some more, I believe it's worse than I originally posted. It doesn't have to be two fields on the same node that use the same image. It happens any time the same fid and isid is used. Which could be more often than you think if users can select previously uploaded files via the Media library. That's functionality I add to every site I build now.

And just adding the field id probably isn't enough. A field can be reused across content types (and entities?).

rvilar’s picture

rvilar
Primary language Catalan
Location Montcada i Reixac, Catalonia
commented

I have the same problem in a project. There is a big database of more than 40.000 images that are used in a newspaper that creates a crop for any news that they need.

Can I help fixing this? Maybe it's out of the scope of this module?

gmclelland’s picture

gmclelland commented

Would their be any way to save the crop as a new managed file? Maybe include the option to also save the original as well?

ParisLiakos’s picture

ParisLiakos commented

there is no field id..we would need to store entity id, field name and delta.

or for starters just entity id

matthijs’s picture

matthijs
Primary language Dutch
commented
Project: Manual Crop (old) » Manual Crop
Version: 7.x-1.x-dev » 7.x-1.4
Status: Active » Closed (won't fix)

As rvilar already suggested this is a bit out of scope for Manual Crop. I understand the need for this feature/bug, but since Manual Crop works on top of image styles there are just to many todo's to make this possible...

If there's anybody willing to work I gladly accept and commit your patches!