I am using imagecrop as part of an images Feature, in which a number of imagecache presets are installed along with some supporting modules - smartcrop and javascript_crop. I'm using a version of javascript_crop (imagecrop) from CVS - DRUPAL-6--1:2010-09-24
Everything worked fine on the site I exported the feature from (using features 1.0). When I reinstalled the feature on a clean site (with all dependencies), I get this message whenever I try to use imagecrop:
No preset is found with the javascript_crop action so far. If you want to take advantage of this module, you will need to create at least one preset with that action.
The imagecache profiles are all installed, and most of them do feature a javascript_crop action. On checking those, everything has been transferred just fine.
Clearing the caches doesn't solve the problem.
Any ideas please?
Comments
Comment #1
steveparks commentedOn further investigation the problem appears to be in the imagecrop_action_exists() function in imagecrop.module at line 249:
Where imagecache presets are stored in a feature, they don't seem to get stored in the imagecache_action table - just in code.
Is there another way to do this - an imagecache API function perhaps - that doesn't rely on directly pulling from an imagecache table?
Thanks
Steve
Comment #2
nils.destoop commentedImagecrop is an imagecache action. So imagecache actions are needed to work.
I would try posting this on the imagecache project page, they need to export this, or all preset actions wont be imported with the feature.
Comment #3
steveparks commentedThe presets have been exported, and are in code in the Feature, along with the other imagecache actions.
Here's an example of what's exported:
However when the Feature is installed on a clean site, it gives the error message "No preset is found with the javascript_crop action so far. If you want to take advantage of this module, you will need to create at least one preset with that action."
It seems javascript_crop only looks in the database, while imagecache has these presets only in code.
The problem goes away if i choose to 'override' the imagecache preset, which then stores it in the database.
So is there a different way for javascript_crop to get the presets - via the imagecache API rather than direct from the DB perhaps?
Thanks
Steve
Comment #4
greg.harveySo, in essence, Imagecache javascript crop needs to
module_invoke_all('imagecache_default_presets')in order to process presets stored in code. At the moment the module makes the incorrect assumption all presets are in the database (which is why I've marked it as a bug report - you could argue it's a feature request, I won't protest). This was the case in early ImageCache versions, but hasn't been for some time.imagecrop_action_exists()needs to be re-written to invoke the appropriate ImageCache hook and check for corresponding actions in exported presets as well as the database check it already does.HTH! =)
Comment #5
greg.harveyLooked a bit deeper, seems there are a number of places the module assumes presets will be in the database and doesn't consider the exported to code option.
imagecrop_javascript_image()also seems to be affected.If it helps, there seems to be an ImageCache API function already,
imagecache_presets(), which returns all presets in a normalised way, regardless of storage mechanism. Contrib modules seeking to search for presets and actions within the database *and* code can use this API function to get back a safe list of presets without doing any gymnastics of their own. Take a look:http://drupalcontrib.org/api/function/imagecache_presets/6
Comment #6
steveparks commentedThanks Greg, that all makes sense.
Changing title to reflect this. It also seems to affect some other modules, so am opening similar issues there pointing here.
Comment #7
nils.destoop commentedI will take a look at it
Comment #8
nils.destoop commentedIt's working now, but i need to clean it a bit more. Monday i will do some refactoring.
Comment #9
nils.destoop commentedComment #10
nils.destoop commentedComment #11
steveparks commentedJust to confirm this now works very nicely.
Thanks for such a quick fix!