New 3.0 install, images not working in subsites

You realize you’re asking WordPress to include a fix that is controlled on the server level? It can’t, really.

The image URL rewriting works based on .htaccess and mod_rewrite actually reading that file. if it can’t or won’t that is inherently a server issue, not a WordPress one.

I’ve tried all the possible solutions I can find online (except editing httpd.conf) –

And that’s the fix.

tell your webhost you made changes to the htaccess file and they are not sticking or being read.

Hi,

No, I’m not asking them for anything that they can’t do.

What I’m asking WordPress is to provide a solution or workaround for it without involving server level settings which, as you said, they have no control of.

One obviously crude workaround is the ability to remove the image path entirely and just absolute-link the images directly to wp-include/blogs.dir/X/files.

(I’ve tried doing this, by the way, in the settings of the subsite by editing the URL paths, it didn’t work. So this needs a deeper level of tweaking that WordPress will be able to do.)

Host the images on a CDN with a plugin. That’s also an option.

So, we’ve launched and are at https://www.rappahannock.edu. I thought the problem had magically fixed itself last week but it seems only half fixed. On the server I’ve got two instances of 3.0.1 multisite running now. One, for our main site and two, for our employee directory. I had some issues with the directory and and to recreate that database after we went live and the image rewriting works there, ex. https://www.rappahannock.edu/directory/mgreene but on our main site the images are still broken ex. https://www.rappahannock.edu/distancelearning

Both sites are running off the same http.conf file and the active rewrite rule is RewriteRule ^([_0-9a-zA-Z-]+/)?files/(.+) wp-includes/ms-files.php?file=$2 [L]

I really don’t want to consider this being a database issue but could that be it?

I really don’t want to consider this being a database issue but could that be it?

I doubt it. The db only stores the URL.

The .htaccess file does all the magic, if Apache is configured to let it do so.

And yes, it is quite likely (the way apache works) that one account is fine and the other is not. You can specify things to that degree. webhosts upgrading Apache, for instance, can make it magically stop or start working.

Try uploading the full site again using “Auto” as the Transfer Type. My guess is that you have your FTP Program set to “ASCII” since you have been messing with the .htaccess

Uploading a full site using ASCII will make all the images mess up on a WordPress install.

Hopefully that helps!

Mike

He’s using the internal media uploader, not ftp.

I did try playing around with .htaccess upload. Since I’m editing on my Mac and uploading to the windows server none of the line breaks were keeping. But, even when I created the .htaccess file on the windows server itself it didn’t change anything.

… becasue you need a web.config file on a windows server (as far as I know. I don’t do windows)

Andrea,

I’m having the same issue with images. I have the .htaccess file set up properly, but do not have access to the conf file. I’m working with IX Webhosting. Have you heard whether or not they support 3.1? You mentioned that you had talked to several of the hosting companies – hoping they are one.

Nope, haven’t worked with them before.

have you talked to their support? really, for a decent web host this is an easy fix.

Andrea – they in fact do have it set up in the conf file. They have AllowOverride All set. Could it be something in the .htaccess file? I’ve scoured everywhere and cannot figure this out. Is there a sample file somewhere that I can check mine against?

We’ve posted the htaccess files for both subfolder & subdomains here in the forums.

also – post a link to a blog with the borked images. preferably in a new thread. ??

I’ve run into this problem (on Apache on Windows Server.) The images are getting served to the client browser (you can see the response headers in Firebug, and if you temporarily comment out the Content-Type header in ms-files.php, you can “see” the image data itself), it’s just they are corrupted when they get there. So, in my case, it’s not an htaccess problem.

I solved it by adding the line ob_clean() – immediately after the last line on ms-files.php, i.e. above the readfile($file)

// If we made it this far, just serve the file
ob_clean();
readfile( $file );
?>

This clears out any whitespace or other junk that is causing the PNG to get garbled. See also https://www.php.net/manual/en/function.ob-clean.php

Once fixed, you’ll need to get the “clean” copy of the images – not straightforward as, as far as the browser is concerned, its cached copy of the corrupted file is “good” and also not updated – so load up in a different browser or do a force refresh.

Just to update – the above workaround worked (and was necessary in the first place) because I had managed to somehow add an additional newline character after the closing ?> in wp-config.php.

The ob_clean() statement cleaned this up for images, but my RSS feed was still not validating, because the newline character, coming from wp-config.php was showing up on the first line, with the XML opening line on the second line, which is invalid. Deleting the newline character fixed both problems and means ob_clean() was no longer necessary.