Editing node causes Referencing to the file used in the field is not allowed

Hm, that's certainly not good. This happens only with new nodes? Which version did you upgrade from (since it last worked)?

And the images that are already uploaded continue to display? I'm not sure how this could happen, since that access check is based on the file already existing in the database. If it can be displayed, then it obviously exists in the database, and ImageField should pass the check just fine.

Are you sure you upgraded ALL the files in your FileField installation? Completely delete the existing filefield directory, then upload the entire new copy. Perhaps the implementation of hook_file_references() (which does the check) wasn't updated with the rest of the module.

I'm sad to say that I'm getting the same problem.

I just upgraded this site to Drupal 6.11 and the latest CCK and Views.

I upgraded to Filefield / Imagefield 3.0 from dev releases dated November 2008.

The content type in question has two image fields on it, "Project Picture" and "Front Page Project Picture".

I was using FileField Meta, but have also disabled it and see the same behavior.

Basically, as reported above, I can save a node once, and the image shows up in the widget and I can click the widget link and be taken to the image. (However, the image does not show up in Views at this point, so it appears that the image never fully makes it in there.)

Upon saving the node again, I get "Referencing to the file used in the Project Picture field is not allowed."

Putting an image upload in the "Front Page Project Picture" field doesn't make a difference.

Let me know if you need more information on this one or have other things I should try. Thanks!

Have the same problem with video_upload field.
I installed video_upload 6.x-dev, file_field 6.3(also was trying 6.x-3.x-dev, 2009-Apr-28 version), try to upload video and the same error:

Referencing to the file used in the Videofile field is not allowed.

File is uploaded to the server successfuly, but I look on page http://mysite/admin/content/video-upload and there is no file in the queue on youtube.

I am getting the same problem with my imagefields. Create works fine, editing fails with error in issue title. CCK 6.x-2.2, Filefield 6.x-3.0

UPDATE: definitely a Filefield 3.0 issue. Rolling back to alpha7 resolves the issue (but that also rolls back the security update).

jrefano, "rolling back" to alpha7 without restoring a database backup will permanently damage the data stored by FileField (since update.php will not be run again when you update again later). I'd not recommend this under any circumstances. In addition, FileField Sources won't work at all under any version earlier than 3.0 RC1. The field will show up, but data will not be saved when using sources. It's also important that the security update stay in place, since without it you're vulnerable to users deleting any file that is stored in the database if they have access to upload.

Right -- I reverted my sites db to the version I saved before I updated to 3.0 RC1. My site is in offline development so I'm not that concerned with the security issue for the time being. This issue seems to have been confirmed by multiple users now, do we have any idea whats causing it? I would love to help but sadly this module is a bit beyond the scope of my coding skills.

No I haven't been able to reproduce the problem, so I'm not sure what's causing it or how to fix it. :-/

Just confirming that I get the same problem.

We have a content type with a 'Featured Image' field. When I edit and then save the node and I get the following error.

Referencing to the file used in the Featured Image field is not allowed.

Deleting the image off, making and saving my changes to the node, then uploading the image again does work, but subsequent editing and attempting to save throws the error again.

Drupal 6.12, FileField 3.0, CCK 2.2

If I find anything further I'll post it back here.

Quicksketch, I'm currently attempting to upgrade the video upload module to work with the stable release of filefield, and I'm also running into this issue. I've traced it to the following in filefield.module:

  // Filter down the list just to file fields.
  foreach ($fields as $key => $field) {
    if ($field['type'] != 'filefield') {
      unset($fields[$key]);
    }
  }

Looking at recent changes to imagefield, it looks like the ideal way for me to hook video upload into filefield is to only define formatters/widgets, rather than a separate field type (that would solve this immediate issue). The problem here is that I need several additional db columns for tracking info not relevant to filefield. Any advice on how to proceed?

jhedstrom, yeah I'd definitely recommend making a new widget for video. Regarding storing additional data there's a couple routes that might work: 1) Use FileField Meta to store relevant file information (though you might be referring to things it doesn't provide). 2) Create your own database table just like FileField Meta and reference files by FID. 3) Review this patch for CCK that lets you add additional columns to CCK tables through hook_field_settings_alter() #417122: Allow drupal_alter() on Field and Widget Settings.

Thanks quicksketch, taking an approach similar to FileField Meta looks like it should work.

I am getting this problem as well

Drupal-6.11
CCK-6.x-2.2
FileField-6.x-3.0
ImageField-6.x-3.0-alpha4

Also, I have found that simply commenting out line 421:

form_error($element, t('Referencing to the file used in the %field field is not allowed.', array('%field' => $element['#title'])));

appears to overcome this problem, however this is obviously NOT the ideal solution.

Can anyone explain what the if statement that's failing is supposed to do:

if ($references['filefield'] == 0) {

majiga, that line is the line that prevents users from arbitrarily deleting files from your server (it's the cause of the security update that occurred in 3.0 RC1). Basically that line if ($references['filefield'] == 0) { is checking if any references to that file currently exist. If there are no references, then use of the file is not allowed.

So the problem goes a little deeper, we really want to know what's going wrong with the previous line:

$references = module_invoke('filefield', 'file_references', $file);

Since the file has already been saved into a File field, this line should be returning "1", assuming this is the only place where that file has been used. But for some reason it's returning 0.

Wait a minute! Re: majiga

ImageField-6.x-3.0-alpha4

You MUST be using ImageField 3.0 (not an alpha version) with FileField 3.0. ImageField and FileField must be updated together, since API changes that occurred between the alpha and beta versions of ImageField will prevent ImageField from working at all.

gah! I've updated and that's fixed it. thanks very much.

Updating to the latest imagefield module solves this issue
but "An image thumbnail was not able to be created." appears and no thumbnail appears on the edit form

sorry double post

I am also receiving this error with the Video Upload module:
"Referencing to the file used in the Video file field is not allowed."

Would it be possible to at least comment out the portion of filefield that throws this error so that I can maintain a few nodes on my site for the time being? What module file and lines? There are no other users to delete referenced videos, so there is no security threat in my situation.... and then this issue would be resolved with later updates beyond 3.0.

Modules:
Video Upload 6.x-1.x-dev (2009-May-19)
FileField 6.x-3.0

Thank you.
Patrick

The same problem:
filefield+image
after saving (without changes) content type with single image field

Edited.
Sorry, I mistaken.

I have reached the same problem while developing BitTorrent module. BitTorrent use FileField, like ImageField does. See: #523588: Error when editing: "Referencing to the file used in the field is not allowed."
Torrent field uses most of FileField functionality as is and overrides or extends some of it.
So, I would like to offer a patch which will solve this issue for such modules.
This patch will introduce a hook "hook_filefield_derivatives" which implementations should return array of field type names which uses FileField like Torrent field does.

Index: filefield.module
===================================================================
RCS file: /cvs/drupal/contributions/modules/filefield/filefield.module,v
retrieving revision 1.203
diff -u -r1.203 filefield.module
--- filefield.module	3 Jul 2009 20:53:07 -0000	1.203
+++ filefield.module	19 Jul 2009 09:02:28 -0000
@@ -849,6 +849,12 @@
  *   Optional. The node type to filter the list of fields.
  */
 function filefield_get_field_list($node_type = NULL, $field = NULL) {
+  static $filefield_derivatives;
+  
+  if (!isset($filefield_derivatives)) {
+    $filefield_derivatives = module_invoke_all('filefield_derivatives');
+  }
+  
   // Build the list of fields to be used for retrieval.
   if (isset($field)) {
     if (is_string($field)) {
@@ -866,7 +872,7 @@
 
   // Filter down the list just to file fields.
   foreach ($fields as $key => $field) {
-    if ($field['type'] != 'filefield') {
+    if (($field['type'] != 'filefield') && !in_array($field['type'], $filefield_derivatives)) {
       unset($fields[$key]);
     }
   }

Usage example:

/**
 * Implementation of hook_filefield_derivatives().
 */
function bt_torrent_filefield_derivatives() {
  return array('torrent');
}

P.S. Patch is against 3.1

I think this issue is going to end up in limbo, because I don't think it's necessarily a problem with FileField. Torrent module does *not* extend FileField the way other modules do (ImageField, ImageField Crop, Image FUpload). Other modules provide a specific widget for FileField, while Torrent module actually makes it's own field type entirely (not just a widget). I pulled out all the FileField-specific hooks specifically because I didn't want to have yet another layer of API (FAPI, CCK, then FileField? It's too much). So I won't be adding any hooks to FileField to accommodate for this problem. Torrent module should use the same approach as other modules and provide a widget-only.

I didn't want to have yet another layer of API (FAPI, CCK, then FileField? It's too much)

I think that it is not too much, because each layer of API will provide only its specific features. FAPI and CCK both cannot provide features that FileField can provide. For example, if I want to implement Field which will be able to upload files. Should I use FileField for this by overriding some parts of it? You think - not. Therefore I can either implement uploading functionality from scratch, or use widget. But widget doesn't give me the abilities that I need. So, only way I can implement it - implement all from scratch... This is not good...
If I mistake about widget abilities, please help me with my issue #524434: How can I insert/remove some info into my tables when a new file is uploaded/removed in a FileField using my own Widget type
Thanks.

Any chance of making this check optional?

Here's why:
-I use the Filefield Sources module to allow users to select previously uploaded files via IMCE.
-I also use IMCE with the WYSIWYG API module and TinyMCE to allow users to add previously uploaded image files to HTML, or upload new ones on the fly.
-With this check in place I cannot upload files through the IMCE interface and then add them to a Filefield later.

Also, I do not want files to be deleted from the server even if they are no longer referenced. I want them to stay in the file repository until they are manually deleted. To get around this issue I have a module implementing hook_file_references() and have it always report back that it has a reference. Since there is always a reference to any file, no file is ever deleted. Since no file is ever deleted, there's no need for this check.

I have commented out the following line in filefield_widget.inc (424 in the version I have):

form_error($element, t('Referencing to the file used in the %field field is not allowed.', array('%field' => $element['#title'])));

With that check disabled I am able to use IMCE as an all purpose file browser and upload files via Filefield or IMCE and reference them from both Filefields and HTML. It works great! I would rather not have to (remember to) dig for this line and comment it out every time I update Filefield though. If we could make this check optional, even if there is no UI for it (just a variable that can be set to disable it), that would be nice.

Another way this could work is if Filefield checked for ANY references to a file and not just it's own references. Not sure why this is a security issue anyway since Filefield will only delete files when there are no references from any module. Maybe I'm missing something.

Thanks,
Adam

I'm also getting this issue using filefield_sources and IMCE to allow staff to upload videos to nodes. They upload them via ftp then use IMCE to select the file. So I guess they have no reference in the db when they are added via IMCE.

Will comment :424 for the moment and hope to see this fixed one day. If you need help testing, i'll be following the thread.

I suppose we need something like 'no fid exists but the file is in one of the IMCE allowed directories'. Though obviously that's not a good solution

@samhassell: I wouldn't recommend doing that. If you're going to upload via FTP you should use some other means to import them into the Drupal files directory and table.

@adamo: yeah, i've just encountered more problems after commenting that. I'll look into using media_mover or something similar i think. thanks.

Getting this same error when attempting a node_import.

Basically I FTP's some documents to the Drupal install, then used node_import to import content that also pointed to the imported files. I had to delete the nodes (was doing some QA on complicated nodes) and apparently there are some remaining ghost entries that point to the files that I want to link and that is holding things up.

I assume that if I remove the entries from the files DB then I can go ahead and begin the import again...

Had same issue, upgraded ImageField from 3.0 alpha04 version to 3.1 and everything works now.

+subscribed

This patch from #27 will never be applied. BitTorrent module is the only module that requires this patch, despite the fact that many other modules all extend FileField (ImageField, ImageField Crop, Image FUpload, Media, etc.) There is no explanation for why BitTorrent module requires this patch, yet ever other module that extends FileField does not.

I upgraded the imagefield module to imagefield-6.x-3.2 and it works. Filefield is also in version 3.2.

Thanks.

I had previously been using the asset module and had an existing set of files uploaded to my files directory. I decided to switch to imagefield, but am receiving this error while updating my existing nodes (the ones with the asset field) when trying to submit a file existing previously on the file system using the file browser.

I'm going to second the request of adamo on comment #30 that this have an option to disable.

What I liked about asset module is that it allowed me to keep a repository of files in the system to choose from when needed, regardless of whether or not anything is referencing them.

Not only that, but users like me that are hoping for some kind of slightly more standardized Drupal/CCK method of handling file management will be able to switch over to image/filefield on a site with existing files that need to be transferred.

Thanks!

@justindodge, same here.

some here
UPDATE: yes, upgrading imagefield to 3.2 worked.

I am using imagefield 3.2 as well but i still got the same error, what am i missing?
Using the patch by #30 works for me, but maybe this isn't the best solution?

hy

i had the same problem using the brand new version of all modules.

I was importing story and images, with success!
So i deleted all story and images to import again, and then this problema started.

"Referencing to the file used in the Imagem da Capa field is not allowed. "

Then i took the database backup that i had (before of the first import i made).
Restoring to the backup version i could import the same CSV with sucess!

Strange isnt? Now i guess that the problem is related to some garbage that stay in database after deleting nodes.

Cheers,

Any chance of making this check optional?

Here's why:
-I use the Filefield Sources module to allow users to select previously uploaded files via IMCE.
-I also use IMCE with the WYSIWYG API module and TinyMCE to allow users to add previously uploaded image files to HTML, or upload new ones on the fly.
-With this check in place I cannot upload files through the IMCE interface and then add them to a Filefield later.

No, this check is absolutely mandatory. Without it, it allows users to delete ANY file uploaded to Drupal (not maintained by FileField):

- Upload something with IMCE.
- Select the file with FileField and save a new node.
- Delete the node, and then the file gets deleted with it.

No, this check is absolutely mandatory. Without it, it allows users to delete ANY file uploaded to Drupal (not maintained by FileField):

- Upload something with IMCE.
- Select the file with FileField and save a new node.
- Delete the node, and then the file gets deleted with it.

That only happens if you delete files that are no longer referenced (which is something I don't want to happen anyway).

A couple of ideas:
1) Perhaps the IMCE module should report a reference for any file it manages. If it were to do that, then you would not have to worry about IMCE files potentially getting deleted (since field_file_delete checks for any references to a file before deleting). Then perhaps this check could be removed and people would be able to use files they uploaded via IMCE with FileField?

2) Or perhaps you could make the deleting of files optional. And if that option was set to not delete files, then an option could become available to bypass the FileField reference check. Maybe call it something like "Allow files uploaded by other modules to be used in FileFields".

Basically I want to be able to use IMCE as a general purpose file manager and reference those files in different ways throughout the site (sometimes using them in FileFields, sometimes using them elsewhere). I don't want files to be deleted when they are no longer referenced. I want them to remain available in the file repository for later use. Currently I work around all this by implementing hook_file_references() in my own module, and I have it always report back a reference for any file. Since there is always a reference to every file, I don't have to worry about FileField deleting files that are managed by IMCE. So I can safely comment out this FileField reference check. The only problem is I have to remember to do that every time I update FileField, forever. :/ Do you see what I mean? Is there any way we can make this work?

1) Perhaps the IMCE module should report a reference for any file it manages.

I believe that any "managed" references (as provided by the FileField API) would make it so that the file would immediately be supported by FileField Sources as a valid file to use. FileField essentially make sure that some other module is responsible for the file before it can be used, unless it's a new file just uploaded (in which case FileField will claim the reference).

That would be great if it worked that way. It doesn't seem to be the case though. Here's the snippet in question:

        $references = module_invoke('filefield', 'file_references', $file);
        if ($references['filefield'] == 0) {
          form_error($element, t('Referencing to the file used in the %field field is not allowed.', array('%field' => $element['#title'])));
        }

It looks to me like it's only invoking the FileField module to check for file references. So, if a file isn't already used in a FileField, you can't add it to a FileField. If it did module_invoke_all to check for any file references from any module, I think that would solve the problem. People would be able to use files they uploaded by other means, and FileField would only delete files that were no longer referenced by anything else.

Then we could see about getting IMCE to implement hook_file_references properly, but in the meantime people who wanted to use IMCE as I described previously could implement hook_file_references in their own module like so:

function tweaks_file_references($file) {
  // Report a reference for every file.
  return array('tweaks' => 1);
}

Doing that, people would be able to use any file in a FileField and never have to worry about it being deleted.

That would be great if it worked that way. It doesn't seem to be the case though. Here's the snippet in question:

Ah right. I wonder why we don't do module_invoke_all() there. I suppose before FileField Sources it wasn't really possible to do referencing at all, so there wasn't any point in checking other modules.

Doing that, people would be able to use any file in a FileField and never have to worry about it being deleted.

Of course that also means that FileField wouldn't delete ANY files at all, even ones it did own.

Ah right. I wonder why we don't do module_invoke_all() there. I suppose before FileField Sources it wasn't really possible to do referencing at all, so there wasn't any point in checking other modules.

That's what I figured... So is there any reason not to have it do module_invoke_all()?

Of course that also means that FileField wouldn't delete ANY files at all, even ones it did own.

That's fine for me, since that's exactly the way I want it to work on my site. But for the general public, I think if we could get IMCE to implement hook_file_references() and get this check to use module_invoke_all(), everyone would be happy. People would be able to use files they uploaded via IMCE in FileFields, and those files wouldn't get deleted from the server when people remove them from the FileFields. Make sense?

Yep, that does make the most sense. Though this would require IMCE to maintain its own table of files it specifically has uploaded. Since it's never kept track of uploads in any way in the past, it has absolutely no way of knowing what files it should claim, meaning you'll still only be able to reference files that were uploaded AFTER this feature was added. In any case, another issue should be opened in the IMCE queue for that. The change to module_invoke_all() doesn't really seem appropriate to this issue either (though maybe it is). I've lost what this thread actually sets out to solve, so making a new issue for module_invoke_all() would help simplify the matter.

Sounds good to me. :) I created a new FileField issue for this:
#736354: Use module_invoke_all() to check file references in filefield_widget_validate().

I also created a IMCE issue to request implementation of hook_file_references():
#736380: Implement hook_file_references().

Thanks!

Probably someone already said that but as #52 I couldn´t find it:

I deleted all files (images) in the files db-table that "created" errors when importing nodes. After that everything went fine.
I guess that any update process of one of the related modules - as mentioned in some of the comments above - caused the deletion of those entries too?

Subscribing. For now I've taken a cue from others and commented out the line with the "form_error". (Line 422 in filefield_widget.inc - Filefield 6.x-3.2)

I can't stress this enough DO NOT DO WHAT IS SUGGESTED IN #53! It opens your site to devastating security problems.

Found something interesting that might help. I had the same error while saving a node with node.save method :

http://drupal.org/node/721336

Changing file status to 0 solved my problem.

sub

subscribe

For anybody who has a similar use case as Adamo and is looking to implement his solution in #47, you'll need to...

1. Create a small mini-module that implements hook_file_references. My *.module file looks like this:

function abol_imce_filefield_file_references($file) {
  return array('abol_imce_filefield' => 1);
}

2. Modify filefield/filefield_widget.inc in File Field v3.3, starting at line 438, as follows:

        //$references = module_invoke('filefield', 'file_references', $file);
        //if ($references['filefield'] == 0) {
        $references = module_invoke_all('file_references', $file);
        if (empty($references)) {

You can do this until you upgrade to IMCE 2.x (see #736380: Implement hook_file_references().) and #736354: Use module_invoke_all() to check file references in filefield_widget_validate(). is resolved. (At least that's what worked for me! :P)

This issue is fixed, since it's essentially a combination of an IMCE issue and a FileField issue, both of which have been fixed (as noted in #58).

I'm sorry to reopen this, but I think I'm not understanding how this was left off and I am having this problem.

I have:

Filefield 6.x-3.7
Filefield Sources 6.x-1.2
Imagefield 6.x-3.7
IMCE 6.x-2.0-rc1

So the newest versions of each of these modules. I was running older versions and just upgraded, which means that I was using IMCE before it had the file referencing built into it. Does this mean that I have to re-upload all the files in default/files to get FileField Sources to recognize them as being owned by IMCE so I can use them in a FileField?

I am also on v3.7 of both filefield and imagefield and have a similar problem. My problem occurs inside filefield_get_file_reference_count(). I inserted some debugging code into the function and found that content_data_info($field) returns this:

Array
(
[table] => content_field_image
[columns] => Array
(
)
)

So it composes a query that looks like this: "SELECT count() FROM content_field_image WHERE = 159" which of course throws an exception.

Please advise whether this is really part of the same issue or a new issue. If so I will create a new issue.

BTW - this is a site that I am upgrading from D5. Is it possible that one of the filefield update scripts went awry? Would that influence the decision as to whether this should be part of this issue or a new issue?

Does this mean that I have to re-upload all the files in default/files to get FileField Sources to recognize them as being owned by IMCE so I can use them in a FileField?

This is an old one, but this thread helped me. I've been trying to tidy up a site written by another company, it was using an old version of IMCE. I converted it all to use FileField and FileField Sources, upgraded IMCE to the latest version, then hit this problem.

All the existing files were unusable by Filefield sources IMCE selector. The fix for this is to convert all files in the files table to take IMCE ownership by running the following query:

insert into imce_files (fid) select fid from files

NOTE: This will override FileFields own handling. That is, if you delete a node that has a file associated to it, and that file isn't used anywhere else, the automatic cleaning of the file from the system won't happen. Not huge, but it might be an issue to some.

People who have files that have been updated by some other means (i.e FTP) will need to find a way of adding each file to the files table, with their size, type, path etc. It won't be the most complex script in the world. Then update the imce_files table to match. Then stop people uploading by any other means than IMCE/FileField.

I am also having the same problem with the following modules:

FileField 6.x-3.10
ImageField 6.x-3.10

The only workaround is to comment out the section that checks file references, i.e. "if (field_file_references($file) == 0)"

FileField 6.x-3.10
ImageField 6.x-3.10
IMCE 6.x-2.2
FileField Sources 6.x-1.4

Same problem here.

I was able to overcome this problem by using the pre-patched version of
sources/imce.inc in the Filefield Sources module
from http://drupal.org/node/877452#comment-4499144
to enable IMCE features set by IMCE profile

Suddenly ran across this in a very old D6 site and remarkably, the bug is still there, confirming #65 from way back in 2011. Using the latest versions of all modules, and significantly not using IMCE -- this was just with filefield and imagefield.

Marking this as won't fix after reading the above conversation and given the status of D6 these days. Although I understand the security implications of commenting out the lines mentioned in #53, this is a non-community site (only staff have access to log in, and they all have the same permissions) so the ability for other registered users to delete non-managed images is pretty limited.

And obviously, with any luck, this D6 site won't be around much longer.

Commenting out seemed to work for us on version 3.13 but it was line 470 of filefield_widget.inc

// form_error($element, t('Referencing to the file used in the %field field is not allowed.', array('%field' => $element['#title'])));