Image upload lists file name, but doesn't store image

I can verify that this problem exists for me too. Files folder is drwxrwxr-x. Temp directory path is changed to a local folder with full read write permissions. Uploading a picture shows a thumbnail in the imagefield form, however no file is stored in the system. All images are jpg within size limits.

Occurs in both imagefield 1.1 and 1.x-dev. It was working normally prior to this in version 1.0.

It occur for me too.
I think this maybe a conflict between cck1.4 and imagefield because they say that it work with cck1.3 (No prove at all, It just my theory)
however, there is an alternative solution that I use.
1. upload image at imagefield, it will show thumbnail point to path where image should be.
2. upload image manually at that path. (ftp or any way you want)
3. submit node.
it worked, but didn't so convinient.

P.$. Sorry about my BADDDD english, Got C at my english class.

I just did a test website and can confirm that it is the changes within CCK 1.4 which is breaking imagefield. Could it be the way in which the content array is rendered?

CCK 1.3 with Imagefield 1.x-dev = Working with bugs
CCK 1.3 with Imagefield 1.1 = Working
CCK 1.4 with Imagefield 1.x-dev = Not working
CCK 1.4 with Imagefield 1.1 = Not working

I'm having the same problem, only I don't get a thumbnail -- just a blank box where a thumbnail should be. When I preview the node, the filename disappears as if I never uploaded anything in the first place.

I am having the same problem

My company is attaching a bounty for a patch to this bug: $100 if fixed by 2007-04-18. We'll pay by check or PayPal.

When I upload a large image that is resized, I get weird thumbnail display: only half of the thumb seems loaded, it takes long time for the rest to load if it loads at all.

When this happen and I click on the submit node button: the browser asks if I want to DOWNLOAD a file !!

When I click no, then submit again, it creates the node twice.

I think there is something really wrong here with the add/ edit page and the way it loads the thumbnail.

Just for interest. have you see and tried this => http://drupal.org/node/109183

Because I am still having the same problem.

@spjsche: Thanks for the link. We're running in public mode, however, so it shouldn't be an issue.

Go to Administer/Site Building/Themes and check 'Use the default shortcut icon'. Withouth setting valid favicon, browser makes some extra GET requests, which disturb process of creating Imagefield widget. Inside function 'imagefield_widget' there is condition: if (!count($_POST)) {imagefield_clear_session();} and I have noticed, that withouth valid favicon.ico this expression is true.

Thanks kndr for an area to look into. I'm investigating now. Any potential patchers please have a look also. I'll review and commit any patches to fix this issue.

I still can't reproduce this. Here's what I went through (after failing to reproduce normally with the versions specified):

- Fresh Drupal 5.1 install
- Install and enable CCK 1.3 and Imagefield 1.1
- Added image field 'test image' to 'story' type with the default settings for an image field
- Submit a story node with a test image *works*

- Upgrade CCK to 1.4
- Run update.php
- Submit a story node with another test image *works*

- Disabled default favicon in admin/build/themes/settings
- Submit a story node with another test image *works*

There is clearly a problem somewhere, but without a way to reproduce we won't be able to fix it.

Please, try it with Firefox 2.0.0.3.

I have:
Drupal 5.1
CCK 1.5
Imegefield 5.x-1.x-dev (7.03.2007)

IE doesn't cause problems. I've forgot about this browser ;)

All my testing was on Firefox 2.0.0.3. I didn't think the browser would be an issue either. Could you outline some steps to reproduce starting with a fresh Drupal install?

I have this problem too, but under IIS 6.0. I thought it was related to the ISAPI rewrite rules, but it seems this problem is more widespread that I thought...

I can reproduce the problem! Great news :D

I finally got it to begin screwing up by enabling 'multiple' on the image field and unchecking the favicon. I think once my browser had cached the favicon, it wasn't generating the requests to the server any more. Super kudos to kndr for finding that one!

Hi All, attached is a patch which should fix the problem.

This simply ensures that you are on a node edit or add page when imagecache cleans out the $_SESSION variable. Previously, this may have been a safe assumption, but recent changes in CCK call this code in places that aren't the node form. In addition the request for a favicon seems to call the current page multiple times with no POST array when trying to request the favicon image. Not entirely sure why that is, but it explains why the problem can occur in some browsers and not others.

This patch also includes the patch in http://drupal.org/node/137313, as I had some odd experiences without it. Please test and confirm it corrects the problem.

Great news quicksketch! Thanx. I will check this. BTW, I've noticed that I have also problems to reproduce this bug on different stations! I use Firefox 2.0.0.3 on three workstations and only with one of them I have this strange behavoiur! It happens when I create nodes with imagefield on localhost (WAMP) environment but also on remote host (LAMP) production version. Curious. Count of extra GET requests dependent from visibility of tabs - one favicon is needed for address bar and one for tab. Maybe it is the source of problems with other modules i.e. upload. It seems like random behaviour but it depends on some mysterious settings inside Firefox.

Once more... I discover method to reproduce this bug on other workstations with Firefox 2.0.0.3. Go to about:config and set network.http.use-cache to false. After that, uncheck 'Use the default shortcut icon' on administer theme page. Go to Create Content and try to upload image with imagefield. If you can see preview than do it once more time. You will see, that no preview is shown.

Hi,
i'm still noticing a weird behavior (using 19 april dev version of this module, latest CCK, Views, imagecache, contemplate and Firefox 1.5.09).

When I upload a large image that needs to be width scalled, on a content type with multiple CCK image fields, it will sometimes load the thumbnail in real time (starts immediately displaying the thumbnail after clicking on "upload" and load it progressively): when this happens, there is a problem usually: it won't load it completely, and sometime it will even fail.

When it works correctly, I noticed it will display nothing until the thumbnail is fully loaded in the system: in this case it will display it instantly and correctly after the load process.

I noticed (but it might just be a coincidence) that I seems to have this symptom when I set image toolkit quality to 98% instead of default 75%.

I think that the thumbnail preview process should be reviewed since it seems to cause problem: there should be a kind of ajax display during the ENTIRE load process of an image with a "Please wait while your image is uploaded". Once the image is fully loaded, it will be displayed as a thumbnail. Another benefit is that it will be less confusing for the user and avoid multiple clicks on "Upload" button.

Cordially,
Brakkar

Looks like this still doesn't correct the favicon problem. We're going to have to do some kind of check to see if a favicon is supplied and provide a default (or blank) favicon to prevent browsers from making these requests. To help debug the issue I'm using the following code:

  if (empty($_POST)) {
    watchdog('imagefield', 'Reseting session: <pre>'. print_r($_SERVER, true) .'</pre>');
    imagefield_clear_session();
  }

Using drupal_set_message doesn't seem to work. When I don't have a favicon and I upload an image, I get at least one request with the following message in watchdog:

Reseting session:

Array
(
    [REDIRECT_STATUS] => 200
    [HTTP_HOST] => drupal5
    [HTTP_USER_AGENT] => Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.3) Gecko/20070309 Firefox/2.0.0.3
    [HTTP_ACCEPT] => image/png,*/*;q=0.5
    [HTTP_ACCEPT_LANGUAGE] => en-us,en;q=0.5
    [HTTP_ACCEPT_ENCODING] => gzip,deflate
    [HTTP_ACCEPT_CHARSET] => ISO-8859-1,utf-8;q=0.7,*;q=0.7
    [HTTP_KEEP_ALIVE] => 300
    [HTTP_CONNECTION] => keep-alive
    [HTTP_COOKIE] => PHPSESSID=a7a6b43026abc128debaa3ec6ea7102c
    [PATH] => /usr/bin:/bin:/usr/sbin:/sbin
    [SERVER_SIGNATURE] => 
Apache/2.0.59 (Unix) PHP/5.1.6 DAV/2 Server at drupal5 Port 80


    [SERVER_SOFTWARE] => Apache/2.0.59 (Unix) PHP/5.1.6 DAV/2
    [SERVER_NAME] => drupal5
    [SERVER_ADDR] => 127.0.0.1
    [SERVER_PORT] => 80
    [REMOTE_ADDR] => 127.0.0.1
    [DOCUMENT_ROOT] => /Users/nate/Sites/drupal5
    [SERVER_ADMIN] => you@example.com
    [SCRIPT_FILENAME] => /Users/nate/Sites/drupal5/index.php
    [REMOTE_PORT] => 56261
    [REDIRECT_QUERY_STRING] => q=node/55/edit
    [REDIRECT_URL] => /node/55/edit
    [GATEWAY_INTERFACE] => CGI/1.1
    [SERVER_PROTOCOL] => HTTP/1.1
    [REQUEST_METHOD] => GET
    [QUERY_STRING] => q=node/55/edit
    [REQUEST_URI] => /node/55/edit
    [SCRIPT_NAME] => /index.php
    [PHP_SELF] => /index.php
    [REQUEST_TIME] => 1176967511
    [argv] => Array
        (
            [0] => q=node/55/edit
        )

    [argc] => 1
)

The number of times I get the message per upload seems to be the number of tabs I currently have open kndr reports. This makes for a very frustrating problem, because Firefox doesn't make the request at the address for the favicon: tt makes a duplicate request (or requests) for the current page (with no POST).

The favicon problem is corrected by http://drupal.org/node/137724.

marking as duplicate.

just wanted to confirm that this patch worked for me.

I don't think this a duplicate... the Firefox favicon bug is annoying, but separate afaics.

So I found another site that has this problem if you're curious, Nate. ;) I have both this patch and the favicon patch applied, but neither seems to cut the mustard. They're having exactly the same problem as reported by the original poster.

This was an upgrade to Drupal 5 from Drupal 4.7.3. I've overwritten the files/.htaccess file with the one from 5 to get around the Options None behaviour.

Anything else I can check?

Btw, using imagefield-5.x-dev (// $Id: imagefield.module,v 1.30.2.17 2007/04/21 21:41:15 quicksketch Exp $) and CCK 5.x-1.4.

I have fixed similar issue by adding "LoadModule rewrite_module modules/mod_rewrite.so" to my apache hhtp.conf. Guess this could be an issue for someone not seeing image thumbnail after uploading a file.

Nah, clean URLs are working. The reason it's not seeing the image on preview is because it's not actually there. :P Something is killing it when it's trying to upload.

I've heard from several people that the problem still exists (or is not related to the favicon). Unfortunately, no one has yet been able to reproduce this problem from scratch. If having this problem, the most beneficial thing anyone can do is install a fresh Drupal and try to reproduce it, detailing all the steps necessary. Somewhere through all the upgrades, contrib modules and patches, this module breaks. If anyone can detail steps to get the same problem, I'll setup a mirror environment (short of installing IIS).

What about file system settings? Check 'Temporary directory' in 'File system'. It should be the absolute path like 'C:\Program Files\xampp\tmp' and not like 'files/temp'. I had problems with it in the past.

quicksketch -- it's the devsite for my organization that webchick was looking at. In terms of codebase, it's a clean 5.0 install -- we set it up in a fresh directory, and moved over the custom sites/xxx/themes folders only after getting all the newly downloaded contrib modules up and running.

At the database level, though (as webchick mentioned) it is an upgrade from 4.7.3. And for what it's worth...
-- In the nodetypes that use imagefields, there are two of them: field_image and field_thumbnail_image
-- Images loaded into nodes *before* the upgrade still display fine, but you can't add/replace images in those nodes either
-- I've attached a copy of the update.php warnings & log messages from when we enabled the various CCK modules. This was the first thing we did after running update.php for the core 5.0 install.
-- This is a multi-site install.

I will try to get a brand-new, single-site test install set up today, and see if I can pinpoint where this breaks. But here's all the contrib module info for the site as it stands, just in case anything jumps out at you as a likely suspect. There are a lot of them, as our live site (www.newamerica.net) makes heavy use of CCK and views both:

• Core Install is 5.0. These optional core modules are enabled: Comment, Contact, Help, Menu, Path, Search, Taxonomy & Upload
• CCK Modules are 5.x-1.4. Content, Date, Image, Node Reference, Number, Option Widgets & Text are enabled
  Imagefield is now 5.x-1.x-dev, but we started with 5.x-1.1 (// $Id: imagefield.module,v 1.30.2.7 2007/02/23 05:01:29 dopry Exp $). The image problem has persisted throughout.
• Developer Module is 5.x-1.x-dev. Only the main devel module is enabled.
• Views Modules are 5.x-1.6-beta4. Views, Views RSS, Views Theme Wizard and Views UI are all enabled. Some views pull in the field_image_thumbnail, by the way, and these work fine with older data that already had images.
• Event Modules are 5.x-1.x-dev. Event and Event Views are enabled.
• JS Tools Modules are 5.x-0.6. JS Calendar and Tabs are enabled, but the main Javascript Tools is not.
• Location Modules are 5.x-1.x-dev. Both Location and Location Views are enabled.
• The "Other" Modules
• Actions (5.x-1.x.dev)
• Content Templates (5.x-1.1)
• Date API (5.x-1.4)
• Forward (5.x-1.x-dev)
• Nice Menus (5.x-1.x-dev)
• Path Ridirect (5.x-1.-dev)
• Pathauto (5.x-1.1)
• Revision Moderation (5.x-1.0)
• Signup (5.x-1.0)
• TinyMCE (5.x-1.x-dev)
• Webform (5.x-1.2)
• Workflow (5.x-1.0)
• There's also a custom "NAF" module, with various functions we've needed. But none of those deal with file-uploads or with CCK fields of any sort.

I'll post back with anything I find while testing. But if anyone has any suggestions, please let me know.

Thanks!

OK, I haven't yet done the clean-site testing, but I did discover a couple details that may help identify the problem:

1. Plain old file attachments are not working correctly either. (Both Drupal and folder permissions are set to allow them.) When you hit the attach button, the "Uploading File" message and "diagonal lines" image bar just grind away forever, even when attaching a tiny file. The status message in Firefox's bottom bar quickly goes to "Done," however, and it you just hit submit, the file attaches to the node. In fact, it attaches twice -- see the excerpt from the Dev Load tab of this test node:

Array
(
    [1657] => stdClass Object
        (
            [fid] => 1657
            [nid] => 5171
            [filename] => mail-forward.png
            [filepath] => files/mail-forward.png
            [filemime] => image/png
            [filesize] => 893
            [vid] => 6930
            [description] => mail-forward.png
            [list] => 0
        )

    [1658] => stdClass Object
        (
            [fid] => 1658
            [nid] => 5171
            [filename] => mail-forward.png
            [filepath] => files/mail-forward_0.png
            [filemime] => image/png
            [filesize] => 893
            [vid] => 6930
            [description] => mail-forward.png
            [list] => 1
        )

2. With an imagefield, if you browse to select an image (or manually enter a valid path into the field), but DON'T hit the imagefield's upload button and instead just submit the node, the image actually loads and displays properly:

field_image

Array
(
    [0] => Array
        (
            [fid] => 1656
            [title] => maria_mid_december.jpg
            [alt] => maria_mid_december.jpg
            [nid] => 5171
            [filename] => maria_mid_december.jpg
            [filepath] => files/maria_mid_december.jpg
            [filemime] => image/jpeg
            [filesize] => 26820
        )

)

All this is done in Firefox 2.0.0.3, on a site using the gazillion modules I listed in the comment above. (Testing in IE produces different, but equally flaky, results.) But it seems as though the problem is with the pre-submission upload part of the process.

Now I'm off to create a super-simple 5.0 test site, and see if I can replicate this there...

The good news: I was able to replicate the larger file-upload problem I mentioned in Comment 33 on a clean Drupal 5 install today. And even better, I know the cause (see http://drupal.org/node/131320). Turn off devel, and file attachments work just fine.

The bad news: Turning off the Developer Module doesn't do anything for the imagefield module. TinyMCE and its imagemanager don't seem to have any effect either (I thought if any module had javascript that might conflict, it'd be TinyMCE...), and I still can get this problem to replicate on the clean-and-simple install.

I haven't recreated our problem site in its entirety -- I don't think that's possible, given its upgraded-from-4.7 database -- but I did nose around via the command line while trying the exact same thing on both sites. By creating a new Article (one of our CCK node-types), and trying to add a small icon into the "field_image" imagefield, I was at least able to identify where the process seems to choke:

On the Clean, 5.0-from-scratch test site I created today:
Upload the image (8-ball_32.gif), and it previews just fine. The edit screen for the node shows a filename of 8-ball_32.gif, and right-clicking on the image shows a location of http://sitename.com/drupal-5.0/files/8-ball_32.gif

In the site's /tmp directory, the following file pops up:
-rw-r--r-- 1 tschneider tschneider 601 Apr 30 20:43 tmp_A5hnDu
...while there is not yet an "8-ball_32.gif" file in /files

I'm assuming the imagefield.module works like upload.module does, in that it creates an alias/symlink/whatever so that final filepath points to the /tmp file until the node is actually submitted.

Once you submit the node, the /tmp/tmp_A5hnDu file disappears, and the following pops up in the /files directory:
-rw-rw-r-- 1 tschneider tschneider 601 Apr 30 20:48 8-ball_32.gif

On the actual, upgraded-from-4.7-and giving us problems site:
It's as though the process chokes as soon as the file has been uploaded into the /tmp directory. Using the same 8-ball_32.gif, I get this in the /tmp directory after hitting the imagefield's upload button:
-rw-r--r-- 1 nobody nobody 601 Apr 30 14:02 tmp_7beCvJ

... but the image doesn't preview in the node (you just see the filename listed), and the path I can get by right clicking on the broken image doesn't work either -- the alias/symlink/whatever for the /files directory has not been created.

Then when you submit the node, all traces of the image disappear -- if I go back into edit mode, even the broken image and filename are gone. The image never gets copied over to /files, and the tmp_7beCvJ copy remains in the /tmp directory. (In fact, I can't even delete it by hand -- I get a message of "rm: cannot remove `tmp_7beCvJ': Permission denied")

---

Any ideas? Both the permissions and the ownership of the tmp file differ from site to site, but I have no idea where that's being set. And I've made sure the directories themselves are fully accessible, but this sure seems like a weird permissions issue.

Thanks again for any help or suggestions,
TKS

Thanks TKS for the very thorough report.

I've submitted these two patches to correct the devel module interfering with imagefield:
Devel: http://drupal.org/node/140417
Core file.inc: http://drupal.org/node/140412

It sounds like other than the previews not working (the above patches fix that problem), we still haven't reproduced the critical "disappearing" images problem. Some suggestions:

- Try loading the troublesome site's database onto you development site. If the problem doesn't reoccur, then we know the problem isn't caused by solely by the site configuration.
- If the problem isn't caused by loading the bad site's database, begin transferring modules from the site to your dev box. The modules will automatically be enabled as you add them because of Drupal's "memory" of it's installed modules (just refresh the /admin/build/modules page). Try reproducing the problem every 5 modules or so.
- If the problem isn't reproduced after moving over all modules and database (basically a site move), then that will leave server configuration. Thanks again for your help.

IT IS A GOOD DAY :)

Working with TKS tonight I think I've nailed down the primary cause of disappearing images. As I've suspected, the $_SESSION variable is getting reset at some point. I haven't been able to resolve why the session is being cleared, but it seems to be happening outside of imagefield. I have found a workaround however, and since it's a good practice anyway I'd suggest anyone having this problem immediately try the following solution.

Here is the scenario:
- In all cases I've seen so far, location.module is causing a 404 request on every page load looking for location.css.
- This 404 error (or others, a likely scenario) is handled by Drupal, which is the default behavior.
- Somewhere in this request, the session is cleared. This includes the list of all current uploads. While I would think that the patch in comment #18 would correct imagefield clearing the cache unexpectedly, it does not seem to fix it. It is being cleared outside of imagefield.
- This problem is intermittent between users, browsers, and platforms because some browsers cache the 404 error on this request. Preventing them from making it a second time. Since some browsers know the missing file doesn't exist, they don't bother requesting a second time, leaving the session intact.
- If the session is cleared, imagefield losses all information about the upload. A preview is not displayed and the image is never moved from the tmp folder to it's final location.

Here is the solution:
- Don't have Drupal handle 404 errors :) This is an active topic of discussion: http://drupal.org/node/76824 Having Drupal handle 404 errors is a serious performance drain when migrating a site or dealing with a lot of 404 errors (like a module incorrectly including a css file).
- In the case I observed, the patch current patch in the mentioned discussion did not function properly on the test installation of apache. Instead I recommend the following work around:

In .htaccess Change

  # Rewrite current-style URLs of the form 'index.php?q=x'.
  RewriteCond %{REQUEST_FILENAME} !-f
  RewriteCond %{REQUEST_FILENAME} !-d
  RewriteRule ^(.*)$ index.php?q=$1 [L,QSA]

To

  # Rewrite current-style URLs of the form 'index.php?q=x'.
  RewriteCond %{REQUEST_URI} !\.(png|gif|shtml|jpe?g|css|js|cgi|ico|swf|flv|asp|aspx|asx|jsp|cfm)$ [OR]
  RewriteCond %{REQUEST_URI} ^\/sites\/[^/]+\/files\/ [OR]
  RewriteCond %{REQUEST_URI} ^\/files\/
  RewriteCond %{REQUEST_FILENAME} !-f
  RewriteCond %{REQUEST_FILENAME} !-d
  RewriteRule ^(.*)$ index.php?q=$1 [L,QSA]

This prevents Drupal from handling 404 errors on any file in the files directory or ending in the above extensions. It immediately fixed the problem on the cases I was able to test. I'm leaving this issue open while I try to find what's causing the session to be cleared. We should be able to fix this somewhere, as the patch in #76824 will probably only be applied to the 6.x branch.

Just experienced this problem with a looming deadline - Thanks quicksketch and TKS!

I had a local test site running on mac osx

mysql 4.0
php 5.0.1
imagecache 5.x-1.2
imagefield 5.x-1.1
CCK 5.x-1.4

Image cache was working fine and uploading through Firefox

I moved to my live test server running php5.1/mysql 4.1
with identical module setup and the image upload stopped working.

I've applied the .htaccess rules and everything is working.

Thanks again
M

One more precaution to keep Drupal from intercepting 404 errors. Change:

# Customized error messages.
ErrorDocument 404 /index.php

to

# Customized error messages.
ErrorDocument 404 default

Or you can set to a pretty html file of your choice.

And one last precaution when implementing quicksketch's last precaution...

I was still getting errors on my site after this fix -- the problem was permissions settings on the .htaccess file itself.

Changing them from:
644 / -rw-r--r--
to:
666 / -rw-rw-rw-
finally got things working for me.

Thanks again to quicksketch for figuring this out so quickly -- it's huge to getting our site upgraded to 5.x.

Umm, scratch that last bit about chmod-ing the .htaccess file. What actually did the trick was changing the ErrorDocument setting to a hard-coded html file:
ErrorDocument 404 /404.html

(Too many people poking around in the files at the same time... sorry.)

For whatever reason, "ErrorDocument 404 default" just wasn't working on our server. But as quicksearch just politely pointed out to me, even if chmod-ing had fixed it, making .htaccess writable in that way would allow for some potentially scary security exploits!...

So, if I understand correctly, everything is fixed now (or can be fixed given the instructions inside this issue), right?
If so, can this issue be closed? Or should some troubleshooting be added to the README.txt before closing it? Or is something still unresolved?

There's still a mystery "what's causing the SESSION to be dropped" question out there. Although I'm pretty sure this is outside the realm of imagefield, it would be best to find this problem also and take care of it there also. Documentation on this issue will be a must.

I've tried all the solutions mentioned above (check "use default shortcut icon", set a valid favicon path, add the rewrite rules to .htaccess, set up a 404.html and configure .htaccess to use that for 404 errors, even disabled pageroute module, ensured that devel is disabled, etc..) but am still experiencing this problem.

Image gets created in /tmp directory, but does not get moved into the /files directory. Files table in the database does not get updated. All directory permissions are set properly. Verified on FF and IE7.

I am not sure at what point image uploading stopped working .. it did used to function correctly.

Still not fixed for me. I have performed all of the above, but still having issues. Anyone wish to help tackle this?

But, I forgot to note, it works fine in IE without any problems. FF and Safari are still problems. I am tinkering and will report anything I find.

I have an interesting issue to report with this problem. This has been tested in Firefox (and Safari on OSX), Windows XP, and on Mandriva (Linux). As already stated, the problem exists where an image is not uploaded properly when using Firefox (IE 6 and IE 7 work without issue, but who ever believes IE does anything right). I have discovered something that I don't believe has been mentioned and might help to put our peepers in the right direction.

Broken Process

1. User clicks on the browse button.
2. User selects the image from their system.
3. User clicks on Upload.
4. User views the preview is available and then clicks submit.
5. Image does not appear.

Working Process (Imperfect)

1. User clicks on the browse button.
2. User selects the image from their system.
3. User clicks submit.
5. Image appears and works fine.

We have tested this repeatedly and each time the result is the same. If one avoids clicking the Upload button, the problem appears to vanish. What happens when the Upload button is selected? What is the process and has this been looked at?

Hopefully, this helps or I am crazy. :)

changing title back, didn't realize i had.

To those who are trying the various fixes in this discussion, and not getting any success: remember to also try closing and reopening browsers between fix attempts, and perhaps even restarting the server if you have such access. I forgot to do this, did many changes and had no (apparent) progress. But the next day it was working again without any meddling.

I applied the changes to .htaccess, fixed the favicon and changed the temp directory. Imagefield uploads now work, but I can't say which fix was essential...

Shane Birley, according to your tests, the problem is in the ajax upload.
When you click the upload button, the upload goes via ajax, but if you just submit the page, the upload will go via normal chanels...
So, the problem is somewhere in imagefield_js()...

I do not believe this is a CCK or imagefield issue, since I use neither CCK nor imagefield. The bug manifests itself on all of my Drupal 5.1 installations.

Clicking the "Attach" button seems to break the link between the temporary file uploaded in the "file system temporary directory" (on my system: C:\DOCUME~1\mobile\LOCALS~1\Temp\php\upload) and the final location of the file in the Drupal file system path (defaults to files). Both values are accessible via "admin/settings/file-system".

For the record, I posted a message regarding this Drupal issue in the Post Install forum.

same problem here.

my images are saved in the files/image folder while imagecache have its folder files/imagecache/image/files

after uploading an image, the image was saved inside the files/image folder but is not being saved at the files/imagecache/image/files folder.

2 weeks ago there was no such problem occurring with the site but this week it's started to have this issues.

I have the same problem, I think. I am using Drupal 5.1 and have the following modules:

cck-5.x-1.5.tar.gz
custom_pagers-5.x-1.7.tar.gz
imagecache-5.x-1.2.tar.gz
imagefield-5.x-1.1.tar.gz
views-5.x-1.6-beta5.tar.gz
views_bonus-5.x-1.0.tar.gz

I have seen the problem both with Mozilla 2.0.0.4 and Opera 9.20

Please say if I can give any information that helps.

My problem seems not to be (only) related to Imagefield. And I saw that I can make file attachments. Then I started disabling modules and saw that when I Disabled CCK.Content I could upload again. Any ideas on what to do?

I too can confirm that it seems to be related to CCK. I was unable to upload using either Image Field or Assets module. When I turned off CCK, I was able to upload again, using the Assets module.

Same here... can't get imagefield to upload in CCK.

"
The selected file /var/www/vhosts/supercleancore.com/httpdocs/d510/sites/www.bayareaflooringsuperstore.com.web/files/tmp/tmp_GbJYRl could not be copied.
"

did you try cross-posting it to CCK issues

My current guess is that this bug is a duplicate of Drupal issue #34807. I already posted a link to this imagefield issue as a followup on that Drupal issue.

did anybody find a workaround to the problem? what is the current situation on this issue?

@all, sorry this issue is a little out of hand. I'm closing it.

Reopen specific support and bug issues.
Please include:

1) CCK version
2) imagefield version
3) permissions for your tmp and files directory.
4) download method (public or private files)
5) imagefield configuration
6) Step to reproduce the problem
7) expected results
8) the unexpected results

There are a lot of reasons while imagefield might or might not work. Drupal, CCK, and Imagefield have a lot of moving parts. The more detail you provide in bug reports, the better chance you are of having someone pipe up and say they know the problem, and have a solution for you.

subscribing