ericr23

Setting $wp_cache_gc=600 and the expire time to 590 appears to have helped.

But expired super-cache files don’t seem to be cleaned up:

Cache Contents
WP-Cache
    * 1011 cached pages
    * 1007 expired pages
WP-Super-Cache
    * 2 cached pages
    * 515 expired pages.

As always, thank you for the prompt reply!

The Expiry Time and Garbage Collection settings are what I believe are the defaults: 3600 seconds and once every hour, respectively.

I will try changing the garbage collection to every 6 hours.

Should I also correspondingly increase the expiry time?

Try deleting the “index.php” exclusion string.

I did that and everything seems to be working as it should. The index is cleared with every edited and new post.

(One odd thing, though: although I’m logged in, it’s being provided by supercache.)

So, any answer to why the index page is cached even though “index.php” is an excluded string?

Or rather, why wouldn’t it be, since with “pretty” permalinks, every single page is index.php, too.

Perhaps the solution is to have an option like “Clear all cache files when a post or page is edited” but applying just to the index page cache.

Our WordPress blog runs in its own directory. Posts are written in the dashboard and published immediately. The index page appears to be cached for both wp-cache and wp-supercache. Version 0.8.4, WordPress 2.6.

Duh, just request any wp page to trigger wp-cron — right?

Meanwhile, back to the 5:30 a.m. site problems, it suddenly occurred to me to check the root cron, since we’re now on VPS. Sure enough, several tasks were scheduled around that time. I rescheduled them earlier and for good measure set up a daily reboot at 4:15 a.m. It seemed to help.

On the other hand, perhaps he’s getting hit by a bunch of wp-cron tasks triggered by his being the first one on the site for a while?

How can I run wp-cron with a cron command to clear it out before the day’s work? Do I just run the wp-cron.php script?

When does wp-cron do its once-a-day tasks?

Our site also has problems around 5:30 every morning, just when our news guy is trying to post.

I think this is another example of a decision for wordpress.com’s needs instead of those of other installations.

Thanks, all. That’s a neat trick for stylesheets, Otto. I’ve had the IE conditional comment in place instead of the PHP code for a couple days now, and that appears to have worked.

I just learned about Microsoft’s conditional comments. Would it work to replace the php code (see original post) with the following?

<!--[if IE]>
<link rel=stylesheet href="https://www.domain.org/nwwstyleIE.css" type="text/css">
<![endif]-->

Hello. I have tried setting up a crontab job with

wget https://www.domain.org/?sm_command=build&sm_key=...

and, when that didn’t work,

curl https://www.domain.org/index.php -d sm_command=build -d sm_key=... -g

which didn’t work either.

Please help!

But I have had the same URL as a link on an “update” page for quite some time, and it always works.

And according to Arnee himself, “With wget and crontab it should be no problem to build the sitemap every night.”

I had removed wp-cron.php until I got wp-super-cache working, because of wp-cron’s heavy use of the shared server CPU.

Since restoring wp-cron.php, the edited files are indeed updated.

Nope.

New tack: Delete wp-cron.php (and delete ‘cron’ row in wp_options table). Write routine to check hourly if updated and if so, ping (Ping-O-Matic), etc. (rebuild sitemap, ping search engines, post future-dated posts).

Otto42 says: It’s an unnecessary option that, IMO, should not be added. Too many options make things confusing.

The unnecessary option is the post revisions feature itself. It’s definitely neat, but how many people really need it? The suggestion that it be an optional plug-in seems much more sensible than adding more confusion to the database for everyone whether they want it or not.