New 3.0 install, images not working in subsites

Yes, I have seen the exact same issue, and as noted in my earlier answers, it *is* the htaccess file not being read properly.

You really do need to add AllowOverride FileInfo Options to Apache;s httpd.conf file. If you can’t do that, then your webhost support has to fix it.

I’ve added the AllowOverride FileInfo Options all over the place in my httpd.conf file to no avail. I tried putting a bad line in my .htaccess to see if it what would happen and that gave me a 500 error in the browser. Here are the following directives I’ve currently got added in my httpd.conf file

<Directory />
Options All
AllowOverride FileInfo Options
Order deny,all
Deny from all
</Directory>

That’s normally Options none AllowOverride none but I changed it just to see if it would have an effect

<Directory "C:/Server/www">
Options All
AllowOverride FileInfo Options
Order allow,deny
Allow from all
</Directory>

<Directory "^([_0-9a-zA-Z-]+/)?files/(.+)">
AllowOverride FileInfo Options
</Directory>

That last one I just put in to see what would happen, but alas still no images. I’ve tried using <Directory /Server/www> as well to see if maybe Apache didn’t like the windows-ish syntax but that didn’t change anything either.

then try AllowOverride All in those places.

Still no go… does anyone know of a way to disable the url rewriting and just allow the browser to use the original URL. I’m at the point where I need a fix ASAP and my users need to be able to upload while I’m working on the real reason this isn’t working.

I’ve seen the bad file error on both Apache on Windows and Apache on Linux but like you had no issue when browsing direct to the file.

Still working on that one – the htaccess messing about only fixed it for the home blog, not the subdomain blogs, so still stumped on it – and moving closer and closer to rolling back to 2.9.2 so I can get my sites working again. If I have to do that, I’ll wait for WP 4.0 before “upgrading” to WP 3.1 – basically following what I do with Microsoft products (staying well behind the bleeding edge).

Re: using rappawotsit as the hostname – if you’re running Apache on a Windows Server box, remember to knock out ISA Server before starting Apache – they cannot be run simultaneously. On an XP/Vista box, knock out Personal Web Server for the same reason.

In my bug report in trac – https://core.trac.www.ads-software.com/ticket/14295 – Ryan has stated he sees no bug in these issues, and nacin has stated there’s no need to do what WP3.0 upgrade forces you to do (change blogs-dir.php for ms-blogs.php) so there’s a disconnect between core devs thinking, and what actually got rolled out in WP 3.0

Gaz

Gaz,

Nice to know I’m not the only one having issues. I don’t have ISA or IIS installed on this server so that shouldn’t be a problem. Hopefully a fix will arrive in the near future, rolling back to 2.9.2 would be my absolute last option, I’m using many of the 3.0 features in this install. I wish you luck solving your wp problems.

Guys, it’s entirely due to your server setup. This is not a bug, there will not be a “fix” to wait for in the code.

Unless they entirely redo the files uploads area, which I can’t see happening.

Either hire someone to fix it for you or look into using an uploads offloading plugin.

What happened for me is that my subfolder was named WordPress. The upgrade renamed it to Word_p_ress (note the lowercase p – the _). Which is why my images are not showing up as they are all expecting the uppercase P.

I hope this helps.

Andrea – respect to your knowledge and expertise and everything – but it doesn’t take more than a minute or two of trawling through the forums to know that hundreds, if not thousands of threads around this same topic have been launched since WP 3.0 rolled out.

What you are saying is rather like “it’s not WP that’s wrong, it’s the entire planet’s hosting industry that’s wrong” – to me that’s a bug. Either in the code or in WP’s belief as to how important they are in the overall global IT industry.

They have coded something that is not working on 100’s on hosting services, and they expect the entire industry to change to how WP believes the world should be run – that’s more than a bug, but I don’t want to use the correct word to describe that sort of behaviour (it’s against forum rules).

As I posted in trac – if it looks like a cow, smells like a cow, and moos like a cow, then it probably is a cow.

Just because there’s an option in httpd.conf or alias.conf, that 99% of the hosting industry leave turned off, is no reason for WP to force everyone to turn it on. My belief is that the hosting industry are right on this occasion for blaming the problem on WP, and as a webmaster, developer, and user, I do too.

there are not hundreds and thousands of threads. I have personally helped out quite a fair number of people in those threads, and with this thread being the exception – every one of them was solved.

I have also been working with a fair number of the most popular hosts out there since 3.0 came out and have not been able to reproduce it. If there are “hundreds” of hosts, can you send me a list to see the ones I’ve missed?

If it IS a bug, then it’s reproducible.

99% of shared hosts do not want to support multisite or WPMU. That’s their choice. Don’t blame WP if some of them deliberately cripple installs (which I have personally seen some do).

Many, MANY hosts have automated upgraded to their OSes that often wipe out tweaks like this when they upgrade. Seen it, lived it, had to fix it.

If you are running a large number of sites within WordPress, you *need* to start learning sysadmin stuff. Blaming WP hurts you and your users.

Hi Andrea – sorry for the frustration showing through – this has been a godawful week with regard to failed WP upgrades and installs – never known a week like it.

The point about OS upgrades losing settings tweaks I can relate to and understand … if the hosts in question had upgraded, which none of the ones I’m working with have done (this week).

With one exception, I’ve not seen the install crippling you refer to but would not be surprised if it happens – there are some very ignorant hosting owners out there – ignorant in relation to how most people use WPMU/MS and how they could throttle sub-blog growth without disabling the function entirely (e.g. setting max subdomains per top domain in WHM / cPanel / Plesk etc – easy enough to do – even I can figure that one out).

You contradicted yourself though – 99% of shared hosts .. v .. if there are hundreds of hosts – I know you know just how big the hosting industry is, therefore your two comments are self cancelling.

A solution to all this is to change how WP handles subdomains – hosts that refuse to allow wildcard subdomains, often do allow manual subdomain creation, therefore rework the subdomain creation code in WP to work with cPanel, Plesk etc to auto-insert a “manual” subdomain creation to the subdomain list for DNS. Do away with the virtual subdomain system entirely. It’s an option – not an easy one I agree, but probably the best one going forward and needs to hook into the control panel API as either a module or plugin for it. But would the hosts then block that too?

greene.md – sorry i took the topic off track for a while there, but I have been rooting around on this topic

I did fix it on one domain (forgetting entirely to come and tell you how) and to the best of my memory … in admin – go to SuperAdmin – Sites and hover the mouse over you sites in turn clicking on edit – check the various urls and paths in the left hand column – iirc there were two or three of them banjaxed on my install (and @andrea – it was WP that created and therefore banjaxed them :-p )

Wish I’d remembered to come back and post immediately, but clean forgot in the excitement of getting it fixed.

Gaz

WP is wonderful when it works, and a goldmine in the fact that with limited coding skills we can usually get a site up for a few hundred dollars and some sweat equity vs thousands to hire a pro.

In my case, as with many others, images are being uploaded and any ‘real’ file path serves up images. i.e. https://jethro.foundersbench.org/wp-content/blogs.dir/2/files/2010/08/oldglory-420×260.jpg works fine, but the WP generated file path does not: https://jethro.foundersbench.org/files/2010/08/oldglory-420×260.jpg

In desperation, I just moved to a new VPS at Media Temple. My computer guy set up WPMU for me in a new test domain on the new VPS and after testing for about a month, we set up another brand new domain and loaded 3.0.1 fresh out of the box only to have images break (again) on sub domains as soon as we converted to multi-site.

I read these forums for days trying EVERYTHING without success until finally my programmer gave me several hours of trouble shooting. I asked him if he was sure Apache was reading .htaccess and he said, that was the first thing he checked. It is being read and the files are redirecting correctly to the file processing script but the process crashes at some point after that. He is not a WP programmer and has no interest in pouring over unfamiliar code, but he said this problem will persist until someone involved in the project recognizes there IS a WP problem here.

WP may be a victim of its own success since it attracts so many newbies, but as long as all those unresolved Google comments linger (yep, hundreds conservatively), it will reflect badly on WP without regard to whether it is a WP problem or a diabolical conspiracy of the world and its idiots.

@gazouteast you can see you’re not the only one letting a little frustration escape into the ether! ?? Can you provide an example of the links that were banjaxed, and how they were malformed? Thanks much in advance for your help if you can!

That image URL rewriting is how it’s supposed to work, and you really have to make sure you’ve got the *right* htaccess stuff in there.

I can confirm working network installs on media temple on various levels of accounts. (thanks clients)

Yep, WP makes it easy, but running a network itself has always been harder because of the skill set involved. that’s why it’s not a one-click switch in the backend.

Hi.

New here. ??

I’m having the same problem with WPv3.

I’ve tried all the possible solutions I can find online (except editing httpd.conf) — all failed to work.

I, myself, have no direct access to Apache’s httpd.conf, hence, will need to do an extra chore of contacting my webhost support just to edit the the conf file. And even that may not guarantee a surefire solution (according to threads here in the forum).

This is unfortunate, since I’m sure there are many more people in the same boat as I am (have no direct access to the Apache conf file).

WPv3 should create a patch (or at least a holler a workaround) for this (versions below 3 worked fine [or so I read] without the need to tinker with Apache conf file).

If somebody has a solution sans conf file editing, do post details and would really be very much appreciated by lots of people like me. ??

TIA.