• Resolved nicollb

    (@nicollb)


    I have a rather large (subdirectory) multisite install that exhibits the following behavior:

    http://domain.name/site/files/xxxx/yy/file.jpg works just fine
    http://domain.name/site/wp-content/uploads/xxxx/file.jpg – Server Error (which it seems is an internal redirect loop — too many redirects AH000124 error)

    Now, I could live with, and probably understand the second URL giving a 404 or somesuch. I would prefer to set up some rules so that this URL would be morphed in to a valid one. (The sites were at one time a bunch of standalone installs, and there are external links bite us from time to time).

    How can I clear this up? Any ideas? BTW: the top level blog uses the wp-content path, while the subdirectory blogs use the /site/files/ path).

Viewing 15 replies - 1 through 15 (of 18 total)
  • BTW: the top level blog uses the wp-content path, while the subdirectory blogs use the /site/files/ path

    Yeah, that’s how Multisite is structured. You could do some database work and fix all the broken links. There’s a great Database Search & Replace script that you could use — http://interconnectit.com/products/search-and-replace-for-wordpress-databases/. I use this at least twice a week and it works like a charm. Make sure you have a backup of the database before doing anything and always do a dry run first and see what it would change.

    Thread Starter nicollb

    (@nicollb)

    Patrick — thanks. I did the search and replace earlier to get the internal links straightened out. It is a wonderfully useful tool.

    But, the server error still occurs when an external site hits an old, incorrectly formatted URL. I would think that there should be a way to avoid the 500 Server Errors. a 404 would be a better solution, IMHO.

    Well, your link structure changed from originally /yyyy/ to new setup of /yyyy/mm. Is that correct? So it’s impossible to rewrite this because it has no idea what month folder the file is now located in.

    If you did have them both organized by year and month then this would work, assuming it’s showing a 404 and not a loop error.

    RewriteRule ^/site/wp-content/uploads/(\d{4})/(\d{2})/(.*)$ /site/files/$1/$2/$3

    Not sure what’s causing the redirect loop. Got anything interesting in your .htaccess?

    Moderator Ipstenu (Mika Epstein)

    (@ipstenu)

    πŸ³οΈβ€πŸŒˆ Advisor and Activist

    Patrick’s got that one :but we can make it simpler!

    RewriteRule ^/site/wp-content/uploads/(.*)$ /site/files/$1

    You don’t need to check for Y/M if you’re just going to put it back in πŸ˜€

    Make sure that goes ABOVE the rules for WordPress!

    @ipstenu — but would that work? I don’t see how you can rewrite http://domain.name/site/wp-content/uploads/xxxx/file.jpg to http://domain.name/site/files/xxxx/yy/file.jpg because the “yy” is not present in the first link. Assuming that xxxx is like 2012 and yy is a month like 12.

    So then it would be, for example: http://domain.name/site/wp-content/uploads/2012/file.jpg to http://domain.name/site/files/2012/12/file.jpg — the rewrite engine doesn’t know in which month this file.jpg is in does it?

    Moderator Ipstenu (Mika Epstein)

    (@ipstenu)

    πŸ³οΈβ€πŸŒˆ Advisor and Activist

    You … can’t ever rewrite http://domain.name/site/wp-content/uploads/xxxx/file.jpg to http://domain.name/site/files/xxxx/yy/file.jpg

    You don’t know what yy is to start with, do you? So if you DO know it, and it’s in the old URL, then /site/wp-content/uploads/2012/12/file.jpg will still become /site/files/2012/12/file.jpg

    And if you don’t know it then /site/wp-content/uploads/2012/file.jpg becomes /site/files/2012/file.jpg

    You’re trying to check for yyyy/mm when we don;t have that at all in the old link, so the redirect will never be called. And in mine, if we DO have the yyyy/mm, it will still work πŸ™‚

    Great, I didn’t take into account that this setup may contain images in both the /2012/12/file.jpg and /2012/file.jpg setup. I guess somewhere along the way the paths were altered.

    Thread Starter nicollb

    (@nicollb)

    I don’t think that is the problem — it was always yyyy/mm — it’s just that it was /wp-content/uploads/ instead of /files/

    I can try the RewriteRule —

    the .htaccess is interesting because it contains rules for the WordPress multisite, and several Mediawiki sites that live inside the directory structure, and some redirects because of another major move. One of those rules probably is the problem, since I get a 404 on another multisite install on the same server.

    (How’s that for beginning to answer my own question?)

    Made a backup copy of my .htaccess and started deleting rules. Redirect seems to be healed. Now I just have to figure out how to do that needed redirect without breaking WordPress.

    At least I don’t get the 500 Error for this anymore.

    Thanks.

    Ah, OK — you accidently left out the /mm/ in the initial post πŸ™‚

    http://domain.name/site/files/xxxx/yy/file.jpg works just fine http://domain.name/site/wp-content/uploads/xxxx/file.jpg – Server Error (which it seems is an internal redirect loop — too many redirects AH000124 error)

    Not sure what’s causing the redirect loop. Got anything interesting in your .htaccess?

    Yeah, that’s starting to make sense now πŸ™‚ Make sure that anything Mediawiki added is specific only to MediaWiki stuff. Sometimes applications have very generalized rules.

    Now I just have to figure out how to do that needed redirect without breaking WordPress.

    Breaking WordPress or breaking MediaWiki?

    Thread Starter nicollb

    (@nicollb)

    nope — always had yyyy/mm/file.jpg as the path. the only alteration would be /wp-content/uploads/ to /files/

    I removed some other rules (non-WP) from the .htaccess and now I don’t necessarily rewrite the path correctly, but I don’t get the server error.

    Thread Starter nicollb

    (@nicollb)

    sorry I got into a hurry in the original post and got this off on the wrong foot.

    Breaking WordPress. I had some very inelegant rules to point to a new location for a 3 app (a Greenstone Install that changed domains. With them in place, I got the server error for the /wp-content/uploads/ path. With them removed I get a 404, which, while not perfect, is far better than a Server Error 500.

    Removed rules: (domain1.org is the WordPress domain that this whole thread deals with)

    # BEGIN Vincentiana
    RewriteEngine On
    RewriteCond %{HTTP_HOST} ^domain1.org$ [OR]
    RewriteCond %{HTTP_HOST} ^www.domain1.org$
    RewriteRule ^cgi\-bin\/library$ "http\:\/\/domain2\.org\/vincentiana\/cgi\-bin\/library\.cgi$1" [R=301,L]
    RewriteCond %{HTTP_HOST} ^domain1.org$ [OR]
    RewriteCond %{HTTP_HOST} ^www.domain1.org$
    RewriteRule ^gsdl\/collect\/?(.*)$ "http\:\/\/domain2\.org\/vincentiana\/collect\/$1" [R=301,L]
    RewriteCond %{HTTP_HOST} ^domain1.org$ [OR]
    RewriteCond %{HTTP_HOST} ^www.domain1.org$
    RewriteRule ^gsdl\/cgi-bin\/?(.*)$ "http\:\/\/domain2\.org\/vincentiana\/cgi-bin\/$1" [R=301,L]
    RewriteCond %{HTTP_HOST} ^domain1.org$ [OR]
    RewriteCond %{HTTP_HOST} ^www.domain1.org$
    RewriteRule ^gsdl\/$ "http\:\/\/domain2\.org\/vincentiana\/" [R=301,L]
    RewriteCond %{HTTP_HOST} ^domain1.org$ [OR]
    RewriteCond %{HTTP_HOST} ^www.domain1.org$
    RewriteRule ^vincentiana\/$ "http\:\/\/domain2\.org\/vincentiana\/" [R=301,L]
    Moderator Ipstenu (Mika Epstein)

    (@ipstenu)

    πŸ³οΈβ€πŸŒˆ Advisor and Activist

    So .. wait, we’re down to just the old image paths not directing?

    Awesome! Really THIS should be all you need for that πŸ™‚

    RewriteRule ^/site/wp-content/uploads/(.*)$ /site/files/$1

    As for the Vincentiana rules, let’s make this a little easier. One of the reasons this isn’t working is the [OR] rules don’t always run the way we think they should, so it’s longer, but easier, to break it apart.

    RewriteEngine On
    RewriteBase /
    
    # Redirect to non-WWW
    RewriteCond %{HTTP_HOST} ^www.domain.com$ [NC]
    RewriteRule ^(.*)$ http://domain.com/$1 [L,R=301]
    RewriteCond %{HTTP_HOST} ^www.domain1.com$ [NC]
    RewriteRule ^(.*)$ http://domain1.com/$1 [L,R=301]
    RewriteCond %{HTTP_HOST} ^www.domain2.com$ [NC]
    RewriteRule ^(.*)$ http://domain2.com/$1 [L,R=301]
    
    # Redirect CGI to vincentiana
    RewriteCond %{HTTP_HOST} ^domain1.org$
    RewriteRule ^cgi-bin/library$ http://domain2.org/vincentiana/cgi-bin/library.cgi$1 [R=301,L]
    
    # Redirect al the gsdl to Vincentiana
    RewriteCond %{HTTP_HOST} ^domain1.org$
    RewriteRule ^gsdl/(.*)$ http://domain2.org/vincentiana/$1
    
    # Redirect Vincentiana folder to domain2
    RewriteCond %{HTTP_HOST} ^domain1.org$
    RewriteRule ^vincentiana/(.*)$ http://domain2.org/vincentiana/$1 [R=301,L]

    You shoudn’t need those covered slashes and quotes, since we’re not actually dealing with complex rules now that we broke out the domain www stuff. We only have to consider ONE http host at a time πŸ™‚

    ( I get into this at http://halfelf.org/2012/htaccess-anarchy/ )

    Thread Starter nicollb

    (@nicollb)

    Ipstenu — Thanks.

    I put those rules in place.

    The redirects for Vincentiana work beautifully — and much easier to read.

    At this moment, I no longer get the 500 Server Error, but I don’t seem to get /site/wp-content/uploads/blahblahblah rewritten at /site/files/blahblahblah

    I’ll study it further

    Moderator Ipstenu (Mika Epstein)

    (@ipstenu)

    πŸ³οΈβ€πŸŒˆ Advisor and Activist

    but I don’t seem to get /site/wp-content/uploads/blahblahblah rewritten at /site/files/blahblahblah

    What happens? It just … sits at site?

    Do you have any WP caching?

    Thread Starter nicollb

    (@nicollb)

    I use WP-Supercache; I have cleared the cache(s);

    It simply does not rewrite the URL. It returns the url that was entered. And, now I am back to the Server Error 500 for the files.

    The other rules (domain1 –> domain2) are working. So, I’ve entered something incorrectly, I’m sure.

    It feels like one step forward, 2 steps back, right now. I’ll back off; check everything and go through one step at a time again.

Viewing 15 replies - 1 through 15 (of 18 total)
  • The topic ‘Multisite Internal Error for bad path to uploaded files’ is closed to new replies.