Drupal 6 port for ImageCache

I'm having problems getting this to work. The files aren't being created and I'm not quite sure where the problem is. It's a new host and a new 6.x install so it might be something as stupid as file permissions or a screwy .htaccess. While trying to debug it I came across one other thing.

Looking at the preset settings (e.g. admin/build/imagecache/preset/1) I'm noticing that the 'Settings' column is empty. imagecache_ui_preset_form() is setting:

    $action_form['settings'] = array(
      '#theme' => $action['action'],
      '#value' => $action['data'],
    );

which leads me to think that the theme function isn't being registered correctly. Looks like we need to add:
theme_imagecache_resize and the contents of imagecache_actions.inc to image_cache_theme().

Once I figure out my issue I'll look at updating this patch.

when i enable private files imagecache works, with public files imagecache_cache() never gets called. i can't say that it's not a problem with my server and mod_rewrite though.

the attached patch add the theme functions to imagecache_theme().

eaton, probably right about not needing the full theme functionality... a call back sounds like the right approach. if there's a usecase for changing the callback we can just send the actions through a call to drupal_alter() so other modules can hack on them.

Can anybody provide the complete files? i've build the new files with the patches, but the module doesn't work :-(

freakx0, what didn't work? also, did you try private file transfers?

just wanted to note that turned on public file transfers to test it out again and it was working.

it turns out that it's not working quite right, the images are only created when private file transfers are enabled but will be served correctly in either mode.

fixed the menu access to be compatible with D6.2.

forgot to fix the access in imagecache_ui.module...

now that quicksketch has a patch for imagefield i started working on getting the field formatters updated. the as link to the node doesn't work yet because i can figure out where to find the node id.

default formatter wasn't working...

Which version should I check out and apply the patch to? I will try to test this imagecache6 with the imagefield patch6_5.

Was the private/public file transfer issue solved?

can someone please provide patched file for drupal 6.2? this patches get quite messy - complete download would be extremely helpful for non full time developers ;)

Thanks for this one guys it's working a treat for me with imagefield at the moment.

To anyone reading please note that the current HEAD copy of the module has been updated since this patch was started which causes some nasty breakages if you try to apply the patches to them. I am reluctant to attach a full fileset for the module as it will likely be out of date almost as soon as it is attached.

Instead here's how you get it to work:

cvs -d ":pserver:anonymous:anonymous@cvs.drupal.org:/cvs/drupal-contrib" checkout -D "March 11, 2008" -r HEAD -d imagecache contributions/modules/imagecache

cd imagecache

[download the latest patch file into the image cache folder]

patch < [patch filename here]

rejoice in the imagecache goodness

just a note... I won't be supporting merged code sources from unofficial releases.. I really suggest you only use the 6.x port if you're really comfortable with the code... I'm still working on 5.x-2.x in HEAD and it will be a moving target until I'm done.

well, it seems like March 11th, 2008 rep is empty. i've used latest one but patching gave me quite few errors :/

no joy with patching
take it that from the above post the version patched against is no longer available from the cvs?
any change of putting up already patched version
or if not the module version itself that needs to be patched
thanks

I would also like to test this port.

totally untested re-roll...

Thanks drewish, the patch worked perfectly.

When I visit admin/build/imagecache, none of the links (edit, remove, flush) seem to do anything other than changing the URL to admin/build/imagecache/preset/1.

psynaptic, thanks for the testing looks like i'd accidentally removed one of the menu wildcard loader functions thinking it was unused. moved it from imagecache.module to imagecache_ui.module and updated the name accordingly.

please keep banging away at it.

[don't mind me, just subscribing]

lol, drewish your patch is already out of date. 8 hours ago cvs got updated. please provide full patched module. original sources change so fast that we won't be able to patch them anyway :(

I'd say just an updated patch would be good.

here's a re-roll... i won't post full versions of the module. patches are pretty simple to apply and if you're not comfortable enough to get the patch applied you probably shouldn't be messing with beta code. because you can always get old versions out of cvs.

thanks.
it's not that i'm uncomfortable with patching. it's not a problem. the real issue was that every time i've came to this thread your patches turned out to be already outdated :)
anyway thanks for re-roll this time i've made it on time ;)

i hope we'll get new 6.x branch soon because this module is almost a must-have for every site.

patch goes ok
but get blank screen on the next page after enabling imagecache module
would I be right in thinking its something to do with permission issues?

mikehh, well assuming you installed imageapi and applied the D6 patch, pull php's error log and provide some detail. what was the error message?

fixed a problem with the requirements checking. on a clean i'd tried enabling imagecache_ui and imageapi_imagemagick thinking it would detect the dependency and enable the required modules... didn't quite work. i got a fatal error because imagecache_requirements() was calling imageapi_get_available_toolkits() which wasn't defined. i tried changing it so that if the function was not defined i returned a requirements error which worked better but caused a new problem: trying to enable the same two modules sort of worked, imagecache_ui was enabled but listed with a missing dependency and imagecache was disable but the checkbox to enable it was disabled. the simplest fix was to just make the toolkit a runtime requirement just like the imagecache_directory checks.

which version of imagecache should this patch be applied to? I have gotten errors on the versions i have tried applying it to.

Subscribing.

New Patch:
- Updated to HEAD
- Modified hook_theme() and imagecache_field_formatter() so that Imagecache now works with Views in 6.2 - needs further testing.

Possible bugs:
- Cache may need to be flushed each time a new Imagecache preset is added/renamed for Views support.

Updated Patch:
- Updated two l()'s from 5.x style to 6.x style

Updated patch:
- Runs drupal_rebuild_theme_registry() after new Preset is defined.

subscribing to know what's going on

Untested patch against latest version of 5.x dev (may 20)

I tried this, patch applied successfully but it still shows up as "incompatible" with my Drupal 6.2 installation.

I've actually been trying all day to get some version of ImageCache working on Drupal 6.

If anyone can help that would be awesome!

What version are you patching against? You have to patch this against HEAD.

Right, that's what I was trying:

http://cvs.drupal.org/viewvc.py/drupal/contributions/modules/imagecache/

And I have tried these patches:

http://drupal.org/files/issues/imagecache-6.0-232624-3.patch
http://drupal.org/files/issues/imagecache_232624_7.patch
http://drupal.org/files/issues/imagecache_6_0.patch

None of them complete cleanly. Which one SHOULD I be using at this point?

@Vigile,

Download every file from: http://cvs.drupal.org/viewvc.py/drupal/contributions/modules/imagecache/...
Use the patch I posted at #39

I just did this myself and it patched perfectly. I can also confirm that it works enough to play with on a development site.

Edit: To make things a bit easier for you I have attached a working version that I just patched from HEAD seconds ago, hope this helps with testing.

@Steve Dondley

I looked at your patch briefly can confirm that it will not work as it is missing some crucial information in the .info file.
Is there anything in your patch that mine does not have?

@Deciphered

Right, my patch only covers the .module file. An oversight on my part.

My patch was created with your patch from #39. Your patch did not apply cleanly because HEAD had moved. So I patched in the failed hunks manually. If I recall, one of the hunks was just thrown away because it wasn't needed any longer.

@Deciphered - That got it working - many thanks! I'll play around and see how it goes!

just to keep everyone on the same page, here's a re-roll of Deciphered's last patch. it seems to be working pretty well for me.

subscribing

Applied and tested #48 and it seems to work pretty well.

Sounds like we might be inching towards RTBC?

dopry, I see that a stable release of 5.x-2.x is out now. Does that mean the majority of your changes are complete, or are you still doing some refactoring there?

subscribing to this valuable effort

...

Hm. This patch doesn't apply against 5.x-2.x, and it looks like that's where active development is going on (last commit in 5-x-2.x was 8 days ago vs. 2 weeks ago in HEAD).

patching file imagecache.info
patching file imagecache.install
Reversed (or previously applied) patch detected!  Assume -R? [n] n
Apply anyway? [n] n
Skipping patch.
3 out of 3 hunks ignored -- saving rejects to file imagecache.install.rej
patching file imagecache.module
Hunk #1 FAILED at 1.
Hunk #12 FAILED at 507.
Hunk #13 FAILED at 537.
Hunk #14 succeeded at 531 (offset -28 lines).
Hunk #15 succeeded at 546 (offset -28 lines).
Hunk #16 succeeded at 572 (offset -28 lines).
Hunk #17 succeeded at 598 with fuzz 1 (offset -28 lines).
Hunk #18 succeeded at 624 (offset -30 lines).
Hunk #19 succeeded at 732 (offset -40 lines).
Hunk #20 succeeded at 747 (offset -40 lines).
Hunk #21 succeeded at 759 (offset -40 lines).
Hunk #22 succeeded at 769 (offset -40 lines).
Hunk #23 FAILED at 791.
Hunk #24 succeeded at 802 (offset -42 lines).
Hunk #25 succeeded at 826 (offset -42 lines).
Hunk #26 succeeded at 834 (offset -42 lines).
Hunk #27 succeeded at 844 (offset -42 lines).
Hunk #28 succeeded at 863 (offset -42 lines).
Hunk #29 succeeded at 871 (offset -42 lines).
Hunk #30 succeeded at 885 (offset -42 lines).
Hunk #31 succeeded at 917 (offset -42 lines).
Hunk #32 succeeded at 963 (offset -42 lines).
4 out of 32 hunks FAILED -- saving rejects to file imagecache.module.rej
patching file imagecache_actions.inc
patching file imagecache_ui.info
patching file imagecache_ui.module

@webchick, try my patch at #41 (does not patch install/info files though).

Here is a working patch against 5--2.

subscribing...

followup #56 committed to HEAD... I'll be doing some follow up fixes... Create new issues for head if it's broken now, but give me a day to work some kinks out.

sub

sub

Subscribing

seriously... why are you people subscribing to a closed issue when there's a D6 release available for testing?

I guess for 2 reasons:

1. they are not aware of it
2. they want latest news - that version is in head, not even dev yet

Anyway, you're right - there should be another issue about latest development and link to it posted here.

I'm subscribing because in the web 2.0 world I've become quite accustomed to having information I want come to me rather than continually searching until the answer becomes available and this seem to be the most likely place for that answer to show up. If someone creates another issue to track the release of an RC or whatever I'm sure you'd see a mass sub on that issue as soon as it is posted here. Basically, yeah, encho is right on #2.

There is also probably a bit of fatigue in all the testing of all the different module going through D6 release. Seems like everyone needs testing to get the bugs out and I only have so much time. Just keeping track of the ones I want to watch is keeping me on my toes.

seriously... why are you people subscribing to a closed issue when there's a D6 release available for testing?

This link above is to a head version from 2006.

Is there to be a full 6.0 release of this?

#66 Head tar regenerates every 12 hours so even though head was created in 2006 it has the most current testing version. It the case of my posting it would be.

Last updated: June 24, 2008 - 19:04

Thanks
Robert

flickerfly, the thing is the issue is marked closed that means that there won't be any further activity on here. any further bug fixes will happen in separate issues. so at this point subscribing is just creating noise for everyone else.

i got dopry to create a release for 6.x: http://drupal.org/node/275934 so please stop posting on this issue it's closed for a reason.

@drewish: I understand it's closed; however, it was closed automatically and issues do get re-opened sometimes. The thing is, from my perspective the system is broken and this is the best possible solution which seems to work fine for a number of other contrib modules. If something happens, I want to know. If people subscribing to these things bother you, then please work on one of the issues related to handling notifications in a better way so that it doesn't spam everyone just for a 'sub' message. http://drupal.org/node/34496 I think that would be a great benefit to the community. I note your other contributions including contrib modules. Thank you for that, seriously.

Putting the link to the release on the project page still means I have to come looking at this and a bunch of other module pages in a regular rotation each time I want to find out if I can build a D6 site and promote it to production using this module. That's messed up and wasting community resources looking for things. I'm no coder, but I'd be much happier spending the time trying to figure out how things work and writing documentation than making the rounds yet again.

If there is a better way to get the information I need to come to me, please let me know. I don't like this method either. I've looked and I just can't find anything better.