Hi,
I am running CCK 5.x-1.5 with imagefield 1.30.2.7 2007/02/23 on drupal 5.2. I have upgraded JQuery to version 1.1.2 to use the lightbox module.
drwxrwxrwt 4 root root 4096 2008-01-30 14:00 /tmp
drwxrwxrwx 9 onepage onepage 4096 2008-01-30 13:58 /home/onepage/onepagelisting.co.uk/user/htdocs/files
I am running with the public download method.
The image field is set to 1024x768 with the path set to "listingimages", custom text is enabled and multiple values are enabled,
In php.ini: magic_quotes_gpc = Off. I've tried with both favico enabled and disabled (when enabled set to the default icon).
---
The problem.
Up until this yesterday everything seemed to be working as expected with the imagefield module then image uploading starting failing for my bespoke content type in FireFox 2.0.0.11. I could browse for an image, select the name, click upload and see the thumbnail appear correctly but when clicking submit the image is lost.
If I browse and select the image name and click submit directly (missing out the upload button) the upload works correctly and the image is correctly saved with the node.
As of yesterday onwards only occasionally does uploading under FireFox works but in general if I use the upload button, the image is lost on the submit.
If I try the failing scenario with IE vn 6.0.2900, it all works correctly.
I've dug around the logs to try find any errors but it seems that nothing is being reported for the problem..... So I installed the trace module to start monitoring the SQL calls, logs, notices etc and as with all good intermittent issues as soon as I enabled trace, everything started working fine. As soon as I disable the trace module it stops working again..... Hence I wondered if it is a timing issue of some sort....
The failure is reasonably consistently occuring at the moment for me. I am a developer but have little knowledge of AJAX as of yet - where should I start looking to try to get to the bottom of this?
I have not updated to the latest RC as I could not find any mention of problems similar to this in the release file for the imagefield module.
I have dug around in the support and problem reports and found comments which claim to fix it but will admit I'm getting a little lost in the noise of them all. So any pointers on where to look would be appreciated.
Thank you.
Mark
Comments
Comment #1
markedmunds commentedI missed from the original posting that when the upload fails, the image files are left sitting in the /tmp directory. (Note: I am running on a dedicated host and do not have permission issues such as those that you might get on a shared web server).
Thanks,
Mark
Comment #2
robotjox commentedI can confirm this.
Upload isn't working when hitting the upload button, only when hitting submit.
The image is stuck in the temp folder (regardless where that is)
I can't confirm it working with IE, though - same problem for me with all browsers.
This is pretty much a showstopper for me regarding this module, as I can't count on my users not using the upload button.
I'll mark this as critical bug for now, please correct me if I'm wrong.
my details:
drupal 5.6
php5
debian etch w. apache2
I tried the HEAD version with no improvement.
Comment #3
robotjox commentedI kinda fixed the problem - for me anyways - with what I'm pretty sure constitutes an ugly hack :)
I inserted this line in the module:
$path = trim(substr($path, 50), '\\/');just before this line
$url = file_create_url($path);in the function "function theme_imagefield_image"
The number 50 is the number of characters that come before the "tmp"-folder in my filepath - obviously this has to be adjusted to your own path...
As if this isn't ugly enough, I also had to change the output of the image to this to get the image shown:
return '<img src="'. check_url($url) . check_plain($title) . '" blablabla...I used the check_plain($title) function, because I don't know how to get the filename - this probably won't work, if you're using custom titles for your images.
Again - this works for me, but it's of course in no way ready to be made into a patch - I only hope this might inspire someone more knowledgeable in php to turn it into something good.
//EDIT: This information might be useful too:
My system path is: files
My temp folder is: files/tmp
For this hack to work I had to uncheck all these options in the imagefield options:
Enable custom alternate text
Enable custom title text
Required (yes, it's true...I don't know why, but it's as if drupal doesn't register the upload and returns error if I set the field required...)
please make sense of all this somebody...
Comment #4
robotjox commentedoh man, I spoke too soon, it seems.
The above code works as intended on my localhost, but I still experience problems on my virtual server (debian etch).
The preview works, though. I can upload to the temp folder and see the uploaded image as well as delete and replace it, but the image does not seem to be uploaded to the files folder when I hit submit after previewing. As before, erverything works, if I don't use the preview option, but I can't really explain this to my users...
so I guess this is somehow related to some server upload settings?
any input would be highly appreciated!
Comment #5
markedmunds commentedHi RobotJox,
I think this problem is something related to ajax. An experiment you could try is to enable the trace module and see if having it report diagnostics to a log file alters anythiang. I find that enabling the trace makes it all work for FireFox - and then disabling it makes the image upload fail again... I'm assuming the trace module makes it work for me as it changes the timings/order of events...?
I've been scanning through the problem reports and found these which are similar: http://drupal.org/node/34807, http://drupal.org/node/191237 - but they do not give me a working solution.
This pending patch seemed relevant until I found the fix is in the subscription module - which I am not running: http://drupal.org/node/183649.
This problem is the same but for filefield and is reported as fixed in 5.2: http://drupal.org/node/194001. Unfortunately it doesn't say how it was fixed...
So - I too am still unsure how to proceed on this one..... Any thoughts anyone?
Thanks,
Mark.
Comment #6
markedmunds commentedI am still having this problem and think other people are also suffering too (http://drupal.org/node/154969). For me, the issue only seems to occur for FireFox (vn 2) where as IE 6 seems ok. However, it has worked in the past with FF on my machine. I have also seen the problem on a different machine on a dial up connection - same FF fails, IE works.
I do not believe it is a FF issue - and if timings of things are changed, (by enabling the trace module) it all works?
Is the problem related to http://drupal.org/node/152695?
Comment #7
jscoble commentedDo you have the firebug extension installed? If so, does it provide any additional info that you can either use to resolve the issue or post?
If not, you might want to install it. It may provide some additional insight.
Comment #8
markedmunds commentedHi Joel,
Thanks for your append.
I've installed Firebug and gone throught the scenario - and it still breaks. Uploading an image I see a new request/reponse for the image on the Net page of FireBug. The thumbnail image is displayed correctly as expected.
The image request/reponse header is as such:
Response Headers
Date Sun, 17 Feb 2008 19:25:52 GMT
Server Apache/2.0.55 (Ubuntu) PHP/5.1.2 mod_ssl/2.0.55 OpenSSL/0.9.8a
X-Powered-By PHP/5.1.2
Set-Cookie SESSf1100d7a4fc83ae5f6cc92177d4d1ed4=65f5979c60c30747d67f04755b3a6ad9; expires=Tue, 11 Mar 2008 22:59:12 GMT; path=/; domain=.onepagelisting.co.uk
Expires Sun, 19 Nov 1978 05:00:00 GMT
Last-Modified Sun, 17 Feb 2008 19:25:52 GMT
Cache-Control store, no-cache, must-revalidate, post-check=0, pre-check=0
Content-Length 7322
Keep-Alive timeout=15, max=99
Connection Keep-Alive
Content-Type image/jpeg
Request Headers
Host www.onepagelisting.co.uk
User-Agent Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.8.1.12) Gecko/20080201 Firefox/2.0.0.12
Accept image/png,*/*;q=0.5
Accept-Language en-gb,en;q=0.5
Accept-Encoding gzip,deflate
Accept-Charset ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive 300
Connection keep-alive
Referer http://www.onepagelisting.co.uk/node/54/edit
Cookie SESSf1100d7a4fc83ae5f6cc92177d4d1ed4=65f5979c60c30747d67f04755b3a6ad9
The edit http request/reponse block looks like
Response Headers
Date Sun, 17 Feb 2008 19:25:52 GMT
Server Apache/2.0.55 (Ubuntu) PHP/5.1.2 mod_ssl/2.0.55 OpenSSL/0.9.8a
X-Powered-By PHP/5.1.2
Set-Cookie SESSf1100d7a4fc83ae5f6cc92177d4d1ed4=65f5979c60c30747d67f04755b3a6ad9; expires=Tue, 11 Mar 2008 22:59:12 GMT; path=/; domain=.onepagelisting.co.uk
Expires Sun, 19 Nov 1978 05:00:00 GMT
Last-Modified Sun, 17 Feb 2008 19:25:52 GMT
Cache-Control store, no-cache, must-revalidate, post-check=0, pre-check=0
Keep-Alive timeout=15, max=100
Connection Keep-Alive
Transfer-Encoding chunked
Content-Type text/html; charset=utf-8
Request Headers
Host www.onepagelisting.co.uk
User-Agent Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.8.1.12) Gecko/20080201 Firefox/2.0.0.12
Accept image/png,*/*;q=0.5
Accept-Language en-gb,en;q=0.5
Accept-Encoding gzip,deflate
Accept-Charset ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive 300
Connection keep-alive
Referer http://www.onepagelisting.co.uk/node/54/edit
Cookie SESSf1100d7a4fc83ae5f6cc92177d4d1ed4=65f5979c60c30747d67f04755b3a6ad9
Clicking submit, then submits the page and the image is lost.
If you have any suggestions on what I should look for in Firebug, I'd be most appreciative. There are not javascript errors or problems reported.
If it is a $session issue, I assume the session is only visible on the server side and I can't get to it with Firebug?
Thank you,
Mark Edmunds.
Comment #9
vm commentedI believe these types of situations are fixed in the 2.x RC4 release
Comment #10
markedmunds commentedOk - I'll give it a go and report back.
Thank you,
Mark.
Comment #11
dopry commented@markedmunds: Do uploads work if you just preview or submit without using the js upload? Are there any errors in watchdog or in the apache error logs?
@robotjox: can you open your own issue?
Comment #12
markedmunds commentedHi Dopry,
>> @markedmunds: Do uploads work if you just preview or submit without using the js upload?
Yes, it always works if I just submit without using the js upload. I've disabled the preview button on my system (long story) so can not test this route.
>> Are there any errors in watchdog or in the apache error logs?
No, I can not find any error logs anywhere - checked the watchdog, apache error logs and syslog messages.
I'm still running 1.30.2.7 2007/02/23 on drupal 5.2 as per the original posting and have not upgraded to the latest of everything yet - I plan to do this next week.
If you need to know anything else or want me to try anything, just ask.
Thank you,
Mark
Comment #13
kid-06 commentedHi Mark!
I have the same problem, so I was very glad to find this issue )
So, here is my story:
I had a well-working drupal5.2 site with cck 1.6 and imagefield 1.1, and decided to upgrade it.
Today, working on my localhost, with D5.6 and the same cck and imagefield I've find out that images disappear on upload. Nevertheless, old images with old nodes (from old database) work fine, but when I try to upgrade the old node, image disappears. The one interesting thing I've figured out was the next.
When outputting the $node object with
I see the following, as one of the items of [content] => Array (the node object has no [field_thumbnail] field, but I think it should), and no image is shown:
As you can see, the [#value] is empty.
But if I try this on the old nodes or on the new Drupal installation I see the next (and the images work well):
[field_thumbnail] is one of the object's fields, in opposite to the previous case.
and in the $node->content array:
I think, that's the place, from which we could try to understand something...
In addition, my images do not work, even if I do not upload them, and just press the submit button. If I want to preview the node before submitting, I see the placeholder for the image, but no image is shown, because drupal generates some awful path for that image, smth like this:
/files/imagecache/thumbs/D:\webdev\www\tmp\tmp534F.tmp
I hope that all of this will help somebody to make some fix for all this stuff...
Comment #14
dopry commentedAll of you are using 1.x-dev or the released 1.1 branch? I've pretty much stopped working on 1.x myself... If you have patches for it I will consider and review them, but you need to submit patches in unified diff format.
thanks.
Comment #15
dopry commented1.x is not supported.
Comment #16
cangeceiro commentedDoes anyone have an appropriate fix for this? I am also experiencing this but its on imagefield 2.x-dev
Comment #17
msjones design commentedsubscribe