Apologies for the fairly sketchy report, I need to do some more investigating, but wanted to get an issue up since there doesn't seem to be other reports of this.

Using CCK 6.x-2.1 and imagefield 6.x-3.0-alpha3 - when uploading an image, once it's actually uploaded, the entire imagefield widget disappears from the form (i.e. completely from the HTML). I'm assuming this is a JS conflict somewhere and need to strip things down to see what's at fault, so leaving at active (needs more info).

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

catch’s picture

Title: Imagefield upload from disappears on upload » Imagefield upload form disappears on upload

ack.

orbgasm’s picture

bump

It works after a couple of retries, and sometimes it doesn't disappear at all.

catch’s picture

Status: Postponed (maintainer needs more info) » Active

OK getting a second person means we can probably consider this active. orbgasm makes a good point - this is only affecting some users on my site, and not all the time (although I did manage to reproduce it myself).

@orbgasm, are you using many other contrib modules?

catch’s picture

Here's a user report with steps to reproduce:

Using IE7, I usually click browse then paste the URL and press enter. Then I press Tab and then Space. This has always worked.

However, last time I pasted in the URL, then pressed enter, and then pressed enter again. This caused the entire fields disappear and the image to disappear as well. So I don't know if the problem could be avoided by pressing tab then space by other people?

On firefox 3/ubuntu, I get an 'HTTP error 0' whatever happens, so wasn't able to verify the workaround.

This happens with hitting 'upload'.

An HTTP error 0 occurred. 
/filefield/ahah/news/field_photo/0

If I leave the path to the image in the browse field, never click upload, then submit the node form, I get taken directly to filefield/ahah/news/field_photo/0 with an empty data line like.

{ "data": "" }

And it looks like the node doesn't get saved either.

basicmagic.net’s picture

i don't know if this is relevant or not-
but i think i remember having similar issues, a few months ago...

i substituted this file in drupal's misc/ directory-
jquery.form.js

with a different version

i have attached the original that ships with core 6.9.0, unmodified-
and the one i use

let me know if this helps you?

and / or if this switch has any impact that i am not aware of.

math0ne’s picture

I'm having this issue on a local dev image. I tried switching the JS out like basicmagic.net suggested but it did not fix the issue.

Solved for me: issue was php.ini memory_limit.

Charlie Sibbach’s picture

I'm having this occur on IE7, no signs of it happening in Firefox. Haven't tested it in Safari. I'm using this along with content_profile for user pictures; this is the only place on the site that uses imagefield. I do not have the image module installed, so it's not an incompatibility there, all other images on the site are done via file attachments + inline module.

gazwal’s picture

FileSize
1.52 KB
18.3 KB

same problem with the input class="form-submit ahah-processed" / only on ie7 :
see screenshots
=> before, when i add content : capture1.png =>OK
=>after, when i add new "upload element" : capture2 => the complete element disapear (only ie7)

orbgasm’s picture

sorry for the late response, been very busy.

@catch, i am using a large number of contributed modules on the site, but nothing fantastically out of the ordinary.

I encounter this error in Firefox, IE, Safari and Chrome on a PC. Firefox and Safari on a Mac as well.

When I create a node with this CCK field and upload a file, and create a second one immediately after, it almost always does this. This leads me to agree the problem may be attributable to memory_limit problems as math0ne mentioned.

very frustrating.

yang_yi_cn’s picture

Increase the php memory will help. But I think it's kind of related to the upload work flow, currently the module always try to extract the image file first, then check if it's oversize and try to scale it. With very large file, that means exceeding the max memory.

I'm using a 9M big image for test and the error is very easy to duplicate, although the disappear of form only happens in IE7.

So my solution is, check the file size first, if it's larger than the size allowed in the settings, just return an error message instead of trying to scale it, as that action can be dangerous and bring down the whole site.

I'll try to roll a patch when I have time.

drewish’s picture

yang_yi_cn, the problem with that approach is that the filesize check is designed to be on the final, resized file, not on the initial file upload.

yang_yi_cn’s picture

It's might be by design, but if so, the design is flawed.

Nowadays the digital cameras are capable of producing very high resolution images, which results in huge files, and these non-technical users are very likely to upload this photos directly to the website, thanks for the high speed Internet. So, it's a rather common case that will likely happen.

There should have some initial check before we do the image operation, as the operation to huge files can be potentially very resource consuming and impact on the performance of the whole site or even bring it down.

quicksketch’s picture

Title: Imagefield upload form disappears on upload » Large Images Cause Upload Form to Disappear (in IE7)

I think this check would be a great thing to add to the ImageField widget. Perhaps we could do some kind of automatic calculation?

if ($php_memory_limit < ($current_memory_usage + $image_x * $image_y * 4)) {
  drupal_set_message(t('The uploaded image is too large for this server to handle. Try scaling down the image then uploading again.'), 'error');
}

The image calculation is based on this quote:

A quite good estimation of the needed memory for an image in bytes is to
calculate the number of pixels and multiply that value with 4 (3 bytes
for the RGB colors, 1 byte for the alpha channel).

Though I have no idea how accurate this is.

It would also be wise to help the administrator choose an adequate resolution limit by calculating the theoretical limit when filling out the field settings.

Catch: If I unintentionally hijacked this issue for a different cause than your original report, please try out the latest dev and possibly #397578: Uncouple ImageField from FileField Custom Hooks, which fixes all kinds of problems (backup first).

yang_yi_cn’s picture

some update, I managed to duplicate it on FF also, and the root cause is not really image related, but the file exceeds the POST max size.

as http://ca3.php.net/manual/en/features.file-upload.php#73762 said

[quote]
As said before if POST size exceeds server limit then $_POST and $_FILES arrays become empty. You can track this using $_SERVER['CONTENT_LENGTH'].
For example:

$POST_MAX_SIZE = ini_get('post_max_size');
$mul = substr($POST_MAX_SIZE, -1);
$mul = ($mul == 'M' ? 1048576 : ($mul == 'K' ? 1024 : ($mul == 'G' ? 1073741824 : 1)));
if ($_SERVER['CONTENT_LENGTH'] > $mul*(int)$POST_MAX_SIZE && $POST_MAX_SIZE) $error = true;

[/quote]

and in filefield.module (not imagefield!) filefield_js(), it checks the _POST in the beginning:

  if (empty($field) || empty($_POST['form_build_id'])) {
    // Invalid request.
    print drupal_to_js(array('data' => ''));
    exit;
  }

so when the large file is causing empty $_POST array, it returns a empty string, which replacing the AHAH handler and makes the form disappear.

In my own module I'm doing very similar things, but actually don't have this problem as I don't rely on the $_POST to get form_id, I use form_state instead.

I will see if I can roll a patch for it.

quicksketch’s picture

Title: Large Images Cause Upload Form to Disappear (in IE7) » Large Uploads Cause Form to Disappear
Status: Active » Postponed
FileSize
1.13 KB

Thanks yang_yi_cn for your very helpful information. You're completely correct. This is all caused by exceeding the PHP post_max_size value. I could reproduce the exact problem repeatedly. By lowering my post_max_size value then uploading a larger file.

Anyone experiencing this problem, I wrote up a handbook page on increasing the upload size: http://drupal.org/node/422474

Currently this problem is extremely difficult to fix. I tried a lot of different approaches, but limitations in the Drupal AHAH framework make reporting the errors extremely difficult. In addition, because $_POST is empty, it's impossible to recreate a form element to keep it from disappearing. The core upload.module has this same problem. Exceed the maximum post size and it'll just disappear.

I've put this patch in place to at least clarify the problem (it's better than just disappearing), but I don't know if this is feasible to fix within FileField. We might need changes to core to fix it for users that are stuck with low upload limits. I'm open to any suggestions, but until others can think of a solution, I'm marking this postponed.

Attached are the patches I've committed to clarify the problem.

quicksketch’s picture

Project: ImageField » FileField

This should be in FileField, since it affects both modules.

Bill Lea’s picture

I am receiving the HTML 0 error on file uploads. I am running FileField 6 x.3 with php post and file up load limits set to 64 meg and php memory size set to 128 meg. I get failures with 20.5 meg files. I want to use the zoomify module to upload large panoramic files. say 50 meg the original images are around 500 meg so I've already downsized them about as much as I want to.

Is there any prospect of fixing this problem?

I have set all the scaling limits to unrestricted to try to stop the modules from scaling down the images but to no avail.

It may be that scaling these image types on the webserver is not feasible. In which case I can generate the zoomify files and FTP them but then the Zoomify module is well useless. If I just scale the images down they look well, invisible. I really need some way to correctly handle a panoramic image. I'd rather use someone's module than try and Kluge one together myself.

Please advise.
Bill Lea

quicksketch’s picture

Bill Lea, you might be getting capped by your web host. 20MB is a common limit for shared hosts, so no matter what setting you have in your php.ini or .htaccess file, your host may override you and push it back down to 20MB (I know LunarPages does this exact thing). It's plenty possible to use very large files, as I've used FileField to upload 2.5 GB video clips through HTTP. You might try contacting your web host and checking if they mandate an upload limit cap.

PeteS’s picture

IMO the "just update your PHP settings" is a tired cop-out answer for this problem -- the behavior being observed very obviously has a number of possible causes, and there are quite a few people experiencing it with inconsistent results. These file/image uploading problems need much more attention.

quicksketch’s picture

PeteS, I've fixed every possible problem existing in code that is reproducible. If you know how to re-create a bug from a clean Drupal site that is NOT caused by misconfiguration, I'll do my best to fix it. However, I can't help that users are wanting to upload 25MB files when their PHP installation is limited at 2MB (the PHP default), 8MB (the default for most web hosts), or 20MB (the common cap for shared web hosts). There is NOTHING that can be done at the code layer to overcome limitations in the server.

Alan D.’s picture

@pete The PHP settings have a drastic change in what happens at the code level. When a form is posted that exceeds the max size limit, the entire POST is dropped!! This is a security feature of PHP to enable users to prevent DOS attacks. There are workarounds, like setting a GET parameter within all post requests, but why rework the FAPI to take into account something that the settings should already resolve. The GET method can detect an upload error caused by this, but it can not resolve it.

kevinquillen’s picture

In Pete's case hes running it on a dedicated server where PHP has more than enough memory and file uploading size/permissions.

Alan D.’s picture

Sorry, not trying to stand on any ones toes, but the max_form_size setting is a killer to try and program against. The other messages all hovered around this general problem.

A possible direction for handing AHAH files requests when max post size is exceeded

For a small module I wrote, I'm collecting the form build id and using this in the AHAH path for the element. I still can not parse the uploaded file, but I still get the form element returned to the form:

<?php
$$element = array(
    '#ahah' => array(
      'path' => 'upload_element_js/'. $element['#build_id'] .'/'. $complete_form['form_id']['#value'] .'/'. $element['#name'],
      'wrapper' => $element['#id'] .'-ahah-wrapper',
      'method' => 'replace',
      'progress' => array('type' => 'bar', 'message' => t('Please wait...')),
      'effect' => 'none',
    ),
)

// then in the AHAH callback
function upload_element_js($form_build_id, $form_id, $name) {
  $GLOBALS['devel_shutdown'] = FALSE;
  $form_state = array('submitted' => FALSE);
  if ($form = form_get_cache($form_build_id, $form_state)) {
    $form += array('#post' => $_POST);
    if ($element = locate_upload_element($form, $name, array('#is_ahah' => TRUE))) {
      $form = form_builder($form_id, $form, $form_state);
      $element = locate_upload_element($form, $name);
      // The only way to detect if the max post size was exceeded is to check the $_POST
      if (empty($_POST)) {
        form_set_error($name, t("The file %file could not be saved, because it exceeds this form's size limit %size for file uploads.", array('%file' => $_FILES['files']['name'][$name], '%size' => format_size(file_upload_max_size()))), 'error');
      }
      $element['#messages'] = theme('status_messages');
      $output = drupal_render($element);
      print drupal_to_js(array('data' => $output));
      exit();
    }
  }

  form_set_error('form_token', t('Validation error, please try again. If this error persists, please contact the site administrator.'));
  $output = theme('status_messages');
  print drupal_to_js(array('status' => TRUE, 'data' => $output));
  exit();
}

?>

Seemed like a hack, but what do you do when you have nothing in the $_POST?

The modules got nearly 1000 users and the issue queue is fairly quiet, so this approach seems to be doing the trick nicely - as long as they use the AHAH upload. There is nothing I can do to alter the main form action that prevents this from happening.

dman’s picture

If the problem is indeed narrowed down to $_POST being discarded by PHP (must have been a bitch to trace) then my first thought would be the same as Alans:

      // The only way to detect if the max post size was exceeded is to check the $_POST
      if (empty($_POST)) {

If your AJAX handler is never called except from by a form submission, then this killswitch should pick up the error. No?

Alan D.’s picture

To the best of my knowledge, you can not pass back an error state in Drupal AHAH to prevent the wrapper HTML from being replaced, so you have to be able to regenerate the elements HTML. (Please correct me if I'm wrong on this point!) Since the form id / build state are also in the $_POST, so this solution for filefield would involve refactoring the AHAH callback URL too to move these into the $_GET parameters of the request.

For me, it was either to use another AJAX file upload framework or to use the modified AHAH callback.

quicksketch’s picture

you can not pass back an error state in Drupal AHAH to prevent the wrapper HTML from being replaced, so you have to be able to regenerate the elements HTML.

Yes, it's definitely a serious problem. Worse yet, you can't even regenerate the HTML because you don't know what the $form_id or element is that needs to be rendered (since $_POST was discarded). So regenerating the HTML isn't an option. The Drupal AHAH framework needs a better way to report errors, bail out, and not replace anything on the page in situations like this, but that's something that I don't think we'll be able to fix in D6 since it would constitute an API change.

So basically it seems our best option is to add an <?php if (empty($_POST)) ?> check and report back a proper error. But if the error occurs, you're still pretty hosed and the only thing the user can do is reload the page and try a smaller file.

Alan D.’s picture

It could worth 30min investigating this option:

  // 1) Update menu router item
  $items['filefield/ahah/%/%/%/%'] = array(
    'page callback' => 'filefield_js',
    'page arguments' => array(2, 3, 4, 5),
    'access callback' => 'filefield_edit_access',
    'access arguments' => array(3),
    'type' => MENU_CALLBACK,
  );

  // 2: Update AHAH wrappers - I didn't look into the custom JScript at all
  // Set up the buttons first since we need to check if they were clicked.
  $element['filefield_upload'] = array(
    '#type' => 'submit',
    '#value' => t('Upload'),
    '#process' => array('form_expand_ahah'),
    '#submit' => array('node_form_submit_build_node'),
    '#ahah' => array( // with JavaScript
       'path' => 'filefield/ahah/'.   $element['#type_name'] .'/'. $element['#field_name'] .'/'. $element['#delta'] .'/'. $form['#build_id'],
       'wrapper' => $element['#id'] .'-ahah-wrapper',
       'method' => 'replace',
       'effect' => 'fade',
    ),
    '#field_name' => $element['#field_name'],
    '#delta' => $element['#delta'],
    '#type_name' => $element['#type_name'],
    '#upload_validators' => $element['#upload_validators'],
    '#weight' => 100,
    '#post' => $element['#post'],
  );
  $element['filefield_remove'] = array(
    '#name' => $element['#field_name'] .'_'. $element['#delta'] .'_filefield_remove',
    '#type' => 'submit',
    '#value' => t('Remove'),
    '#process' => array('form_expand_ahah'),
    '#submit' => array('node_form_submit_build_node'),
    '#ahah' => array( // with JavaScript
      'path' => 'filefield/ahah/'.   $element['#type_name'] .'/'. $element['#field_name'] .'/'. $element['#delta'] .'/'. $form['#build_id'],
      'wrapper' => $element['#id'] .'-ahah-wrapper',
      'method' => 'replace',
      'effect' => 'fade',
    ),
    '#field_name' => $element['#field_name'],
    '#delta' => $element['#delta'],
    '#weight' => 101,
    '#post' => $element['#post'],
  );

  // Modify the filefield_js to use the callback arguments, the logic I used was pasted above and applicable to the best of my knowledge
function filefield_js($type_name, $field_name, $delta, $form_build_id) {
// eg $_POST['form_build_id'] => $form_build_id
// It looks like $form_id is redundant, I can not remember why I'm using form_builder and not just the cached form. I think it was something to do with the use of hook_value. 
}

[edit]This is not a patch, it is just an approx. workflow that may work![/edit]

kevinquillen’s picture

If AHAH is unreliable, why not make a branch that doesn't rely on it?

Alan D.’s picture

@Kevin A solution similar to the above can detect the failure of an AHAH request, a full form post losses ALL post data, not just the file upload field. This is a PHP thing. Sorry if I wasn't clear why I added the code above, it is simply a cut n paste of a solution used in another module to detect the AHAH failure.

kevinquillen’s picture

Oh, I was referring to:

'The Drupal AHAH framework needs a better way to report errors, bail out, and not replace anything on the page in situations like this, but that's something that I don't think we'll be able to fix in D6 since it would constitute an API change.'

I haven't tried any of the snippets, because I don't want to interrupt service on our clients website until a concrete solution is known about the issue.

raystin’s picture

my problem is, I have two site at local machine,they both use the same module.
1. http://localhost/wzssx
2.http://localhost/d12
but the imagefield in http://localhost/d12 can't work correct now!

the problem is :
in http://localhost/d12 site,I have a content type named "albums", and create a imagefield in this content type,set "Number of values: unlimite".
when I create a albums type content,It works correctly during I add the first image,(see screenshot-1),but after I upload the second image,the field works wrong,the preview image can't show( see screentshot-2,and then I click "add anther item",It shows two blank upload field(see screenshot-3).

if I change this filed's setting, set "Number of values" to 10 or any other value except "unlimited",it's works fine,and i can upload more than one image. (see shot-4)

Is there anyone can help me to fix this problem.
screenshot I posted here #486880

change memory limit can't fix my problem.

kirilius’s picture

I think I have the same problem. I am trying to upload about 20 images (approx 8Mb in total size). Resolution is 1600x1200 for all of them. My imagefield is set to 1024x768 max resolution and I also have 2 imagecache presets, so there is certainly some resizing going on.

I am testing this in two ways:

1) Using Image FUpload

I select the images and at some point I see this error:

    * warning: filesize() [function.filesize]: stat failed for /tmp/P1190371.JPG in .../public_html/dev/sites/all/modules/filefield/field_file.inc on line 154.
    * The selected file P1190371.JPG could not be saved. The file is not a known image format.

The second line cannot be true as when I upload the image in question, there is no problem at all.
Also about 12 images processed so far are preserved.

2) Using just the generic multi-image upload capabilities of imagefield. I upload the images one by one and I am using the "Add another item" button for every new image. I am not saving the node in the meantime. At some point everything just dies and I see the node in a state as if no images were uploaded at all. No errors were presented at that time.

At one point or another I have tried this with different numbers and sizes of images and the results are slightly different every time. Once I got about 40 images uploaded using FUpload but no thumbnails were generated for them. I saw only images entrees and descriptions but no actual images.

I am using shared hosting from Siteground. Here is the information I have from their FAQ:
:: Memory limit: 96 MB
:: max_execution_time: 45 sec
:: upload_max_filesize: 24 MB
:: post_max_size: 32 MB

Does anybody have an idea how this may be solved?

quicksketch’s picture

kirilius’s picture

Thank you for the quick answer but I don't think any of that would help:

- My host's upload_max_filesize is 24 MB (http://www.siteground.com/news_details.htm?id=149) and I am trying to upload less than 20 files, which are less than 8MB in total
- I don't seem to be limited by 21 or 25 files, as I am getting problems in less than 20 files
- I also don't have the Suhosin extension showing on my PHP report

It is a weird problem really. I am now trying to do more testing but this time I am setting up one image per node and I am using FUpload to create many nodes at once. I tried with 40 images and I got 40 nodes created without any problem. The question is how to do this with 40 images within a single node ;-)

quicksketch’s picture

Status: Postponed » Closed (won't fix)

Quoting myself from above:

So basically it seems our best option is to add an if (empty($_POST)) check and report back a proper error. But if the error occurs, you're still pretty hosed and the only thing the user can do is reload the page and try a smaller file.

We're already doing this now. As such I think we've already done about the best we can do without going to a Flash-assisted solution.

serjas’s picture

I wish , if there is a alternate way like this in ahah :) . But sadly there is not!!

'#ahah' => array( // with JavaScript
       'path' => 'filefield/ahah/'.   $element['#type_name'] .'/'. $element['#field_name'] .'/'. $element['#delta'],
       'wrapper' => $element['#id'] .'-ahah-wrapper',
        'wrapper_fallback' => 'SOMEOTHERID',
       'method' => 'replace',
       'effect' => 'fade',
    ),
if (empty($field) || empty($_POST['form_build_id'])) {
    // Invalid request.
    drupal_set_message(t('The uploaded file likely exceeded the maximum file size (@size) that this server supports.', array('@size' => format_size(file_upload_max_size()))), 'error');
    print drupal_to_js(array('data' => theme('status_messages'), 'wrapper_fallback'));
    exit;
  }