distobj

So fixing rewriting seems a dead end. 8-(

Anybody else got any ideas about how I can avoid these two redirects? Two is two too many, but one would at least be an improvement. The only one-redirect solution that comes to mind is to generate the Redirect commands for all (~5000!) effected permalinks and stick those in .htaccess.

Thoughts?

Yep, still a 404, which I’d expect because the old permalink structure was a proprietary one. Weird eh?

Ok, thanks. Unfortunately, I made that change but the problem persists. Here’s the full, revised .htaccess file;

# Rewrite old custom permalink structure to canonical post-id form
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^[0-9]{4}/[0-9]{2}/[0-9]{2}/00([0-9]*)/?$ /?p=$1
</IfModule>

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>

# END WordPress

Thanks Otto!

Here’s the rewrite that used to work in 2.5, but no longer does after the upgrade to 2.6.3;

RewriteEngine On
RewriteBase /
RewriteRule ^[0-9]{4}/[0-9]{2}/[0-9]{2}/00([0-9]*)/?$ /?p=$1 [L]

what we’ve done for now is change the rule to use a 302 redirect;

RewriteRule ^[0-9]{4}/[0-9]{2}/[0-9]{2}/00([0-9]*)/?$ /?p=$1 [R=302,L]

That “works”, but it results in not just the initial 302 redirect, but a subsequent 301 to the new permalink (as you probably know), so it’s not a permanent fix (we hope!).

Thanks again.

Mark.

I’ve just done a fair bit of testing, and when I enable tags & categories (at “consider”), I see the widest variance in CPU utilization by the mysql daemon. For bodies and titles, I’m seeing anywhere from about 0.6-1.1 sec, but for tags/categories, it can consume anywhere from 1 to 5 seconds depending upon the particular post I’m testing on.

Hey. Thanks for the prompt response.

I’ll answer here in case my answers are useful to others.

For “relatedness”, we have everything selected with extra emphasis on the body content as well as “require at least one tag in common”.

I turned off RSS support only because I hadn’t had a chance to see how it worked.

Performance was “worse” than with 2.06 in the sense that 2.06 took about 15 minutes to bring the server to its knees (during almost peak traffic) whereas 2.1 brought it down almost immediately despite being tested during off-peak hours. That’s not entirely an apples-to-apples comparison though, because I’d done lots of MySQL tweaking in the meantime.

Yes, we’re using WP-Supercache.

I just tried the new 2.1 version, hoping it would help with the performance problems we had with 2.06. Alas, it brought the server to a crawl again.

The site I tried it on has 5400 posts, about 200 categories, and a couple thousand tags (and uses WP Super Cache of course). It runs on a quad core Xeon with 4G of RAM, and CPU and which serves about a million hits per day, all while keeping CPU utilization hovering at about 5-10%. When I turn on YARRP, CPU goes immediately spikes to 90% and the site becomes unusable.

Any suggestions for how we could optimize the query that YARRP performs? Perhaps additional indexes, turn types of matching off, etc..?

I solved the problem, so I thought I’d let others now.

At the same time as the move, we upgraded our plugins which included the Meta Robots plugin. Unfortunately, in my haste to upgrade, I didn’t notice that upgrading Meta Robots sets a bunch of options to “on” that were previously off. One of those options was “disable date archives”. Oops.

Ok, thanks again for your help.

Sorry, there was no subdomain. The site is https://www.windowsmobilecool.com and we have a staging site at staging.windowsmobilecool.com where the problem can also be demonstrated.

I tried changing the permalinks structure on “staging” to default, but even then, date archive links (using “?m=200808”) still redirect to the home page.

Yes, individual post permalinks work fine.

Thanks for your help.

Good thinking. I changed the theme back to WordPress default, but the problem still exists.

We moved the server & switched permalinks at the same time, so never checked.

I just ran into this problem last night too, on line 274 of plugin.php. I encountered it during an import of a small WXR file. It always stops at the same point in the file, and always on that line in plugin.php.

I don’t know where it’s getting the “60 seconds” value from though – I updated php.ini temporarily and increased the value to 600, but it still complains about 60. Weird.

FWIW, I had the same problem described here, and am also at Dreamhost. It happens with the latest versions of WP-Cache and WP-Super-Cache: a few minutes after activation, whammo, the number of httpd instances goes sky high, consuming available memory.

What I did to fix it, was move the cache directory from wp-content/cache (NFS mounted) to /tmp/hostname-wp-cache (local) by changing the relevant line in wp-cache-config.php. Luckily my cache maxes out at about 10M, so it fits well in /tmp: YMMV.

FWIW, the problem was the XHTML Validator plugin.