After browsing to choose image and clicking upload, error pops up "An HTTP error 0 occurred.
/portal/upload_element_js/form-64259b90f74492cfd6a7c7692e7c3fdb/rotor_item_node_form/rotor_image"

-Xyber.

Comments

linealternativa’s picture

the same thing is happened to me :-(

mrfelton’s picture

Do you have FCKEditor enabled by chance?

xyber’s picture

Nope, no fck editor. I'm using BUeditor

-Xyber.

mrfelton’s picture

I can only think that this is some kind of module conflict. Please can you disable all other contributed modules and confirm if the problem exists. If not, start enabling your modules again and find out where the conflict is.

ps. what browser/os are you using?

xyber’s picture

Done a clean drupal install with cck installed and filefield only enabled. Same result... Using FF. I think it is FF is not compatible with filefield. Thank you guys for your replies =) Anyone know how to make FF compatible?

-Xyber.

mrfelton’s picture

I don't think this is anything todo with filefield as Rotor Banner doesn't use it. It uses the upload_element module to provide the file upload facility. I seem to be unable to reproduce this problem. Perhaps you could try with the latest -dev version of upload_element?

mrfelton’s picture

Status: Active » Postponed (maintainer needs more info)

perhaps follow the advice of this person: http://drupal.org/node/297035#comment-1609590

mrfelton’s picture

3 sugestions:

Try using the ImageMagick Image toolkit instead of GD
If using ImageMagic, check it is installed correctly at admin/reports/status
Check your file upload limits at /admin/settings/uploads

edemus’s picture

subscribe

yogeshchaugule8’s picture

I was also having same problem,
Go to your File System
http://yoursite.com/admin/settings/file-system
check your Temporary directory (location and permission for directory)
like in my case my Temporary directory was 'C:\wamp\temp'
I changed it to '/tmp'
And it solved my problem, I can upload images now

crifi’s picture

This problem is maybe caused by a wrong configuration of $base_url and should be prevented by inserting a warning message to the requirements system. Therefore I created a new issue #1046682: Install/Update process fails if $base_url is set to a wrong URL. Please close this bug as a duplicate, if this solves your issue. Thanks!

gianfrasoft’s picture

I solved in a strange way!

The problem for me was in all site's upload widgets(!).

After a lot of javascript debug (I think this is merely a javascript issue) i changed line 93 of ahah.js 'cause I found a problem in interpreting the HTTP response (that is not in JSON format) and i solved the problem this way:

old code:

    complete: function(response, status) {
      if (status == 'error' || status == 'parsererror') {
        return ahah.error(response, ahah.url);
      }
    },
    dataType: 'json',
    type: 'POST'
  };

my code:

    complete: function(response, status) {
      if (status == 'error' || status == 'parsererror') {
        return ahah.error(response, ahah.url);
      }
    },
    dataType: 'html',    // <-- LOOK HERE.
    type: 'POST'
  };

If this solution corrects your problem, please give a feedback and let's try to understand why ahah.js acts this way...

Cheers.

2c’s picture

Thanks gianfrasoft,

That worked for me as well. I wonder if it will cause problems when the data is expected to be in json format?

japicoder’s picture

Hi gianfrasoft,

I checked your solution, but to solve my problem I commented the ahah.error return. This is my code:

    complete: function(response, status) {
      if (status == 'error' || status == 'parsererror') {
        //return ahah.error(response, ahah.url);
      }
    },
    dataType: 'json',
    type: 'POST'
  };

Obviously, I will get no errors from ahah in any way, including errors I want to see, but now for its ok, so I hope can be good to somebody else.

jg314’s picture

Commenting out the error and changing the dataType to html didn't work for me. Once I did that the page just sat and sat, never doing anything.

I have the problem in IE only.

msathesh’s picture

#12 worked for me.. Thanks very much..

mrfelton’s picture

So what, you are changing this in the Drupal core?

K-Max’s picture

Bad idea going with #14.

gianfrasoft’s picture

I agree with K-Max: bad idea going with #14.

smoothk’s picture

Hi all,

first: thank you gianfrasoft! Your solution REALLY helped.

On OpenAtrium beta 10 (most recent version as of this writing), the problem was present both on node uploads and comment uploads.

My solution was to modify AHAH.js exactly how you suggested.
This took care of the HTTP 0 error.

Things I also did:
1. I checked the file upload settings and changed them accordingly to my php.ini settings ->
upload_max_filesize and post_max_size

2. I also modified the max_execution_time and max_input_time to be sure to avoid timeouts

Aside from this, I kept having "Validation error..." messages quite randomly. It looked like a problem of a different nature.
Apparently I solved it by changing permission setting, allowing every single role I needed to upload files and view them.

Now I'm monitoring the software to see if everything keeps running ok.

Cheers!

gianfrasoft’s picture

Great! : )

bdichiara’s picture

None of these solved the problem for me. I get the error on Upload and Remove. My file is 4KB in size.

msathesh’s picture

@bdichiara this problem can also be linked to 'mod_security' and it is a good idea to talk to your web hosting provider. Pls look at this thread as well here http://drupal.org/node/659206 . My problem was actually the hosting provider's settings in Apache it seems. Read my comment in that link as well. Don't forget to read the last few comments because they will be the latest ones.

Jalandhar’s picture

HURRAY...I Got It....

I installed the jquery update module and its fixed.

Install the jquery update from:
http://drupal.org/project/jquery_update

bbruda’s picture

for me solution of the problem was exactly inversely like @Jalandhar , I disabled jquery_upadete and I don't have problem ;)