Forums

[resolved] Inconsistent URL rewriting after server migration (9 posts)

  1. hunsford
    Member
    Posted 1 year ago #

    We have migrated to a new VPS with a new host. Since then, we've been seeing problems with URL rewrites.

    It's a subdirectory installation, so child sites look like:

    http://domain.com/name/

    The first sign of problems was that a URL could not be rewritten without the trailing slash. http://domain.com/name would take you to the 404 page on the parent site (but the menu would match up with the menu on the child site; we use WooThemes custom menus). Typing www (as http://www.domain/name) managed to rewrite the trailing slash just fine.

    We opened a ticket with host support. I don't know if support actually did anything, or if it was already working for them when they got around to the ticket, but in time, more and more sites began working w/o the trailing slash. It's still inconsistent, though.

    Many sites seem to be working now without the trailing slash, but not all, and I'm also seeing other inconsistent URL rewrites. For example, I typed http://domain.com/name and ended up at http://domain.com/other-name/name/. Another staffer followed a link from the parent site at http://domain.com/page/ to a child at http://domain.com/childname, which was correctly rewritten with the trailing slash, but when she hit the back button, she ended up at http://domain.com/childname/page/.

    Permalinks themselves seem mostly okay. http://domain.com/page makes it to the intended destination, but http://www.domain.com/page gets routed to http://domain.com.

    Let me show you the rewrite rules. Other than some custom rules so that timthumb can access cached images instead of dynamically generating everything every time, the rules are standard WP multisite rules:

    <iframe src="http://pastebin.com/embed_iframe.php?i=zQaBE2DA" style="border:none;width:100%"></iframe>

    I've not found anything to be consistently reproducible, but here's an example of a link that, at first, would not work without the trailing slash, and later, started directing me to an unrelated site.

    http://realtronhomes.com/gordana-valois

    (For example, one time it directed me to http://realtronhomes.com/stephen-greenberg/gordana-valois/.)

    We disabled our caching plugin (W3 Total Cache) after the migration because of some problems, and also b/c we thought it might help this issue, so the site has been slow.

    Any ideas would be appreciated. I don't know much about the server config, but could find out. It's a cloud VPS with VPS.net. Someone mentioned LightSpeed. Sorry so vague. The guy to ask is in another time zone and still sleeping. :) I'll get the details.

  2. hunsford
    Member
    Posted 1 year ago #

    Oops. Wasn't supposed to use iframe from pastebin. Sorry. Here's the link:

    http://pastebin.com/zQaBE2DA

  3. I would pull the TimThumb code out for a quick test (and if you put it back in, put it in a section ABOVE the WordPress calls.

    RewriteEngine On
    
    #timthumb caching
    RewriteCond %{SCRIPT_FILENAME} thumb\.php
    RewriteCond %{QUERY_STRING} src=http:\/\/.*\/(.*)\.(png|jpe?g)&w=([0-9]+)&h=([0-9]+)&zc=([0-9]+)
    RewriteCond %{DOCUMENT_ROOT}/cache/%1.%2-%3-%4-%5-80.png -f
    RewriteRule ^.* /cache/%1.%2-%3-%4-%5-80.png [L]
    
    # WordPress Start
    RewriteBase /
    RewriteRule ^index\.php$ - [L]
    
    # uploaded files
    RewriteRule ^([_0-9a-zA-Z-]+/)?files/(.+) wp-includes/ms-files.php?file=$2 [L]
    
    # add a trailing slash to /wp-admin
    RewriteRule ^([_0-9a-zA-Z-]+/)?wp-admin$ $1wp-admin/ [R=301,L]
    
    RewriteCond %{REQUEST_FILENAME} -f [OR]
    RewriteCond %{REQUEST_FILENAME} -d
    RewriteRule ^ - [L]
    RewriteRule  ^([_0-9a-zA-Z-]+/)?(wp-(content|admin|includes).*) $2 [L]
    RewriteRule  ^([_0-9a-zA-Z-]+/)?(.*\.php)$ $2 [L]
    RewriteRule . index.php [L]
    
    # WordPress End
  4. hunsford
    Member
    Posted 1 year ago #

    Thanks, Ipstenu. I was just coming back to say we found a fix. I'll still adjust the rewrite rules as you suggest as it seems a better way to handle it.

    After we deactivated W3 Total Cache and removed the caching directory that it created in the wp-content directory, there was another file left behind in wp-content called objectcache.php. We got rid of it and ta-da! No more weirdness.

    We're also planning to look into Super Cache instead of W3 Total Cache b/c andrea_r indicates that it's multisite aware.
    http://wordpress.org/support/topic/trailing-slash-needed-to-find-subdirectory?replies=16

  5. W3 Total Cache works fine if it's activated per-site in my experience. I'm using it right now :)

  6. hunsford
    Member
    Posted 1 year ago #

    You know, I have heard that people are using it successfully on multisite, usually when activated per site. We just haven't had good luck with W3 Total Cache. We tried doing it on a per-site basis before, and had trouble, so we switched to using it only on the parent site for awhile. That worked well until the server migration.

    I'm guessing that if we activated W3 Total Cache right now and didn't activate object caching, we'd be totally fine again.

  7. The 'problem' with W3TC is it's hella complicated and tricky to get working right. Really powerful, really tricksy.

    I use DB and opcode caching (via APC) on my site with no issues. Other people can't. It's not that W3TC is broken, it's that every server is different, and what works for me may not work for you. Nothing wrong with SuperCache, I love it too, but I had issues with it and BuddyPress. It flushed my cache every time I sent a PM via BP, and I couldn't get traction with the dev to fix it, so I switched.

  8. hunsford
    Member
    Posted 1 year ago #

    Hey, thanks for that BuddyPress note. Good to know, as we might implement BuddyPress in the future.

  9. To be fair, I have NO idea if that's still the case, but since I got W3TC working, I've no reason to switch again ;)

Topic Closed

This topic has been closed to new replies.

About this Topic

Tags