Batch imagefield - content type named "image"

did you run mysite.com/update.php?

The form (batch) should appear if you change the widget and save the field. But you could only use the image fupload widget once per node type. Be aware of this.
Please always provide screenshots what you mean.

It appears that I am experiencing the same issue.

I am attempting to change one existing imagefield field in a content type. I have changed the widget to Fupload. I have changed number of values to unlimited. I have run update several times.

But it appears that I still have the normal imagefield functionality without the ability to batch upload.

I have attached screen shots to illustrate.

This looks like an incredible module. Thanks for all your work!

Please show me the source code of your node type where the image field is present. Does your template support JavaScript?

Yes. I am using javascript for hierarchical select module. I assume you are speaking of page source of the node type? I have attached it.

Thanks for looking into this.

-dennis

Update.php should only be executed after having update the files of module image fupload.

Please try to reconfigure your imagefield. Please notice that you only can use image fupload widget once per node type.

It's very strange that fupload will not be integrated in the form. Are you sure that you set the right permissions? Have a look at your permission's table if you're using another user than admin.

I seem to be having the same issue as well. I've given the permissions to any authenticated user to see if that would make a difference (even though I'm using user 1), but no such luck. There is only one image field (set to use Image FUpload widget) in the content type.

In the back-end I get to change the settings for a Image FUpload widget, but in the front-end (creating a node) I still only get the standard filefield.

Help would be appreciated. :)

A little more digging reveals the following:

In image_fupload_imagefield_form_alter() we find the variable image_node_types which returns a non-existing field-name. I traced it back to the install file where it's being hard-set to images rather than trying to find out if any imagefields exist. (unless I'm reading this all wrong?)

Hope that helps.

Thank you for your tracking.

No, it isn't hardset to "images".
This variable caches where a node type & a (image)field is supporting fupload. After a imagefield is saved, the variable should be regenerated. (image_fupload_imagefield_widget_widget_settings_save)
Please try to create a new node type, create a new imagefield (widget: image fupload) and give me the output of "image_node_types":
print_r(variable_get('image_node_types', array()));

When I changed an existing imagefield to use the Image FUpload widget, the variable didn't get properly regenerated, it seems:

Array
(
    [image] => Array
        (
            [type] => image
            [fieldname] => images
            [image_selection] => 
            [imagecache_preset] => gallery_thumb
        )

)

When I created a new node type and added a brand-new cck field I do get a regenerated variable:

Array
(
    [image] => Array
        (
            [type] => image
            [fieldname] => images
            [image_selection] => 
            [imagecache_preset] => gallery_thumb
        )

    [test] => Array
        (
            [type] => cck
            [fieldname] => field_test
            [image_selection] => 
            [imagecache_preset] => gallery_thumb
        )

)

So it seems the problem is with converting existing imagefield fields into image fupload fields.

But in your case, the variable wasn't regenerated anyway. Or did you post the wrong output in the 2. case (everything new)?

Sorry, I posted the wrong output in case 2. Then updated my post. You just looked too fast. ;)

Thank you very much.
Now, I have "only" to track done why it won't be updated correctly. I also updated one field and it worked. Nevertheless, I will test it again.

Perhaps the sequence of events I used might help?

1. image fupload NOT installed
2. create node type
3. add imagefield cck field
4. create a few nodes
5. install image fupload and image fupload (cck)
6. edit node type, change imagefield widget to image fupload widget and adjust new settings
7. try to create a new node (no batchload is available)

Thank you for your help. I'll try to locate the problem.

OK, now I tried to redo your steps: It worked perfectly. Very strange (in your case).
Tomorrow, I will setup a complete new Drupal installation on another server and will check, if I can reproduce that behaviour.
Nevertheless, thanks for the provided information.

Not sure if it is helpful, but my issue in #5 came about following the same steps as moonray above in #14.

For all, please don't forget to set the permissions. Also don't forget to run update.php once after having updated the module files.

I just experienced the same problem on my testserver. First, everything was working perfectly, then I wiped the database and settings.php and reinstalled Drupal.

Then i did the following:
1. I enabled CCK, ImageField and Image_FUpload all at once.
2. Created a new content type, added Imagefield with Image_FUpload widget

And the result was the normal Imagefield widget.

Result of print_r(variable_get('image_node_types', array()));

Array
(
    [image] => Array
        (
            [type] => image
            [fieldname] => images
            [image_selection] => 
            [imagecache_preset] => image_fupload_preview
        )

)

Mac OSX, Apache 2, PHP 5.2.6, Safari 4, Flash 10...

edit 1:
It seems that enabling image.module fixes the problem... As if it is needed to "jump start" the whole shebang... I will research this some more.

edit 2:
Did a new clean install, with only a minimal amount of modules enabled, and now it worked perfectly. This time image.module was not installed.

OK, it really seems to be a bug, to many users having this problem. I will set up a new Drupal installation today and will try locating this misbehaviour.

But a question:
Does enabling the image fupload (image.module) module really fix it?

For me, it seemed to fix it, but it may just have been a coincidence. I did a second installation without image.module, and everything worked as expected... Not really sure where or how or why, but... Something is buggy, yes ;)

Really strange. For everybody, please use the following version of imagefield and filefield:

• imagefield 6.x-3.0-alpha4
• filefield 6.x-3.0-alpha7

Perhaps, this helps. Please comment.

Those are the ones I am using

All right. At the moment, I examine this case on an external server.

I had the same problem.

I turned off the "Secure Site" module.

Seems to work ok now.

I'm having the problem mentioned from others. Fupload widget not showing up.
I installed on recommended module version, but not fupload flash widget shown on my cck imagefield field

Try to reconfigure your imagefield settings. Also provide a list of used modules, perhaps this could be a conflict.
Furthermore you should know that you also have to change some settings in imagefield, only a widget change won't eventually work.

Thanks!!
I missed to create an imagecache preset which will be used in imagefield settings.
Then the fupload icon appear.

Maybe other guys were missed these step too.

Hello,
i am fairly a newbie to drupal as well, i feel i have set everything up correctly, and i get some weird reactions.
here is what i am experiencing:
if i create a new content type then add a new field using the fupload widget. (attached are images of what i am seeing)
i add the new field successfully, then i add a new node for the content type i just created.
here is what is strange, when i set up the fupload widget, if i select 1 for "number of values" the fuploader shows up and works to upload 1 image. however, if i set "number of values" to unlimited, it adds the "default" image uploader under the fuploader. then when i upload multiple images it gives me the message: "The path is already in use." and it deletes the images.
maybe i missed something along the way. it all seemed pretty smooth up until here.

thanks for all of the hard work and time dedicated to this project. it is greatly appricaited.

The error message does not come from fupload. Probably, you misconfigured your upload path.

I am having a similar issue. I see text that reads "Click the Select Images icon on the left below to begin" but I dont see the "Select Images" icon.

When I try to click on the "Upload Images" icon, nothing happens...

Using:
imagefield 6.x-3.0-alpha4
filefield 6.x-3.0-alpha7

This is another thing. Have a look at status message page. I think, you didn't follow the attached README.txt: You have to put some additional files into the subdirectory "swfupload".

I think I have tracked this down! This seems to be a problem with the machine readable name of the content type.

When the image.module is disabled and a user creates a content type with the machine readable name of "image" the fupload widget doesn't show up. Simply renaming the machine readable content type name to "images" fixes this and causes the widget to show up. Renaming the content type back to "image" causes the widget to disappear.

I assume this is a problem with the module's integration with image.module. It should still allow users to have a content type named "image" regardless of whether or not the image.module is used.

Steps to reproduce:

1. Create a content type with the machine readable type name set to "image."
2. Add an imagefield and set it to image fupload widget type.
3. Go to node/add/image
4. Fupload widget doesn't show up.

Steps to fix:

1. Rename machine readable type name to "images."
2. Add an imagefield and set it to image fupload widget type.
3. Go to node/add/images
4. Fupload widget shows up.

or

1. Create a content type with the machine readable type name set to "images."
2. Add an imagefield and set it to image fupload widget type.
3. Go to node/add/images
4. Fupload widget shows up.

Thanks for your research.

I am still having a problem with nothing showing up. I reinstalled and made sure the 3 swfobject files were under /swfobject. Any ideas?

Grandcat, where can I check status messages?

Status messages of Drupal should be accessible at /admin/logs/status.

As #25 suggested, I believe that that there is an conflict with the secure site module. I am now able to select images to upload, but when click save, it fails with an error code 412, and in the space for showing upload progress my Secure Site site login screen appears, then the process fails. I have attached a screen shot showing what happens after files have been selected and I click on save.

Unfortunately, my site requires the use of the secure site module.

Thanks again for a great module.

I already heard about conflicts concerning this module. I didn't do any testings on this module so far what exactly causes the error message.

Has anyone come up with a solution for the conflict with the secure site module? Unfortunately, I don't have the skills to trouble shoot this myself.

Thanks.

Seems like the 'image' node type name is hard coded into the module. There's actually no need for that, as one can call node_get_types() and check which module handles the current content type.

Appropriate patch attached.

My bad, hadn't noticed that there were other occurrences of this check. I have added a function that accepts the node type and returns true if the node is handled by the Image modules and changed all occurrences of this check to calls to the new function. Patch attached.

Patch in #41 failed to apply for me, the hunk for includes/images.previewlist.image.inc. Manually moving the changes in did fix this issue for me.

Hi,

the patch from #41 neither applies from ./sites/all/modules/image_fupload/, nor from within sites/all/modules/image_fupload/includes/, it seems to be rolled to be executed from the Drupal installation's root. However, from there I'm getting:

# patch -p0 < image_fupload.module.patch
(Stripping trailing CRs from patch.)
patching file sites/all/modules/image_fupload/includes/images.previewlist.image.inc
Reversed (or previously applied) patch detected!  Assume -R? [n] n
Apply anyway? [n] n
Skipping patch.
1 out of 1 hunk ignored -- saving rejects to file sites/all/modules/image_fupload/includes/images.previewlist.image.inc.rej
(Stripping trailing CRs from patch.)
patching file sites/all/modules/image_fupload/image_fupload.module

At least in this form it doesn't fix the issue for me. Btw, my Imagefield content type is "image".

Greetings, -asb

#33 fixes it for me. thanks! this is on drupal-6.14 with -dev modules and image.module disabled.

Patch works when manually applied. Needs to be rerolled from root module directory.

I can confirm that the method in #33 fixes this issue for me as well.

This causes a conflict with the Views Gallery module, of course, since that module creates a content type 'image' for all the images. I renamed the content type to 'photo' and it works swimmingly.

I think either the Image FUpload module needs to be fixed so it can handle imagefields in an image content type, or Views Gallery should change it's default content type to photo or something different.

Patch Rolled correctly against Head.

i can confirm this.

it works well if you create for example:
content type - name: Images
content type - type: images
fields - label: Images
fields - name: field_node_image
fields - datatype: FIle->Image Fupload

also worth noting, for a single field per node - dont know if its mentioned in the docs, but here it goes:
set storage mode: One image per node (the other option for multiple images per node)
Editable fields:
Title (Node)
Description (Node) (aka Body, this should be renamed)
(you can uncheck the last 3, the imagefield ones)
Title (ImageField)
Alt (ImageField)
Description (ImageField)

mark Required to force uploading at least one image
set Number of values: 1 (or more for multiple images per node)

please not that this issue is for when the content type is named "image"

yes works. had to use the following to patch it though

patch -p0 < image_fupload-399114.patch

I cant get the patch to work it give me this error:

patching file includes/images.previewlist.image.inc
Assertion failed: hunk, file ../patch-2.5.9-src/patch.c line 354

grandcat: this is severely needed, and already RTBC, is there something holding up committing this to dev?

subscribing

here is the patch against the latest 3.x dev from Feb (1st?) (old patch works fine, see #50).

Worked for me as well.

great patch! works fine. Thanks!

subscribing.

Will be applied soon. Thank you, frankcarey.

#25 #37 #39 mentions Secure Site module not working properly with Image FUpload. There is no dedicated issue for this and it does not relate to mod_security.

What works for me -
in securesite.inc where cron.php passthrough takes place, line 360 ,

    // Form authentication doesn't work for cron, so allow cron.php to run
    // without authenticating when no other authentication type is enabled.
	$sttest = request_uri();
	$sttest = trim($sttest);
    if (($sttest != "/fupload/flash") && (request_uri() != $base_path .'cron.php' || variable_get('securesite_type', array(SECURESITE_BASIC)) != array(SECURESITE_FORM))) {
	  drupal_set_title(t('Authentication required'));	  
	  $content = _securesite_dialog_page();
    }

FYI just used this again - although dev is now much more recent, patch is still working as of Aug 3.

subscribing

sub

Here a small modification of previous patch (#54), that provoked a "Object of class stdClass could not be converted to string" in watchdog theme function, because of the object $upload_user being passed as a watchdog variable.

The change is on line 190, as follow:

- watchdog('image_fupload', 'attepmting to authenticate session id @sid, user @uid from IP address @ip', array('@sid' => $sid, '@uid' => $upload_user, '@ip' => ip_address()), WATCHDOG_DEBUG);

+ watchdog('image_fupload', 'attempting to authenticate session id @sid, user @uid from IP address @ip', array('@sid' => $sid, '@uid' => $upload_user->uid, '@ip' => ip_address()), WATCHDOG_DEBUG);

By the way I also corrected the spelling mistake of 'attepmting' (=> attempting) ;)

Not really a functional patch, but avoids to have this useless error appearing.

This issue is still active
Avoiding the "image" content type name seems to be enough as a temporary fix
Sub

Variable name wrong in line 136 of the patch:

function _image_fupload_is_image_module($type){
  $content_types = node_get_types();
  return ($content_types[$node_type]->module == 'image');
}

Should be:

function _image_fupload_is_image_module($type){
  $content_types = node_get_types();
  return ($content_types[$type]->module == 'image');
}

Otherwise, works for me!