Closed (fixed)
Project:
ImageCache
Version:
5.x-2.0
Component:
Code
Priority:
Critical
Category:
Bug report
Assigned:
Unassigned
Reporter:
Created:
21 Apr 2008 at 16:09 UTC
Updated:
3 Jun 2008 at 20:41 UTC
Jump to comment: Most recent, Most recent file
Comments
Comment #1
brunodbo"(...) I'm using the default CCK 'Display fields' settings (...) "
I meant: I'm using the CCK 'Display fields' settings. Not the default ones: I did select an ImageCache preset.
Comment #2
rootworkI'm having exactly the same problem -- after upgrading, all of my cached images refuse to appear, even after taking the steps mentioned above. I even tried deleting the images on a node and re-adding them, but that doesn't fix it.
I have one piece of information that may help address this issue: When I use the devel module to look at the variables that are rendered, in the image field's view attribute I see the following note:
What's odd is that the imagecache formatter I have is named "candidate_images," and that's how it's set to display on the node (where it's not appearing) and in a view (where it's not appearing). So I'm wondering if somehow the underscore is throwing off imagecache.
It could be something else, but I thought I'd give as much info as I have about the issue.
Comment #3
rootworkYep, that was it. I tried renaming the presets by removing the underscores; when I returned to the node it was trying to render the image but not finding the original file. Deleting and re-adding the file fixed it, and now it's rendering them.
So there must be some bug in dealing with underscores, and since I don't want to rename all of my presets, update all of my templates and delete and re-add all of my images, I think I'm going to bump back down to the beta until rc2 addresses this.
And sorry I'm not a good enough programmer to be able to submit a patch.
Comment #4
brunodboConfirming that images are rendered and displayed correctly when underscores are removed from presets' names. Hyphens work fine, btw.
Comment #5
brunodboSteps I needed to do to get my images rendered again:
- change preset name (remove underscore)
- for views: re-selecting the desired preset under the view's fields' options (after renaming the preset, it jumped to the first preset available) & re-save the view
- for cck content types: re-selecting the desired preset on the 'display fields' page & re-save the content type's 'display fields' settings
Comment #6
dopry commentedDid you try clearing your cache?
SQL: DELETE from cache, or TRUNCATE cache
Devel module: Empty Cache
Sometimes old preset settings get stored there...
I use presets with underscores pretty regularly.
Can you go back to the previous state and test again with just clearing drupal's cache.
Comment #7
brunodboYep, I tried fixing the problem by clearing Drupal's cache. That didn't help however.
Comment #8
jonhattandopry: It's not a caching issue. replacing the rc2 folder with -beta folder does fix the problem immediately.
I have take a look to the code and seen a problem at line 555 :) :
this is not compatible with having presets with underscodes. I've replaced it with the following code and I got a step further, but seems to not work still:
Comment #9
dopry commentedjonhattan,
thats the exact bug I found yesterday..
http://cvs.drupal.org/viewvc.py/drupal/contributions/modules/imagecache/...
It shoudl already be fixed in HEAD... give it a try... the dev release should have the fixes.
Comment #10
dopry commentedoh yeah.. fixed.
Comment #11
DerTobi75 commentedHi,
I am still experiencing this issue with RC2 ;(
Tobi
Comment #12
DerTobi75 commentedDropy,
it seems like, that now presets without underscore are not rendered!
Tobi
Comment #13
tancI'm having the same problems with rc2. Have emptied cache etc. I've removed the underscores which helped a little but the issue now is that the imagecache images will only display if the content type's display fields are set to 'mypreset as link to node'. Selecting just 'mypreset' causes no image to be shown.
Downgrading the module to 2 beta allowed the standard 'mypreset' to work but no 'mypreset as link to node', almost the opposite effect...
Comment #14
DerTobi75 commentedHi,
what if you rename your preset to: my_preset? This should work.
Regards,
Tobi
Comment #15
almich commentedHi,
I updated to rc2 and I can't see the images, either. Instead in the source code there can be found the comment <!-- imagecache formatter preset() not found! -->. So I looked closer to the module code, the problem still seems to be line 556ff:
In my case $formatter is a string without underscore. $parts becomes an array with just one element, $style is then a string again, identical to $formatter. And in the end $presetname seems to be an empty String, which obviously leads to an error message.
Regards, almich
Comment #16
soxofaan commentedmarked http://drupal.org/node/254368 as a duplicate of this issue
I attached my patch from that issue here.
It just makes sure all formatters have the same structure "$presetname_$style", so that the explode-pop-implode trick works for all cases
(@brunodbo: hi bruno)
Comment #17
TC44 commentedsame problem here. I'll try the patch later today.
Comment #18
brunodboConfirming that 254368_formatter_names_01.patch by soxofaan works. Images are rendered correctly, with or without underscores in preset names.
@soxofaan: Thanks!
Comment #19
dopry commentedoh sorry I fixed that in HEAD and never backported to DRUPAL-5--2... Back ported now.. should show up in dev release tomorrow. I may roll another RC later today.
Comment #20
a_c_m commentedPlease do roll a new RC, downloaded RC2 today and ran into this problem.
Comment #21
sun+1 for RC3.
Comment #22
Anonymous (not verified) commentedTo get this bug to clear up on the 2.0 release, you have to poke at your CCK field formatters by flipping them to another option and flipping them back.... at least that was my experience.
Comment #23
miklI have been trying to find the where the selected formatter (CCK display fields settings) is stored in the database, but so far I've not been able to.
Does anyone know?
Comment #24
Anonymous (not verified) commentedThey're stored in a serialized variable in the node_field_instance table, so you're better off working with them in PHP.
Comment #25
Anonymous (not verified) commentedAutomatically closed -- issue fixed for two weeks with no activity.