Summary: Attempted file attachments of pdf files (to blog node) fail with message The selected file can not be attached to this post, because it is only possible to attach files with the following extensions: jpg jpeg gif png txt html doc xls pdf ppt pps.

I've tried a bunch of fixes and have narrowed the problem down a bit in the code, but I'm in way over my head on this one. Any help to confirm this as a bug or to shed some light on what's going on would be great!

I'm on Win32/Apache/PHP5. What I've seen so far:

- The same kind of file upload works flawlessly for the admin user (i.e. uid = 1) ==> seems to suggest it's not an apache/windows/php permissions issue (?)

- The problem doesn't go away when I assign all permissions to the non-admin user ==> seems to suggest it's not a drupal permissions issue

- I can see the temp file created in the php file upload directory in either case. (Also, I'm using the default drupal 'files' directory)

- Seems like the way the module works is _upload_validate() is called once for each Attach, and then again on Preview or Submit... The first of these times (i.e. the Attach click) the function completes successfully. The second time through, when Preview or Submit is pressed, one of the validation checks fails and the error message is posted.

That second time through, it looks like the code expects there to be a file object that isn't properly there...

function _upload_validate(&$node) {
  // Accumulator for disk space quotas.
  $filesize = 0;

  // Check if node->files exists, and if it contains something.
  if (is_array($node->files)) {

    // Update existing files with form data.
    foreach($node->files as $fid => $file) {

Well, at this point in the code right before the failure, count($node->files) is 1, which seems fine. But if I look at $file->filename here it's empty.

So, when the extension is checked later on...

            if (!preg_match($regex, $file->filename)) {
              $error['extension']++;
            }

it fails every time. This causes the error message to get kicked out:


          if ($error['extension'] == count($user->roles) && $user->uid != 1) {
            form_set_error('upload', t('The selected file %name can not be attached to this post, because it is only possible to attach files with the following extensions: %files-allowed.', array('%name' => theme('placeholder', $file->filename), '%files-allowed' => theme('placeholder', $extensions))));
          }

It certainly seems like something's happening so that the node's file list is getting messed up or incorrectly set somewhere, but I haven't been able to track anything down.

Any ideas???

CommentFileSizeAuthor
#8 54298_0.patch640 bytesdopry
#6 54298.patch747 bytesdopry
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

JHeffner’s picture

Seeing the same issue on WIN32 IIS/PHP4. This seemed to have been introduced with beta6, as it works fine on beta5 as discussed at http://drupal.org/node/54179 . We also noticed that with beta5 (fine in beta4) a bug was introduced that clears the "list" checkbox when submitting posts with attachments. You then have to edit the post to re-check the "list" box. I'm not sure if this is related or not, but worth mentioning.

rar’s picture

samc said:

Well, at this point in the code right before the failure, count($node->files) is 1, which seems fine. But if I look at $file->filename here it's empty.

Righto - it looks like $file->filename is only set when you have something like
<input type="file" ....

But that only happens once - when upload.js is called. Uploading files is a two step process
1) Attach, 2) Submit

When you hit the attach button (1) there is input type = "file" but after the javascript does its thing that "input type" is no longer there. Now right after stage 2 (just hit the submit button), if we look at print_r($_POST) I get (test upload file=header.gif)

Array(
    [edit] => Array
        (
            [title] => Testing 1
            [body] => asdfasdf asdf a
            [format] => 1
            [form_id] => page_node_form
            [log] => 
            [name] => rar
            [date] => 2006-03-15 23:01:46 +0000
            [status] => 1
            [promote] => 1
            [comment] => 2
            [menu] => Array
                (
                    [title] => 
                    [description] => 
                    [pid] => 1
                    [path] => 
                    [weight] => 0
                    [mid] => 0
                    [type] => 86
                )

            [files] => Array
                (
                    [upload_0] => Array
                        (
                            [list] => 1
                            [description] => header.gif
                        )

                )

            [fileop] => http://www.yoursitenamehere.org/?q=upload/js
            [vid] => 1
        )

    [op] => Submit
)

So it looks like we can use

if (!preg_match($regex, $file->filename)) {

for step 1 - attach. But that code breaks on step 2, submit since $file->filename will be empty.

ScarabMonkey’s picture

I have the same issue on RedHat server etc etc...

It is interesting that when I try this, by choosing attach (which appears to work) then pressing submit... it highlights the 'Attach new file:' box rather than the file it is failing on.

Perhaps it is complaining that ' ' contains no extension? i.e. it is checking the empty box as if it has a filename inside.

Hope this helps someone!

samc’s picture

Title: Serious wierdness with upload.modue » Serious wierdness with upload.modue (only user = 1 can upload files)
Priority: Normal » Critical

JHeffner said:

We also noticed that with beta5 (fine in beta4) a bug was introduced that clears the "list" checkbox when submitting posts with attachments. You then have to edit the post to re-check the "list" box. I'm not sure if this is related or not, but worth mentioning.

It appears to be related to the patch that fixed the list box issue. Details here: http://drupal.org/node/42358. That patch, which was committed with version 1.79 of upload.module, introduced some major changes to the module and this issue appears to be a side effect.

I've confirmed that reverting to v1.78 of upload.module does fix this issue, suggesting perhaps that the problem is isolated to upload.module, and not due to changes in file.inc, etc.

I'm finding the code in upload.module a bit mind bending, so I'm giving up on this one. IMO this issue renders upload.module unusable, thus I'm escalating this to critical.

I'll also email the developer of the aforementioned patch, just to make sure he's aware of this issue. Hopefully he can work on a fix.

Thanks all!

webchick’s picture

Title: Serious wierdness with upload.modue (only user = 1 can upload files) » Only user = 1 can upload files

more descriptive title.

dopry’s picture

FileSize
747 bytes

This is a one liner....
The for some reason newly uploaded files com through as objects, and old files become arrays. There is a cast to array hidden in here some where.. Maybe in the session save/load.

Eitherway an explicit cast as object for the file array does the job just fine.

killes@www.drop.org’s picture

Status: Active » Needs work

I'd really like the spurious cast to be fixed instead of the symptom.

dopry’s picture

FileSize
640 bytes

Hmm I figured out it wasn so spurios... This function is called with both the $node object and some times with that $edit/form_values array.

Here is a patch w/o the misleading comment.

samc’s picture

Just wanted to confirm that this patch does fix the issue for me.

Thanks!!!

dopry’s picture

Status: Needs work » Needs review

After a quick discussion on IRC I think the consensus was that after 4.7 we deal with deciding to use just arrays or just objects. In the mean time test this out. Or commit it.

rar’s picture

This patch fixed the issue for me also

Stefan Nagtegaal’s picture

Status: Needs review » Reviewed & tested by the community

I did test this patch on 4 of my sites and can confirm that it works as advertised.

Setting status RTBC..

killes@www.drop.org’s picture

The patch might fix things, but I am still not happy with it. question: Will $node->files be always of the same form (ie an array?) at this place? $file isn't returned anywhere and we can just change the rest of the function.

dopry’s picture

No, node->files will not always be the same form. A new file upload is returned form file_check_upload as a object. So if you use the JS upload, the file is an object when passed to _upload_validate the first time. I could probably get away with the cast in upload_prepare but I'm afraid of regressions from other core or contrib
modules this late in the 4.7 release cycle. I just did the basics with the last update of upload module. I don't want to go any further changing datatypes or function returns until head is unfrozen.

killes@www.drop.org’s picture

Status: Reviewed & tested by the community » Fixed

I guess there was really no choice. We should try to fix the array vs object issue once and for all.

JHeffner’s picture

Still not fixed. Uploads still do not work in the latest cvs version with patches described in this post. They work fine in drupal beta5 though.

tfejos’s picture

Status: Fixed » Active

I have the same problem.
I'm not uid 1. I have tried to upload several files with latest HEAD but it did not work.

dopry’s picture

What errors did you get. Is anyone else experiencing this with a current head.

samc’s picture

I just created a new drupal instance from HEAD and upload is working fine.

dopry’s picture

Assigned: Unassigned » dopry
Status: Active » Fixed

Uploads are working fine from head for me as well... closing...

If you are going to reopen a closed issue please post details about the error you are recieving.
Make sure your checkout, or at least the files you are testing are clean. I normally

rm <suspect file>
cvs update -dP
JHeffner’s picture

I found out that the relative paths no longer work for writing to the temp folder. Once I put in the full system path to the folder it worked fine. This could still be a bug depending if you want relative paths to still work beyond beta5 for the temp folder.

I apologize for the lack of information. I wasn't getting an error messages at all.

I found another issue I will search for in the open tickets. If you preview a post it will delete your file in your temp folder and not attach the file on submit. Thanks for your help.

tfejos’s picture

I have tested t oset the path to absolute it didnot helped.

I've got a massage:
"The selected file Japanese_Kanji.pdf can not be attached to this post, because the disk quota of 1 MB has been reached."

samc’s picture

tfejos said:

I've got a massage:
"The selected file Japanese_Kanji.pdf can not be attached to this post, because the disk quota of 1 MB has been reached."

The maximum file size is an admin setting of the upload module. Take care to note that the value is independently set for each user role. Try increasing this value for the appropriate role or choosing a smaller file and see if that helps.

JHeffner’s picture

All fixed now. The additional errors were caused by the flexinode module. It took me awhile to track down. I was using the events package.

tfejos’s picture

Increasing values at /admin/settings/upload helped me.

killes@www.drop.org’s picture

Status: Fixed » Closed (fixed)