"The path is already in use. All queued images were deleted." when adding images to imagefield

Having exactly the same problem. Any suggestions?

Here's a hint: I was having exactly the same behavior. Initial FUploads on a new node with a CCK ImageField worked fine, but failed on subsequent edits. Worse, it was working on one site in my multi-site installation, but not on another.

After several hours comparing settings between sites, (in a fit of desperation) I changed from the Sky theme (/project/sky) to Garland and it started working. I tried several other themes I had installed: Acquia Slate, CTI Flex, Zero Point and they all worked. It only fails on an edit when I use Sky.

It doesn't occur to me how a theme interacts with these modules to cause this behavior, but perhaps this will give someone with better understanding a clue to resolve it.

If it's relevant, here are the versions I have installed:

Sky 6.x-3.9
FileField 6.x-3.1
ImageAPI 6.x-1.6
Image FUpload 6.x-3.0-rc2
ImageField 6.x-3.1
ImageCache 6.x-2.0-beta10
Content Construction Kit (CCK) 6.x-2.5

Having same problem

Exactly the same problem.

Same problem here

But with the aquia slate theme
Tried to switch to Garland but no succes

The error message says that somewhere in cck, a wrong path was set. Please check this. This should not be the problem of the theme.

same problem for me..
Also it uploads some images, but not all of them, like the first 3 images, and got stuck after it with the message "validation error, please contact site administrator"....

any advice ?
-P-

Exactly the same problem, fupload doesn't work with the error message from post#1, alternative normal imagefield works..

I'm having the same problem. It looks like it's ok for the first 3 and then it goes and deletes everything. I tried ensuring the path was already created in case having to create it was confusing it. All I can think of is that it's tripping up on the token? The image path is images/user/[uid]/blogs with [uid] being a token.

Michelle

Same problem here. I created several new nodes with no problem and then, all of a sudden, I got this error upon creating new content and editing existing content.

You have to remove the Cache minimal lifetime. Then it works. (workaround at the moment).

I have this problem when caching is disabled.

Try enabling "Normal cache" and set minimal lifetime to "".

I'm experiencing the same issue. No matter if cache is enabled or not. Also switching from my custom theme to Garland didn't improve things :/

I think unsetting node_id generates the problem.
I made a little patch, works for me, check it.
(i am absolute newbie, tell me if patch format is wrong or something)

Hey lysander19,

thanks for your help.
I had no luck applying your patch but I'm not 100% sure weather it's the patch or my new system. I've been successful running patch on Windows XP previously but this is the first time I'm using it on Windows 7. Here the output:

Microsoft Windows [Version 6.1.7600]
Copyright (c) 2009 Microsoft Corporation. Alle Rechte vorbehalten.

C:\Users\klickreflex\Desktop\fupload>patch image_fupload.module image_fupl
oad_imagefield.module.patch --verbose --binary
Hmm...  Looks like a context diff to me...
(Stripping trailing CRs from patch.)
The text leading up to this was:
--------------------------
|*** image_fupload_imagefield.module    Tue Apr 06 13:16:20 2010
|--- image_fupload_imagefield.module_patched    Tue Apr 06 13:09:07 2010
--------------------------
Patching file image_fupload.module using Plan A...
Hunk #1 FAILED at 275.
(Fascinating -- this is really a new-style context diff but without
the telltale extra asterisks on the *** line that usually indicate
the new style...)
Hunk #2 FAILED at 311.
2 out of 2 hunks FAILED -- saving rejects to file image_fupload.module.rej
done

What does the exclamation mark mean anyway? Up until now I've only seen ++ and -- to indicate lines being added or removed. Now I'm confused how to apply the patch manually :/

PS: also had no luck patching in Eclipse.

I think unsetting node_id generates the problem.

No. This was implemented purposely.

Same stuf, tried with cache life time, nothing happened.

I think unsetting node_id generates the problem.

No. This was implemented purposely

Perhaps, but it seems to be the only way to get around the problem. I have been unable to locate any bugs introduced by deleting the following line from image_fupload_imagefield/image_fupload_imagefield.module, however I'm sure my situation is not the same as everyone else.

unset($form['nid']['#value'], $form_state['values']['nid']);

The error only occured when I was using the path module and the already created node I was editing had the path set to something.
I tracked the error The path is already in use. down to the path/path.module file.

By removing the nid from the $form & $form_state, when the drupal_process_form call occurs, drupal attempts to create a brand new node each time instead of adding it to an existing node.

Perhaps editing a node and creating a new one should be split up to prevent whatever bug is caused by leaving the nid set. I'm at a loss to come up with anything better without knowing what that bug is.

I only get that error if I edit the node with any other kind of callback before uploading an image, but I have only had this error once. I also cannot use the module at all without commenting this out. Well, I can half use it. I can create a new node without issue, but I can just never add any images to it later when editing.

I may need to add that I have modified the module to use SWFUpload 2.5.2 and image resizing on the client side. I have no idea if there are changes in SWFUpload.swf that may be contributing to this. I've only changed javascript to enable this. I had intended to clean up my work and submit a patch, but it does involve cutting this line out.

Tracking down that exact error message results in this chunk from node_validate()

<?php
  if (isset($node->nid) && (node_last_changed($node->nid) > $node->changed)) {
    form_set_error('changed', t('This content has been modified by another user, changes cannot be saved.'));
  }
?>

While finding out the cause is within my grasp - I have no idea how to fix this sorry. Perhaps the posted node data could be updated to the node_last_changed($node->nid) before attempting to save it, but this is essentially a hack and bypassed this protection, but so is removing the nid from posted node data.

I can't have the line in the module, you have to have it. There must be a better away around this problem.

I just had a look at the patch provided again and it already includes code to avoid the error message you describe in the exact way I described to do it. Did you fully patch your code?

<?php
              // add new files to node
              $node->$field_name = array(0 => $file);  
              // save node
+             
+             // get last changed
+             $last_node_state = load_node($node->nid);
+             $node->changed = $last_node_state->changed;
+                       	
+                       	
              node_save($node);
?>

Based on the code in node_validate() this above patch should probably be changed to this instead.

<?php
              // add new files to node
              $node->$field_name = array(0 => $file);  
              // save node
+             
+             // get last changed
+             $node->changed = node_last_changed($node->nid);
+                       	
              node_save($node);

?>

Here's the updated patch .. same format but I knocked out any ! type lines by not editing single lines ;) With only the 2 lines difference between the patches plus a few comments, it hardly seems worth it though :P

Thanks for the patch in #26. I'm getting the same error again on the "next step" (Edit Captions) screen, though. Any ideas?

The path is already in use message<, or the This content has been modified by another user, changes cannot be saved. one. If you're getting the second one, I'm guessing there's another instance of the node modification time not being updated again. Alas, I've now got this in production on the sites so I can't fiddle with it there. If I get a spare moment I'll have to hunt through the code looking for similar situations.

Just tried the patch - it seems that unsetting the nid forces the "modified by another user" error, but setting the node->changed value actually solves the issue.

I am experiencing this same problem and have tried everything listed in this thread. I have a content type with imagefield and taxonomy field. I am editing existing nodes. I have caching set normal with for minimum lifetime. I get the path is in use error and tried applying the patches (to 6.x-3.x-dev and rc2).

One thing I did notice is that before I get the error message "This content has been modified by another user..." another error briefly flashes in the same spot. I snagged a screenshot of it because it happens so quick

warning: array_merge() [function.array-merge]: Argument #1 is not an array in /home/leobaby/public_html/modules/image_fupload/image_fupload_imagefield/image_fupload_imagefield.module on line 392.

Since I applied the patches manually, line 392 for me is ...
$node->$field_name = array_merge($node->$field_name, $imagefield_files);

I would really appreciate a solution to this problem and will contribute $10 to the bounty if it's soon, $20 if it's tomorrow. I have 200+ nodes to edit with over 800 images.

I am getting the same issue when used with a Project type:

"This project name is already in use.
This project name is already in use."

This feature did work just fine when used with a Page type, but now I get other errors when uploading to Page and Event types (although the images do upload). I too need to upload hundreds of images now, and likely hundreds more over the coming months. I am willing to put down some bounty money simply for the time this would save me.

I wanted to give some input because this issue was also plaguing me...

Using 6.x-3.0-rc2.

I had an existing node that would generate "The path is already in use" when trying to FUpload images. Other nodes of the same type would work fine, just not this one.

The problematic node had "Automatic alias" for URL path settings unchecked and had a manual entry for the alias. I couldn't check the "Automatic alias" and get it to stick, it remained unchecked after saving the node and kept the manual entry.

Went to Site building -> URL aliases and deleted the manual entry, went back to the node, checked "Automatic alias", saved the node and let it automatically generate a new alias.

After that, no problems, works a charm.

Subscribing.

Having the same problem til I checked "Automatic alias." Seems to correct the problem. Not really a solution, though.

Still getting "This content has been modified by another user, changes cannot be saved" occasionally, but the changes are there when I go to 'view.' Doesn't automatically return to 'view.'

The problem is in the path auto, if you change it manual this generate the issue. I changed to auto path of the node and the problem is resolved. When I finished to upload I changed to manual path and all its ok.

The pathauto workaround is not an acceptable solution if you expect the people who are uploading images to be end-users.

Same experience as above:
- The path conflict refers to the page URL alias
- Applying the above patch causes the "another user is editing this page" error
- Changing the page URL when saving avoids the problem, but this is not an acceptable workaround.

(subscribing and thank you for your work on this)

subscribing

I confirm that it has something to do with the path module (and not necessarily path auto). As long as the url remains of "node/xxx" everything's fine. As soon as a custom path is entered (via pathauto or manually without pathauto installed) it triggers this error on editing.

How do you save the revision ? How do you target the particular node ? It has something to do with the node url, as if it tries to duplicate the url in the url_alias table.

It's this line that causes the "error":
path.module, line 143

function path_nodeapi(&$node, $op, $arg) {
  // Permissions are required for everything except node loading.
  if (user_access('create url aliases') || user_access('administer url aliases') || ($op == 'load')) {
    $language = isset($node->language) ? $node->language : '';
    switch ($op) {
      case 'validate':
        if (isset($node->path)) {
          $node->path = trim($node->path);
          if (db_result(db_query("SELECT COUNT(dst) FROM {url_alias} WHERE dst = '%s' AND src != '%s' AND language = '%s'", $node->path, "node/$node->nid", $language))) {
            form_set_error('path', t('The path is already in use.'));
          }
        }
        break;

Comes from image_fupload_imagefield.module, line 283

// Form validation
drupal_process_form($form_id, $form, $form_state);

This is a dodgy way to fix this, but:

Problem:
When editing a node that already has a path alias, the form is submitted with the path ($form_state['values']['path']). This creates a conflict with the path.module, which enforces all urls to be unique (duh) and thus sets a form error: "The path is already in use.".

Solution:
The textfield for the path alias should be empty when uploading new images to an existing nodes. As the module depends on javascript, we could add $('#startuploadbutton').click(function() { $('#edit-path').val('')}); to the window.onload function in swfupload-settings.tpl.php.

This will clear the field on each edit. When clicking "Next Step" after uploading, the node is saved using the previously declared path ! So, even though we unset the field, the url remains.

Important note !
The image_fupload_imagefield.module does not allow users to change the path ! Even when users change the url and upload new images, the new url is not taken into account ! This is, however, another problem and not part of this issue. When it will be addressed, this The path is already in use problem will be solved as well.

Same issue when editing existing nodes. Checking "Automatic alias" helps, but I don't want to change already generated aliases.

For what it is worth, I was also encountering this error. I had the URL Alias section of the edit form turned off, so it was not displaying on the edit page (I'd done this with the Display Suite module I think.) With the URL Alias section turned off, I'd see this error. When I turned it back on so it was present in the form, the error disappeared. This could be reliably reproduced. Not sure which side the error was on; I've just hidden the unwanted section using CSS for those users with permissions to edit this and have moved on, since it was a visual design rather than security issue in this case....

Setting the Minimum cache lifetime setting to NONE fixed this for me, however this is not a desirable setting when running a performance-optimized website...

For issues related to content with more than one image: Try to delete the content that is giving your problems. Check that the set number of images is unlimited. Then create the content from scratch. This is how I solved this error on my end. I also deleted the files from tmp directory before re-creating the content.

I did the same as #44 but when I try to edit the node I get the same error. This is not fixed yet? 2 years later?

#44 did it for me ... for a while,
same problem again

Making sure Automatic alias was checked solved it for me.
I would usually have this checked on anyway.