No photos show on edit captions page

You have to choose another imagecache preset on the field's setting page.

Well then how do I know which Imagecache presets are OK and which are not?

This one was working before, now it is not.

I ran into this problem. You have to make your *own* imagecache preset and assign it to the preview. I don't know if the module makes that clear, but that worked for me.

It is an Imagecache preset that I made.

You should know that imagecache has problems with images which contain special characters.

#5, in that case, the transliteration (http://drupal.org/project/transliteration) module strips non-ASCII chars from uploaded files. That may help.

Yes, I know. I do use that module as well.

It doesn't seem to be an ImageCache problem because the images do show up fine on the node itself. They just don't show up on the caption editing page.

On the the node edit page, after uploading 10 images it says: "10 files uploaded in queue". However, after clicking on "Next step", on the edit captions page it says: "No images yet in queue." The images get saved correctly as they do show up on the node itself. There just seems to be something wrong with the edit captions page.

Here are my settings for the imagefield:

Storage mode: Multiple image per node
Permitted upload file extensions: jpg jpeg png gif
Maximum resolution for Images: 0
Minimum resolution for Images: 0
Image title processor: _;{;};-

Preview Image Preset: Image size: gallery
(this is a custom preset which scales and crops images to 75x75px)

Editable fields: Title (ImageField), Alt (ImageField)

List field: Enabled, Files listed by default
Description field: Disabled

Neither my imagecache settings nor the filenames contain any specials chars.

This doesn't seem to be the same issue. In the original issue the photos are actually there but are just not being displayed on that page and there is no "no images yet in queue" message.

Oh, sorry! I didn't want to hijack this issue. However, one way or another, there is something wrong with the edit captions page.

@ extect:

I think fupload didn't manage to install the mysql table which contains the tmp files for the preview page. Please have a look at your log messages.

uhhh, you are right! Sorry, I forgot to run update.php! Everything working now. Thank you!

OK, I will close this issue now.

Grandcat, I think you're forgetting that that was a 2nd issue posted in the thread of another issue. The original issue still remains.

I am now experiencing the exact same problem as the others here in this thread. What is strange is that I have definitely seen it working without any problems, but suddenly the thumbnails stopped showing up on the edit captions page.
At the moment I have no idea what is causing this. I will keep testing...

Ok, this probably sounds absolutely strange, but the following steps solved the problem for me:

1. Delete the custom filepath for your imagefield
2. Upload some images
3. Re-enter your filepath in the settings for your imagefield
4. Done. Everything is working again

extect: is this a bug? if so, mark it as such.

Can you reproduce the bug?

@momendo:
I am still not quite sure. It may also be a problem that is specific to my site or maybe even another module is causing this. I just don't know.

@grandcat:
yes and no! The problem exists for all my content types until I follow the steps in #16. As long as I haven't done that, the problem still exists for that particular content type. After following the steps in #16 it's gone and not reproducible (at least so far).

Maybe the way the (broken) preview image on the edit captions page gets inserted will give some hint to track down the problem. The html wrongfully looks like this:
<img title="test.jpg" alt="test" src="http://www.mysite.com/sites/default/files/imagecache//galleries/story/42/test.jpg"/>
The file path for the image field was set to "galleries/[type]/[nid]".

Although the file path is still the same after the following the steps in #16, the html is correct after that.

Have you installed filefield_paths?

yes

Did you upgrade to the newest version?

yes, my versions:

FileField Paths 6.x-1.2
Image FUpload 6.x-3.0-rc2
ImageCache 6.x-2.x-dev (2009-May-04)
ImageField 6.x-3.0

I just upgraded to the latest versions of FileField Paths, ImageField and FileField and same problem again. I had to follow the steps in #16 to get images showing up on the edit captions page. Does really nobody know what could be causing this strange behaviour?

It is essential and I can't fix it myself so I have to uninstall the module. :(

The current modules I'm using are:
Image FUpload 6.x-3.0-rc2
Imagefield 6.x-3.1
Fielfeild 6.x-3.1
Transliteration 6.x-2.1

I'm sorry, I don't have the time to work on it at the moment.

Unfortunately, so far I wasn't able identify what is causing this. However, #16 is a workaround I can live with. I am marking this as a bug, so perhaps somebody, who knows what to do will come back to this issue.

Not sure if this is the result of inter-connected module issues, but in troubleshooting, and reading the related modules' issues, I think this may be attributable to at least one of the following:

• "Tmp" folder permissions and settings (do you have one defined, does it actually exist, permissions correct?)
• Imagecache preset name. I had a preset called "large_thumbnail" which seemed to present a problem at the "Edit Caption" screen. The preview image is temporarily(permanently?) stored in /files/imagecache/[presetname]/[filepath-name]/[image-name], but was loading in html as "/files/imagecache//[filepath-name]/[image-name]". Note the missing preset name in the file path.I changed the preset that Imagefield was using to "thumbnail" and the problem disappeared. Once I changed the Imagecache preset name to "largethumb" and reset Imagefield to use that preset, the issue vanished and image previews appeared as intended.
• One of the tokens used in the custom filepath field. In my particular case, I'm using the User ID as part of the file path, and mine in particular has a space. I realize ImageFUpload handles spaces, but what if the ISP does something tricky with letter cases?

Hope that helps others track down and fix this bug on their sites.