By cobbjbc on

I'm using 4.7 R2, and I'm having some trouble with attachments.

The first problem I had, I found a resolution for, which was the Greasemonkey Firefox plugin somehow screwing up the attachment in Drupal (would browse, Ok, then hit attach, progress dialogue, would show up in list, but then be gone after preview or submit). IE 7 works fine. Even with Greasemonkey uninstalled, I still can't edit my blog post and add another image.

Now, when I use IE or Firefox, I can't add more than 2 attachments - adding a 3rd drops the last one added from the list, and replaces it with the current one I'm trying to upload.

It also seems that anonymous users cannot see attachments on the blog post.

⋅ Categories: Drupal 4.7.x

Comments

stmind’s picture

stmind commented

Same here:

Files appear to attach fine, but are not actually placed in the files directory, nor is there any sign of attachments after pressing save.

In IE, files attach fine, however they are listed in reverse order on the resulting page.

cobbjbc’s picture

cobbjbc commented

I fixed the anonymous users bit, I just neglected to let them see attachments in the Drupal configuration. The other issues may still exist, I just upgraded to the actual 4.7 release from RC3, so I'll see if this is still happening.

libre fan’s picture

libre fan commented

I too confirm attachment is broken on the online website (drupal 4.7-- I have Linux and only Firefox installed (can't install Seamonkey for the moment) .Uploading takes place, the name of the file is displayed, complete with its path

On my local web site (off line, localhost), attachment seems to work all right on Firefox.

My extensions are the same as when I used Drupal 6.6: colorzilla, webdevelopment, quicknote, HTML Tidy, Dom Inspector and Talkback (I uninstalled MediaConnectivity but perhaps I ought to remove the files from Firefox profile dir).

I created a new files dir through the settings (file system); the dir was created automatically by Drupal; I increased the permissions for the sake of experiment to 777.

The upload module is on, the permissions for uploading and viewing uploaded are on for some users too, I checked input formats. Even the admin (user ID 1) fails to attache files

Is there another way to attach files? Could I upload the files I need to the files dir and somehow insert a link in the article? I'll try that.

Very inconvenient. Does someone have an idea as to what's happening here? :-\

Please help!
---
Libres-Ailé(e)s (Association for Linux and free software)

libre fan’s picture

libre fan commented

I found a helpful thread in the Drupal issue section : http://drupal.org/node/61841

Doing as budda says works fine. So I write my article, preview it, edit it and finally click on the browse button, and the on the submit button (no longer touch the Attach button) and it works! saved at last!

My host is 1&1 (as server problem was suggested).

cheers
---
Libres-Ailé(e)s (Association for Linux and free software)

stmind’s picture

stmind commented

My Windows machine with current Firefox still can't upload attachments. I have not tried the little workaround process mentioned above. I have only a few extensions installed, including web developer and adblock. IE 6 works fine on that machine.

My Ubuntu machine with Firefox 1.07 works ok. It also has webdeveloper installed.

Has a bug ticket been created yet? I think something's not right with the Ajax attachment stuff.

Nick Bell’s picture

Nick Bell commented

Back to drupal for 4.7, looks good but ...

I'm having the same problem with PHP 4.4.1 with FF 1.5.0.3 on Mac OS X 10.4.5.

Whilst the 'budda' workaround works, this clearly isn't ideal for the end-users - is there any hope?

Nick

gjaxson01’s picture

gjaxson01 commented

Being a newbi I am glad that someone besides me is having the same issue!

Garrett

ADLongwell’s picture

ADLongwell commented

I can confirm this problem as well. I'm using Drupal 4.7.0 and Firefox 1.5.0.3. I have the web developer toolbar installed in Firefox, and have a number of modules enabled in Drupal, including image and img_assist.

As others have summarized, I see the progress bar UI, and the attachment list appears when pressing the attachment button. Upon saving the node, all uploaded files disappear from the attachment list. I believe the Ajax upload is failing but producing no Javascript error and proceeding as if no error occurred.

gumdrop’s picture

gumdrop commented

However, I'm using 4.7.1 & Firefox 1.5.0.3
Works fine with IE v6.
This is the error.

Error: missing } after property list
Source File: http://www.mysite.com/misc/drupal.js
Line: 321, Column: 171
Source Code:
][1][description]\" id=\"edit-files-1-description\"  size=\"60\" value=\"2010-04.jpg\" class=\"form-text\" /\x3e\n \x3cdiv class=\"description\"\x3e\x3csmall\x3e<a class="linkification-ext" href="http://www.mysite.com/files/2010-04.jpg%5Cx3c/small%5Cx3
bentpenny’s picture

bentpenny commented

I just upgraded to 4.7.2 and use FF 1.5.0.4, Mac OS 10.4.6, PHP 5.1.2. Same problem.

holbech’s picture

holbech commented

Webdeveloper, greasemonkey and tons of stuff in firefox.

I could upload one file, but whenever i tried a ssecond it failed silently. Renamed the second file and it worked!!!! Whats that all about?

Anywho.
401.html worked fine
xhtml10.html could not be uploaded (the renamed version (x)html1.0.html uploaded just fine)

andrewfn’s picture

andrewfn commented

I am having the same problem. (Drupal 5.2 and both FF 2 and IE 7)
If I use the attach button, the upload fails around 30% of the time. It seems to depend on how busy/responsive the server is at the time. If I just submit without attaching then it always seems to work. I have experimented and it has nothing to do with the size or filename. The same file will sometimes upload and sometimes not.

I think that this is an AJAX bug, related to the asynchronous events. It is probably connected with:
http://drupal.org/node/152695 - Drupal session is not AJAX safe

The problem seems to be happening with a lot of people, but because it is asynchronous it is very hard to replicate reliably.