Posted by Holie on January 3, 2009 at 4:40pm
| Project: | Image FUpload |
| Version: | 6.x-3.0-rc2 |
| Component: | User interface |
| Category: | bug report |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | needs work |
Issue Summary
When uploading images into galleries, the first three go allright, but for the others I keep on getting this error:
Validation error, please try again. If this error persists, please contact the site administrator.When uploading other images into another album, some of the failed images from the previous album come along into the new album.
I'm trying to import images into acidfree galleries.
Versions: Drupal 6.8, image_fupload 6.x-2.1, image 6.x-1.0-alpha3, acidfree 6.x-1.x-dev
Comments
#1
Please try to activate "normal caching" at Home >> Administer >> Site configuration >> Performance (Page cache) and tell me if it helps.
#2
Grandcat,
Normal caching is allready active.
the images names contain spaces and "(" ")", could that have anything to do with it?
#3
No, spaces are no problem for image_fupload.
Have you set another thing at performance page? For example, minimum page lifetime?
Could you create a screenshot of this page?
EDIT:
I saw that you were using Chrome, could you also test this special case in Firefox or IE 7?
#4
I'm having these issues in chrome, ie7, ff3.0.5
The screenshots also include the installed modules and the error I get on image_fupload
Edit: Turning all caching completely off and clearing the cache doesn't seem te be a solution. When uploading 4 images there is no problem, when uploading 60 there is.
#5
So, I think, it's a configuration thing:
I saw that you have set "minimum lifetime" to 1 min. This could be a problem. Try to disable this option by setting it to the following:
<none>Have a look at the screenshot and tell me if it helps.
#6
When setting it to
<none>the problem is solved, thanks!#7
OK, so I think, this is a Drupal Issue.
#8
Automatically closed -- issue fixed for two weeks with no activity.
#9
I am having the same problem and disabling the minimum cache lifetime worked but this isn't really a solution. Is there another way to fix this?
#10
+1
I agree.
#11
At the moment, no.
#12
subscribe
#13
subscribe.
Why is this a Drupal issue?
#14
I worked around this by disabling the cache_lifetime in function image_fupload_imagefield_node_create()
added this after global $user (line 236) :
$cache_lifetime = variable_get('cache_lifetime', '');variable_set('cache_lifetime', '');
and this before the function closes (line 431)
variable_set('cache_lifetime', $cache_lifetime);#15
I'm using Boost for static caching, and #6 (setting cache to ) does not work. But for the rest the issue is the same.
#14 solves the problem in my site. Would it be possible to implement that fix into the code of the next release?
#16
Patch based on 14,
but at a different location in the file
#17
#18
The location the settings are done, can't be taken. This would be too buggy.
#19
Tried the lines in #14 (http://drupal.org/node/353915#comment-1860284) and the validation error ceased.
#20
Also this error occures when using memcache. Any chance for it to be fixed?
#21
Patch in #16 worked for me and I am using memcache among other things .. thanks a ton alanburke for fixing it, my new server and fupload were not playing nice until I found your fix, awesome!
Cheers!
#22
Patch in #16 worked for me. Thanks a lot.
#23
Patch in #16 worked for me too, thanks
#24
I repeat that #16 is a hack. You could do the same by setting the value in Drupal's cache settings.
#25
What exactly cause conflict for sites with the page cache turned on?
(apparently on function fupload_filetransfer)
#26
It's the AJAX mechanism which is repeated for each image. If there's no cache enabled, the form won't be cached.
#27
Setting minimum lifetime to fixed the problem for me as well!
#28
Can we change the title of the issue to "Validation error when cache is enabled" ?
#29
#30
I can *also* confirm that this fixes problems with uploading behind a proxy server. I was at my wits end trying to fix this problem, and turning off the minimum cache lifetime solved both problems in one fell swoop!
#31
Hi there,
I changed a small piece of code to workaround this issue. My "minimal caching duration" is set to 5 minutes and everything works.
// Load the form from the Form API cache and check if valid$oldUserCacheTime = $user->cache;
$user->cache = 0;
$form_state = array('rebuild' => TRUE, 'values' => $_POST); // rebuild option needed to prevent that "_image_node_form_submit" gets executed by drupal_process_form
if (!($form = form_get_cache($form_build_id, $form_state))) {
// code based on upload.module (15/08/2008)
form_set_error('form_token', t('Validation error, please try again. If this error persists, please contact the site administrator.'));
$output = theme('status_messages');
drupal_json(array('status' => TRUE, 'data' => $output));
exit();
}
$user->cache = $oldUserCacheTime;
Cheers,
Peter
#32
I've turned minimum cache off (we turned it on last week and then turned it off again for more than a week now) but I'm still getting the error. Images upload, and then the processing starts, but the processing widgets just keeps trying post requests over and over, but keeps getting this response:
{ "status": true, "data": "\x3cdiv class=\"messages error\"\x3e\nValidation error, please try again. If this error persists, please contact the site administrator.\x3c/div\x3e\n" }
We are also running memcache, but not for sessions. And we are running behind a load balancer.
#33
yeah #16 fixed it for some odd reason. Looking at my variables table 'cache_lifetime' == 's1:0' . Again, I manually set min cache lifetime to none, and this was still an issue.
#34
I tried patching with #16, but that didn't do the trick for me.
My site is accessed behind a corporate firewall (MS proxy server), and upon upload, the first three or four pictures always go through, then the rest get stuck in the queue, while a proxy authentication window pops up, asking me to log into the proxy server again.
When I tunnel via SSH, or access the site from practically everywhere else, everything works swimmingly. :(
#35
O,k, but for your case: It seems to be the proxy's fault.
#36
Hmm... I was having trouble with this in both IE and FireFox all morning, then I changed line 26 of swfupload-settings.tpl.php to:
<?phpdebug: true,
?>
After doing this, I could see all the data output of swfupload, and everything worked [Edit: works in IE after one failed attempt, doesn't work in FF]... I'll try a few other settings as well, and we'll see how it goes! (I think setting the "use_query_string" setting to 'true' in the SWFUpload settings might help as well, but wouldn't be as secure).
(By the way, it seems you're using tabs - at some point, you might want to switch to soft tabs).
EDIT: When I set the debug mode to 'true' and try uploading via firefox, here's the output (it doesn't advance past the last line):
SWF DEBUG: StartUpload: First file in queueSWF DEBUG: Event: uploadStart : File ID: SWFUpload_0_0
SWF DEBUG: Global Post Item: PHPSESSID=[redacted]
SWF DEBUG: Global Post Item: fieldname=field_image_gallery_image
SWF DEBUG: Global Post Item: nodetype=image_gallery
SWF DEBUG: ReturnUploadStart(): File accepted by startUpload event and readied for upload. Starting upload to /fupload/flash for File ID: SWFUpload_0_0
SWF DEBUG: Event: uploadProgress (OPEN): File ID: SWFUpload_0_0
SWF DEBUG: Event: uploadProgress: File ID: SWFUpload_0_0. Bytes: 165043. Total: 165043
#37
Thanks Omerida & Alanburke....#16 worked for me too..