What is it putting in it’s place?
ipstenu, in it’s place, this appears:
http://cityname.mydomain.com/files/2011/07/filename.jpg
I created two new domains, and when they were first created they had these settings:
Upload Path: wp-content/blogs.dir/4/files
Upload URL Path: (blank)
Fileupload URL: http://cityname.mydomain.com/files
But when I change these settings, it just disregards them and stores the files in the wp-content/blogs.dir/4/files directory, and uses the old fileupload URL as the link to the file.
I’m poking a bit around on my end. It shouldn’t be ignoring the changes.
Just an update: I was wondering if my database might be corrupted, so I created a test database with basically nothing in it except what installs with WordPress. I was able to change the settings on the main site just fine, but on the subdomains, I still have the same issue. No matter what I place in the Upload Path, Upload Url Path & Fileupload Url, WordPress defaults to the original settings, creates the blogs.dir directory, uploads the files there, and gives the File URL a name of http://subdoman.mydomain.com/files/2011/07/filename.jpg.
Now this is getting really weird.
Another update: I can change the value to store uploads in month/year folders, but nothing else. Even trying to use wp-content/test doesn’t work.
Thanks to anyone who can chime in to help or have had similar issues.
I’m having an identical problem – on our multisite installation, WordPress ignores the values I’ve set for Upload Path, Upload URL Path and Fileupload Url and uses its defaults.
Did you end up resolving the issue?
Yes, I forgot to update it here.
If you just comment out only one line in wp-includes/ms-settings.php. the last one which calls for ms_upload_constants(). if you open ms-default-constants.php you will see that function defining upload constants. after commenting that line it looks to be working like I wanted it.
I don’t know why someone hasn’t found the solution and posted it sooner, because it seems like something that a lot of people would be dealing with. Oh well, hope this helps you too. 🙂
because it’s a core hack, which is not recommended. 😉
You know we LOVE core hacks! 😉
But this really seems more like an oversight than a hack, because here’s my question: what’s the point of having the fields there to edit, if you can’t, in fact, edit them??
They are used in signle sites, so you need to edit them there. but in multiple sites in a network, can jack things up. so they turned ’em off. because you need to get a global to do ti for all the sites in the wp-config file.
Cooliojones – works perfectly.
Seems like a bug to me! I’ve filed a ticket in trac … http://core.trac.ww.wp.xz.cn/ticket/18272.
