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)?

I upgraded from 3.0-alpha7. The problem affects both newly created nodes (after the upgrade) and nodes created eralier.

OT: I received the famous http 0 issue and during research I found the release of the new version so I upgraded. Http 0 Wasnt solved but I later found out the cause: the image was too large for memory to create thumbnail. Made it smaller dimensions and it 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 put the site in maintenance mode. Cleared out the whole folder then uploaded the new package. Ran update.php then put the site online again.

The images for old and new content show up very well in node teasers and full page views. It's the "edit" only that gives this error message.

What's missing now also is the thumbnail in the form field for image fields in CCK nodes.

I upgraded imagefield to 6.x-3.0 and this solved the problem

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:

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.

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):

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.