Image/Media Uploader problem, uploads to wp-admin folder

I am having this problem also after upgrading 4 different WP sites. The trouble seems to be only in Firefox when uploading an image from the “Write Post” page (post-new.php).

However, if I login and upload an image using IE, it works. And then, it works in Firefox. But if I clear the IE cookies, it no longer works in Firefox.

Here is my guess as to what is happing: Shockwave is using IE’s cookie store no matter if it is running in Firefox or IE. When using Firefox, Shockwave doesn’t have access to the admin_cookie in Firefox’s cookie store and thus does not send the cookie with the upload request.

Anyway, no real solution here, just more information.

To follow up, the SWFUpload object (and more precisely Macromedia Flash Player) has known issues with cookies:

https://swfupload.org/forum/generaldiscussion/383

Demonstrated by:
https://demo.swfupload.org/cookiebugdemo/

and another blog entry:
https://blog.ascaniocolonna.com/?p=23

That is interesting info ne0phyte.

I tried the flash uploader again on a PC. I cleared out the caches on all the browsers and tried it first in IE7, the file “crunched”, and seemed to upload fine, but it still uploaded the file to my wp-admin directory. mny results were the same in Firefox.

I can see how Flash problems would be causing a lot of the issues that other people are having. But my uploader seems to work the same, with or without Flash.

I think the problem is deeper, in the PHP, or database configs; since NetSol has had problems with both MySQL and PHP for me in the past.

I like the new media uploader, it is slick. But use-ability means a lot to me, my installs of WordPress are used by many different authors and editors. And they should be able to use any browser, without needing to install or upgrade Flash.

Besides, I like my Open Source software as “open” as possible. I accept that Flash is the best, most compatible container format out there for adding audio, video, and other multimedia to websites. I use it for media like this myself, at least until a more open option is a viable.

And I would accept them adding a Flash media player or players to WP by default to help you play the media you may be uploading to a site. But it is too bad that the developers used Flash for something that already had a more open, non-Flash solution.

Ah, but I am getting way off-topic!

Thanks for the input ne0phyte, after I can actually get files uploaded to my wp-content directory, I may have to revisit other issues like this with the Flash uploader.

Does any one know if the media uploader in the nightly version of WordPress might be functioning better?

Hi jleuze

I disabled the flash media uploader on my fresh installation, and still had the same problem uploading with the standard HTML single upload form. I think you were on the right track about this error being deeper in the PHP or database config.

By any chance, are your problems occuring on sites that have 2 subdomains? ie sub1.sub2.domain.com ?

That’s the only thing that I’ve been able to come up with that’s different on this new host that I’m having to use.

Yeah luxcious, I think the biggest issue with these media uploader problems is that there are actually 3 or 4 separate problems that people are trying to tackle simultaneously. And none of the WordPress gurus have had the opportunity to isolate these different bugs yet…

My guess is the PHP; or rather some web servers like NetSol that use stricter or non-standard PHP not handling the new code as they should. I have had this problem with running phpBB on a NetSol shared host, and I had to add a hack to phpBB in order for it to run on that host. This issue feels like that in a way.

But the database could be just as likely a culprit. I could see how something could get borked in there with 2.5 and 2.5.1 upgrades. Both of the installs that I am having a problem with are live production sites with existing databases.

I’ll admit that I have not tried doing a fully clean install on this host with a new database. It wouldn’t hurt me none to try this though. Is your site using a pre-existing database?

I’m afraid there are no subdomains involved in my installs. One is in the root of the domain, and the other one is in a subdirectory. But I do have another web server that the media uploader does work on. I would be willing to do a fresh install in a sub-subdomain and see if it breaks the uploader.

Every morning I hope to wake up to 2.5.2 ??

I created a sub-subdomain on my web server and did a fresh install, I was unable to break it, the media uploader worked just fine.

I tried doing a fresh install of 2.5.1 on the problem web host. A created a new database to use with this install. The media uploader problem is still present.

I was able to come up with a work around that seems to work though. In Setting/Miscellaneous, I left the upload path as the default, “wp-content/uploads”, which with the bug is actually “wp-admin/wp-content/uploads”.

I changes the full path to: https://www.MYSITE.com/wp-admin/wp-content/uploads

It seems like the uploader is using the upload path, but the full path is being used in the post editor, so if this full path reflects the true location, the URLs that are generated for the image and link tags will be correct.

I also deselected “Organize my uploads into month- and year-based folders”

I did a lot of tinkering, so I’m not sure on the exact details, but you’d probably have to tinker with chmod settings to get the images to display correctly.

This work-around is not one that I am enthusiastic about. I’d rather not have authors and editors anywhere near the wp-admin directory, and it sure seems like a potential security breach!

But I am desperate, if I had the time to get it done quickly, I’d move the domain to the host that works. But that is not an option at the moment.

I have writers that have to be able to upload images, so I will have to use this inelegant solution, until 2.5.2 comes out. I will report back, and post on the results of using this work-around.

I’ve got the same issue on one of my sites and have spent hours, possibly days, trying to get it to work. Hopefully someone will address it at some point.

Hi Kyle, what kind of hosting are you using? My functioning sites are on a VPS, but the broken ones are using shared hosting.

Did you try the work-around in my last post? I’m curious if this works for anyone else.

FYI, I tried the work-around on a second install that was having the same uploader issue. It worked with that install too, and I did not make any changes to any of the chmod settings.

Hi jleuze

I solved my problem, in a way, by using a different server with PHP5 with my same host. It’s not really a solution to the problem, but for me, it did show that it was only on a machine running PHP4. Are you able to use PHP5 with your host?

That’s interesting luxcious. My shared hosting package at Network Solutions is using PHP 4. I don’t think that I can get this changed, but they do offer VPS hosting, which might allow PHP 5 to be used.

But my installs of WordPress that are working are on a server from a different web host, that is also PHP 4. So maybe it is only a certain version of PHP 4 that is giving these problems.

I think it has more to do with how the host has configured PHP 4. The web host that works for me is using a standard install of PHP as far as I know, I am able to control settings like safe mode.

However I know for sure that Network Solutions uses an install of PHP that is either non-standard, or has excessive security features enabled. I have had problems installing phpBB3 on this same webhost, because of the way that they have PHP configured. It is a known issue in the phpBB community, and a hack is required for this forum to be installed on a NetSol server.

So, my guess is that your webhost has the version of PHP 5 that it offers configured in a slightly different way than they have PHP 4 configured. I bet if they had a vannila install of PHP 4, or tweaked the existing install slightly, WordPress would work correctly.

By the way, I do have a ticket in on this general problem. But Otto42 was able to narrow it down quite a bit, and was kind enough to submit his findings to another ticket dealing with that specific issue.

So maybe one of the talented trac folks can come up with an official fix.

OK, so here is what I finally did to fix _my_ upload problems. Whilst browsing the wp_options table for nefarious values, I found that the value for active_plugins and inactive_plugins looked hinky. So I cleared out the option value for both records and hit the site again. I had to re-activate some plugins – but – afterward the uploader magically started working again!

So, to summarize, David Mihm MIHMORANDUM NO. 92 has some good WordPress upgrade tips:

https://www.davidmihm.com/blog/design/wordpress-upgrade-tips/

Most importantly, before upgrading WP, remove the plugins, go through the upgrade process, put the plugins back, activate, rinse, repeat.

ne0phyte, that’s great that you’ve got your problems solved.

It looks like the problem I am having, uploading to the wrong path, is a bug in the PHP code itself. Or at least part of the code doesn’t play nice with some obscure set up of PHP that some web hosts use!

I have opened a ticket for this issues, and there is anther ticket that deals with this issue as well, so hopefully the Trac folks can find a fix to help out those of us with this particular problem.

But I do have another webhost that I can switch to that 2.5.1 does work fully on.