Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.I've created a site where I have file products that have images associated with them. I'm using all the latest stable versions of modules as of this month, including cck, filefield, imageapi, imagefield, imagecache etc.
When I go to remove an image from a product in the admin, the ahah spinning wheel spins, but nothing happens. Firebug reports the following javascript error:
"new_content is undefined
[Break on this error] if (new_content.parents('html').length > 0) { ahah.js?T (line 178)"
Since "new_content" is set on the line above as an ahah return, it seems the ahah command is not returning anything, but I don't know how to debug this.
I'd be happy to use the table add/remove method used by filefield rather than the button used by imagefield, or any kind of non-ajax solution, but I don't know how to implement it. Can anyone help please?
| Comment | File | Size | Author |
|---|---|---|---|
| #14 | Picture 1.png | 123.08 KB | bjornarneson |
| #12 | 494666-filefield.patch | 1.17 KB | gordon |
Comments
Comment #1
quicksketchIt's hard to say where this is coming from without being able to see the error. My sandbox site works just fine on a fresh install, you'll need to provide steps on how to cause this error from a fresh install of Drupal.
Comment #2
erosenfield commentedOkay, from a fresh install of the latest version of drupal, all I did was add the modules:
adminrole
advanced_help
cck
ctools
ec_file
ecommerce
filefield
imageapi
imagecache
imagecache_profile
imagefield
mimedetect
panels
private_upload
rules
token
views
views_bulk_operations
These are all the absolute latest versions of these modules.
I also installed and enabled the zen theme and created my own subtheme, but right now it's just a copy of the sample subtheme. The
I'm going to try disabling some modules to see if it fixes the problem.
Comment #3
erosenfield commentedAlso note: I added to the content type product an imagefield, and that's the image I'm trying to remove.
Comment #4
erosenfield commentedOkay, I wiped out the database and JUST enabled cck with filefield and imagefield and it worked fine. I'm going to reenable modules one by one and see when it breaks.
Comment #5
erosenfield commentedOkay, found the culprit! It is the file_product module!
This is, of course, the dev version of file_product since a production release for version 6 doesn't exist yet. My site needs this module. Unless one of you can suggest a fix, I'll have to go back to Drupal 5.
Comment #6
erosenfield commentedActually, going to try UberCart as an alternative solution.
Comment #7
erosenfield commentedInterestingly, I had to deactivate the entire ecommerce set of modules before the images started working right again.
Comment #8
quicksketchGreat, so it's not really a bug in ImageField it sounds like. Could you transfer this to the appropriate issue queue? I'm not really sure where this "file_product" module lives.
Comment #9
erosenfield commentedI think it may be a problem with ImageField getting along with eCommerce en toto, (or vice versa), but I'll change it to e-Commerce.
Comment #10
gordon commentedI have now fixed this in dev.
Basically the problem was that in ec_common I am extending the #process to include additional information on in the #ahah, and because both filefield and imagefield are building #ahah fields on the #process I was not able to get my process as well.
I have added an additional handler to these fields so that the the additional #ahah information is added.
Comment #11
gordon commentedSee commit http://drupal.org/cvs?commit=228696 which should be able to be patched against any resent version of e-Commerce
Comment #12
gordon commentedHi,
After fixing this in e-Commerce I thought about this more, and I actually found that this is a bug in filefield.
basically what is happening is that when fieldfield is creating the upload and remove buttons it is adding #process fapi in these submit buttons. This is then causing problem for other modules (like e-Commerce) which add adding additional processing to the submit buttons which is not being added because it has already been set by filefield.
By removing the #process off the submit elements it fixes this problem.
Comment #13
quicksketchI'm not sure when this might have been fixed in Drupal core, but at some point #process functions were not automatically added if an element was being added inside of a #process function itself. At least, that's what I believe those lines where added. However, after removing the lines as suggested in the patch, everything still continues to work, which is a good sign.
I've applied the patch, but I'm going to let it chill for a little bit before making a new release to see if any problems creep up from it.
Comment #14
bjornarneson commentedActually, I think I may have found a problem. When I apply Gordon's patch to filefield_widget.inc, any node/add or node/edit page with Wysiwyg API is broken. Unexpectedly, the rich text editor doesn't load and toggling back and forth between input formats has no effect. I can confirm that undoing the patch returns everything to normal.
I'm using:
cck-6.x-2.4
filefield-6.x-3.1
imagefield-6.x-3.1
wysiwyg-6.x-2.0 (with Tinymce 3)
I've attached a screenshot of the Firebug console output when loading a node/add page containing a filefield input with Gordon's patch applied. Hope it helps.
Comment #15
quicksketch@barneson This doesn't seem to be at all related. FileField and WYSIWYG should have absolutely no connection. I'm unable to reproduce on the current release and we haven't gotten any confirming reports in the 6 months the current release has been out. If it still comes up in current releases of modules, please open a new issue.