Remove button doesnt remove the thumbnail

I approve - this is not very good behaviour :)

I am experiencing the same problem and came across this post. Is this as per design?
I hope it is something that can be looked at and I will be the first to test to give feedback =)

Thank you in advance!

subscribing - I think this causes confusion to end-user if their picture was in fact actually removed (if it still shows after they press the remove button)

image attached to show issue mentioned.
please let me know if anymore details are required.

thanks

Same here.

Plus, after removing, saving, and returning to the edit page, the full image is there. Actually there are two full images stacked one on top of another, but one is all black except for the part in the crop box.

After refreshing the page, there is no image.

This image is from Firefox 3.

Oops, wrong image.

Here is the actual beautiful image from the website.

I am still experiencing this issue. I am guessing others as well? More comments may help bring this issue to the surface =)

any updates on this?

this is still happening with the latest dev =(

This is still happening with 6.x-1.0-rc2

Any chance of a bug fix on this one?

I'm encountering it with an 'unlimited' imagefield upload list - it may well work on a single/limited imagefield upload list?

Yes, this is also happen on our site. Very ugly bug, we have no method to fix it.

When will this bug be fixed!

Not a proper fix but I needed a quick solution. Works for my current purposes (single images, not sure how it would work with multiples).

Place this in a module or theme's javascript file:

$('.jcrop-preview-wrapper').each( function() {
  if (!$(this).parents('.widget-preview').length) {
    $(this).remove();
  }
});

Thank you aether, it works for us!

I think i've found a proper way to fix it. I've tried to narrow down the problem and found that hook_widget_value was invoked before the actual file delete and we don't check if remove button was clicked in imagefield_crop_widget_value. This lead to some problems:
1) _imagefield_crop_resize invoked on remove event. In my case (my images is huge) this lead to memory issues on th server
2) problem, described by previous authors.

So a quick fix from me:

      $element['filefield_remove'] = array(
      // With default CCK edit forms, $element['#parents'] is array($element['#field_name'], $element['#delta']).
      // However, if some module (for example, flexifield) places our widget deeper in the tree, we want to
      // use that information in constructing the button name.
      '#name' => implode('_', $element['#parents']) .'_filefield_remove',
      '#type' => 'submit',
      '#value' => t('Remove'),
      '#submit' => array('node_form_submit_build_node'),
      '#ahah' => array( // with JavaScript
        'path' => 'filefield/ahah/'.   $element['#type_name'] .'/'. $element['#field_name'] .'/'. $element['#delta'],
        'wrapper' => $element['#id'] .'-ahah-wrapper',
        'method' => 'replace',
        'effect' => 'fade',
      ),
      '#field_name' => $element['#field_name'],
      '#delta' => $element['#delta'],
      '#weight' => 101,
      '#post' => $element['#post'],
    );
    if (_form_button_was_clicked($element['filefield_remove'])) return;

Should be added right after if ($edit) { in imagefield_crop_widget_value

Seems to me it's a major UX problem. I'm not too found of the fix in #14 but it seems to be the best as of today. Attached a patch for review.

@quadbyte,

Haven't tested yet, but patch seems to take the right approach. I'd change the docs a bit, though, and copy from filefield:

  // Because the output of this field changes depending on the button clicked,
  // we need to ask FAPI immediately if the remove button was clicked.
  // It's not good that we call this private function, but
  // $form_state['clicked_button'] is only available after this #process
  // callback is finished.
  // This is also used in filefield_widget_process().

+1 subscribing

#15 Works for me
I'm attaching the patch with the filepath fixed and the docs suggested by #16

Applied the patch in #18 - works fine for me. Thanks very much.

Regards,

- Paul

this patch helped with my problem as well.
thank you

I think that this thumbnail is ok, maybe it should be a task - an administrative option/checkbox if we want or don't want this thumb?

It is strange for a thumbnail to remain on the page after Remove was clicked by the user. It definitely looks like a bug from an end-user perspective, as when they choose a different image and upload the lingering thumbnail then disappears. What does everyone else think?

I definately agree - it makes no logical sense for this thumbnail to remain.

I fixed this using a slightly more generic method by checking if '#access' variable on the element.

Actually that previous patch caused some regressions, I also noticed there was some code that was attempting to check for the remove button but not working so this is a re-worked patch.

last patch works fine!

Thank you so much, it works for me.

Thanks, I run into the same issue and the latest patch works for me too !
For themes putting all their scripts just before page closure, I made a patch (http://drupal.org/node/962382#comment-4900678) that solve both issues.