Attached is a patch which changes a few lines and variables to the _imagecache_apply_action function also passes along the presetid.

I'm busy writing a 'javascript_crop' action in a custom module (screencast coming soon) where I store x and y offsets in a seperate database if the users wishes to change the default offsets set in the action. Since it's possible to have multiple presets, it's dangerous to just find my data in the database alone with the source file which is passed along in the &$image variable.

Would be great if this got in for the official release. I guess it needs soms refactoring though, but the principle works here.



dman’s picture

I can't see why passing better context information would be a bad thing, and the code (visually/untested) looks sensible.

dopry’s picture

Version: 5.x-2.0-beta » 6.x-2.x-dev
Status: Needs review » Postponed (maintainer needs more info)

@swentel.... I totally haven't forgotten about you... I'm still concerned about passing the presetid into the actions... I wanted it to just be the actions themselves... so their forms are more portable and not dependant on how imagecache works or stores data... A trick you can use to funnel the presets though is to use a #after_build or #submit to grabs the preset id from the form the action form gets merged with... I'd like to give that shot before modifying the imagecache pipeline... Do you feel up to it or should I take a bang at it when I get free time?


swentel’s picture

My crop callback in my actions file looks like this:

// with my patch
function imagecrop_javascript_image(&$image, $data, $presetid) {
  // Get the x and y offset and (optional) the size to determine the crop for this file for preset $presetid
  // do some cropping now

I'm not sure how using #after_build or grabbing it from the #submit would help me if I don't have the $presetid because the only thing at this point I have is the filename and it's possible to have 2 (or more) presets with my action in them.


Another trick I just thought of is maybe using arg(1) in my callback which should give me the preset name. It should be safe, because since my function is called, it means imagecache allready knows the presetname is a valid one. I can do 2 things then:
a) either store the name instead of presetid in my table per file
b) lookup the preset id which should not produce to much overhead since imagecache caches the presets.

So I think I have a solution without patching ImageCache. I'm going to test that this evening (also with imagecache2-rc1) and I'll report back.

swentel’s picture

Status: Postponed (maintainer needs more info) » Closed (fixed)

Good news! It's actually arg(2) that gives me the presetname and with this I have enough, so the patch isn't needed at all, imagecache can be as you intented.

Release candidate of imagecache 2 and rc5 imageapi are working great also, just tested them with my module and no errors (so far). It leaves me to one problem where a caching problem on IE forces users to press F5 in my popup, but I think this is more a browser issue (firefox works fine) then imagecache's fault.

I still wonder why I haven't thought of the 'arg' function 2 months ago .. anyway, closing!