Add support for Imagecache 2

I wasn't able to get asset to completely work, but here's a start...

Two issues from a look over of the code...

1. The method in this patch of just substituting the new API functions in for their older counterparts won't work, since the return different objects
2. Since the Imagecache 2.x API attaches the actions to the presets when called, is it necessary to make another API call to fetch the actions when putting the formatters together?

_imagecache_get_presets() returns an array as:

$presets[$row['presetid']] = $row['presetname'];

that is,

Array(
   [1] => 'preset name'
   [2] => 'another preset' )

imagecache_presets() generates a different $presets object:

while ($preset = db_fetch_array($result)) {
      $presets[$preset['presetid']] = $preset;
      $presets[$preset['presetid']]['actions'] = imagecache_preset_actions($preset);
    }

which leads to:

Array
(
    [1] => Array
        (
            [presetid] => 1
            [presetname] => sidebar_user_image
            [actions] => Array
                (
                    [0] => Array
                        (
                            [actionid] => 4
                            [presetid] => 1
                            [weight] => 0
                            [action] => imagecache_deprecated_scale
                            [data] => Array
                                (
                                    [fit] => outside
                                    [width] => 50
                                    [height] =>
                                )
                        )
                )
        )
)

We need to update the handling of the presets to reflect this, of course. Also, this has implications on how actions are loaded. Since the actions are attached to the presets already, is it necessary to make another API call to get them separately in _imagecache_asset_description()?

Just a few thoughts. I plan to tinker around with this a bit, since it is absolutely necessary I have it for a site I am working on. If some

ok, I've made some progress... This patch doesn't work completely yet, but it does make an attempt to handle the new API.

Marking as 'code needs work', since neither of the two patches here are in good working order

Patch is applied against the 5.x-1.x-dev release.

In the mean time, it might help to add a note on the Asset project page explaining which version of Imagecache is currently compatible with which version of Asset. The equivalent info for Panels would be helpful too.

I think supporting old versions is a bad idea - it adds complexity for very little benefit. Drupal core takes this approach, and I think we should follow the same practice. If imagecache 2.1 is ready for production use then lets switch to that completely.

I also think that the _imagecache_asset_description* function is a red herring - if it exists at all (which is dubious!) it should be part of the imagecache module and hooks. What we have here simply hardcodes descriptions for actions that happen to be provided by the main imagecache module - it will be inaccurate when modules provide additional actions (e.g. http://drupal.org/project/imagecache_actions), and is very likely to get out of sync.

That said, here is a patch that does both of these things :)

This has been fixed on dev in http://drupal.org/cvs?commit=130534, thanks Owen!

Stumbled upon an imagecache2 integration issue while working with the TinyMCE plugin. Images placed into the wywiwyg would not show, and would not have the correct dimensions specified.

It seems that asset integration with imagecache makes assumptions about location of files under the files/imagecache/ directory. It also appears that imagecache2 changed the layout of the directory ('files/' prefix is omitted). Attached patch quick-fixes my issue with 'asset' (though potentially more issues unknown to me). There must be a better way to address this issue.

Just hit the same problem myself - here is a patch that uses the handy imagecache API functions to generate the correct file path instead, and also fixes a third instance of the incorrect file path being generated.

Thanks a lot for pointing this out Konstantin. Owen's solution is more dynamic than removing "files/" from the string so I tested it out and it works as expected. This has been committed to dev. Thanks!