See that nice dip in the graph for this week? I started to preload the cache used by WP Super Cache last Sunday and it’s made a noticeable difference in the load on my server here. The big spike is the preloading process.
I’ve always discouraged users from preloading the cache (Askapache Crazy Cache will do this for any cache plugin), mainly because of the possible problems so many files will cause for hosting companies. If you have thousands of cache files, it’s going to take so much longer to recover from a disk crash.
On the other hand, Google will now be using speed as a metric for judging how “good” a website is. In the past this plugin ignored the pages visited by bots because the bots only visited each page once so caching a page after the fact was pointless. The page, all pages, have to be cached first before Google ever visits.
That’s what it looks like. Once you start preloading it launches a wp-cron job to fetch 100 posts, then schedules another job 10 seconds in the future to fetch another 100 posts until it finishes. It also disables garbage collection of old pages, but making comments or posts will still clear out the appropriate cached files.
It only caches single posts right now. It may not be worth caching archive or tag pages because many sites already tell bots to ignore those pages as the server is doing less work it will serve those archive pages more quickly anyway.
The preloading only works if you’re using the plugin in Supercache or “ON” mode. It’s still a work in progress but has worked fine here. As well as the preloader the development version of the plugin has:
- Better support for mobile plugins.
- A cache tester.
- Can be configured to only delete the page a comment is left on, rather than the front page and associated pages.
- Works in WordPress 3.0.
It also has a number of bug fixes and other features added too.
I need testers though, so grab the development version from the download page. Install it and please leave feedback here or preferably on the support forum.
You might also like
If you like this post then please subscribe to my full RSS feed. You can also click here to subscribe by email. There are also my fabulous photos and funny videos to explore too!
I use WordPress mainly as a CMS, so having it preload the pages as well would be huge. I do it now manually, and that is no fun.
Pingback: WP Super Cache: WP Cache Preloader und WordPress 3.0 - wp super cache, preload, cache, wordpress, plugin, caching - Vip-Chicks
great to hear. installed it on about 5 blogs now.. preloading seems fine, nice feature for sure (google..) – but on shared hosting? Mh.
the new preload developer version seems fine – no bugs. even its running great under wordpress 3.0 like you wrote it up
thank you very much for this, donncha!
I have a slow site, so lets say that I can not load 100 pages in 10 seconds, will I get a huge backlog of cron jobs asking for another 100 pages?
It will only schedule the next job when the current 100 pages are done so it doesn’t matter how long it takes. (As long as the process itself doesn’t timeout!)
Awesome Sauce! I’m loading this up on my blogs (two 3.0, one 2.9.2, with a mix of single site, multi site, and buddypress). So far? Looks good!
Awesome stuff!
What would be the impact on shared hosting in your opinion?
How long is a piece of string? Depends on your blog, how many posts you have, and how good your hosting provider is. I already talked to the guys at http://blacknight.ie/ and they were enthusiastic about the idea of precaching for performance reasons. If your hosting isn’t good enough, check them out! (and note the lack of affiliate codes on that link, I’m not earning a commission mentioning them!)
Okay, now I have a verbiage question!
My thought is ‘Okay, so once I’ve pre-cached, I go BACK down to the Expiry Time & Garbage Collection section and put my time in there.’ But then there are two places for expiry time: the Pre-Cache section and the Garbage collection. Am I right in assuming these are entirely independent of each other?
In the back of my head is the thought that combining these two, into a pre-cache and keeping the regular expiration, would work well. Only re-run the massive pre-cache once every couple months, and in the meantime, have your regular garbage collection going on every, say, 15-30 days? I have a feeling my brain is going about this the wrong way.
The preload time is a refresh when the cached pages are all cleared out and refreshed in one go. That’s completely different to the GC expiry time that clears out old files but leaves new ones.
What needs to happen is garbage collection on half-on files that are generated by people who have commented on the site or are logged in. They’re usually files that can only be used by one user so there’s no point leaving them there for ages.
Hi!
My site has some 11 000 posts from the last 5 years. My host is shared and relatively slow on serving (I’d say its mySQL-related) and I have som 5 000 visitors per day.
Now, should I enable preload or not with my situation?
Thanks!
I don’t know, but probably not. Your blog will generate over 20,000 cache files. Better to ask your host really!
@Donncha: Thank you! That makes sense. I going to have to think about how best to use Pre Caching with my set up now. (BuddyPress)
Great idea! Thanks!
Could you please tell me what exactly is the difference between the two expire times? I want the posts to stick forever. And the front page to expire every 15 minutes. Is that doable?
Is there a way to tell if it working or not? Do I need to log out as administrator. Can I look at the HTML?
Please see this comment. It isn’t possible to do what you want out of the box but it would be simple to code a plugin that deleted the supercache files for the homepage. Just delete wp-content/cache/supercache/hostname/index.html (and .gz) every 15 minutes …
Let’s say that I delete the supercache files for the homepage every 15 minutes. Should I set the other expire times to 0? I’m still confused on the difference between them.
Yeah, set it to 0. You don’t want the garbage collection deleting the other files…
I will suggest U provide few more settings for PreLoading.
Like How Many Pages to Pre Load. (Old Posts are Actually Never Accessed so frequently. and Even if they are accessed, chances are they are already Cached by previous request).
Flexibility shuld be provided to us as to what range of pages we need to Preload.
Something of that sought.
With my 20000 Posts on one of the ten blogs I have, my powerfull dedicated server will soon see its space gone ZERO if I enable Preload.
Good ideas and already on my mind. I will need to add limits of some sort to the caching.
I haven’t used your plugin in a while. But now I’ve tried it again, with the new options, and it seems to be working fine!
I had some trouble at first, because even though I unchecked the option “Don’t cache pages for known users” I could not see the cached files. I even tried logging out of my WP blog, but still wasn’t able to see the cached files. I then discovered that even though I was logged out, I still had the cookie “wordpress_test_cookie” in my browser. “wordpress_test_cookie” matches this line in the .htaccess file
RewriteCond %{HTTP:Cookie} !^.*(comment_author_|wordpress|wp-postpass_).*$
Maby you could change this line to
RewriteCond %{HTTP:Cookie} !^.*(comment_author_|wordpress_logged_in|wp-postpass_).*$
I just logged in into my blog checked at the settings again. It still says “Currently caching from post 200 to 300″. But I have more than 4000 posts…
It seems to have stopped (actually I’ve confirmed it by looking in the supercache directory).
Is it possible to make it continue?
Maby my value is too high? “Refresh cache every 525600 minutes. (0 to disable)”
Sounds like the wp-cron job failed and didn’t schedule the next job. I’ll see if I can catch that the next time you load the admin page.
Hmm, actually, it’s quite hard to figure out if the cron job is running because if you set an option as a flag, the blog may have an object cache in which case that option won’t be set until after the cron job has finished (and a new job scheduled). I had to check for this type of thing happening in my Tweet Tweet plugin and made the plugin insert a flag directly in the options table so I could be sure it wouldn’t be cached.
Might need to do the same with this unfortunately.
I clicked “Save” again to start the cron job again. But then my previous cache was deleted… So now I’m back on about 10 cached posts.
Do I have to stay logged in for the cron job to continue?
No, the cron job fires when someone visits your site. Ironically, it’ll fire less often the more of your site is preloaded! As long as people are leaving comments on your site and “known users” are looking around the cron jobs will (or should) fire.
I’ve just checked in code that will allow you to limit the number of posts cached, and added a “preload mode” where only wp-cache files are cleaned up. The dev version will update in about 15 minutes.
Hi Donncha,
I transferred a WP site to a new server with WP super cache on it.
~Zip the entire directory
~Unzipped to the new server
~reconfigured database connection
~activating plugins [issues started]
–> Now the issue is my posts went blank after activating WP super cache
(2nd attempt)
~ Deactivated all plugins [posts came back]
~ Activated WishList Member [posts are okay]
~ Activated WP super cache [posts went blank again]
(3rd attempt)
~ Deactivated all plugins [posts came back]
~ Activated WP super cache [posts are okay]
~ Activated WishList Member [posts went blank again]
My Question now is, is there a compatibility issue between the two plugins? Given the fact that it was working previously on my old server?
Francis – try uninstalling WP Super Cache. I bet the path in wp-content/advanced-cache.php is wrong and if you installed the plugin a long time ago that file isn’t as resilient to change as it is now. Make sure to follow the instructions in the readme.txt and then install it again.
Donncha,
I have done == If all else fails and your site is broken ==
Installed the latest version of WP-SC and done the same steps. I still have the same issue… Do you think is it something to do with permalinks? Do you have more suggestions?
BTW, Thanks for quick response I really appreciate it.
I don’t know, check your error log for PHP errors. It does look like there’s some incompatibility there but I’ve never used the WishList plugin so I don’t know. Sorry.
Nothing was reflected on the error logs.
Anyways, thanks for your time…
I can really use this stuff. Expecting wel over 10k visitors on 1 day on a site next week.
just noticed an odd behaviour: upgraded to the dev version, removed the regular version compeltely, but it doesn’t show me the rules I have to insert into the .htaccess file. Please see screenshot: http://screencast.com/t/NTRmNTUwZ
sorry, ignore my comment. I still had the old rules inside .htaccess that is why it wasn’t showing me what to insert
– once I deleted the old rules, your plugin was showing me the new rules to insert
just curios about one thing: you built the preloading in ’cause google will now be using speed as a metric, then how come, google doesn’t get a cached page? see this excerpt from one of my logging emails:
USER AGENT (Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)) rejected. Not Caching
also experiencing a weird behaviour: as I have been playing around with the settigns a couple of times, including preloaded the cache, etc. I noticed that the Expiry Time & Garbage Collection resets itself to 0 from time to time…
also the preload function, seems to only preload the main blog in my wpmu installation… I was expecting it to preload all blogs?
The rejected user agent is a throwback to when the plugin didn’t cache requests made by bots. Bots visit a page once and never go back to the same page (within a reasonable amount of time) so there was no point caching it. I’ll probably remove the bots from the rejected UA list for the next release just because it’s now important for bots to see fast page loads now as well.
The GC will reset itself to 0 if you’re using the code from yesterday but I made a few changes this morning. Grab the latest dev code!
MU – it’ll only preload the current blog. You’ll have to go into each blog’s admin page to reload each. I hadn’t thought of that, so thank you. Not sure if I’ll add a feature to cache all blogs though.
@Donncha: thx. also playing around with the debugging, not sure how helpful this message is:
URI rejected. Not Caching
how about also including the rejected URL? makes the message more useful
I downloaded the DEv version ~1h ago.. strange.. will simply update it again.
@Donncha: just thought about soem mroe feedback:
- the list showing the latest cached pages, is also limited to the main blog on a wpmu installation.
- a bit confused by GC:
Garbage Collection
Last GC was 11:41 minutes ago
Next GC in 58:19 minutes
Expired files are files older than 7200 seconds. They are still used by the plugin and are deleted periodically.
The explanation below says that if expiry time is above 1800secs GC is done every 10 minutes, how come mine says 60mins!?
Very good read Donncha, thank you for this. BTW, I’m using your domain maping plugin and it’s working great. Best regards, Alex.
@Donncha: Roger, will test the latest version
Preload the cache in WP Super Cache http://ocaoimh.ie/preload-cache-wp-super-cache/
Pingback: Preload the cache in WP Super Cache | Johnny Chadda .se
Hmm. I have the “same” problem as some people have commented about here earlier.
The additional cronjobs doesn’t get done. I get 100 cached pages (being ~50 of my last post and ~50 of my first posts, probably because the wordpress “import” done somewhere along the line…).
Is it this plugin that has problems or should I hunt deeper into other plugins? (I know lifestream have some problems with the cronjobs itself, but do not know if it causes other cronjobs to fail).
The original implementation of this loaded the posts by reloading the admin page with a counter. You had to stay on the admin page as it reloaded using Javascript. It doesn’t look as nice but might be needed if there are problems with cron.
Hi!
Where I can download the beta?
I´ve a wordpress with very high traffic (100.000 daily) and i need better caching system.
On the download page I linked from above perhaps?
We struggled with Super Cache on a sports site with 30k pageviews/day. Endless fiddling and tweaking didn’t bring satisfactory results. The frontend was fast in all browsers except Firefox. The backend crawled resulting in endless complaints from editors. How come the admin panel is not cached?
We switched to wp-file-cache. Easy setup. No fiddling. Bingo! Great results in all browsers with both the frontend and backend.
Robert – there’s no exception or code in the plugin to exclude Firefox so you might have been logged in on that browser and excluding caching from “known users” perhaps? The plugin is a full page caching plugin and not appropriate for the backend which is supposed to be dynamic. If the backend was crawling you should install an object cache. Use Google, there are plenty of different ones.
a nice feature (too all the other great stuff) would be a little db caching (queries) – maybe even in the dashboard like db chache or w3 total cache make it?
the new wp super cache with preloading runs still fine on my 5 blogs
thx!
Well. After some testing I have realized my description of the “cron” problem is not as I first said.
What is does is that it says: Caching page 100-200 (sic!)
And after a 100 post/pages is caches it then says an time for next job (a time which I don’t know if it ‘s actually happened yet or not, as I’m not totally sure of the time of the server…)
And then it clears the cache and begins caching the first 100 posts/pages again (once again stating it’s page 100-200…)
Okay. My last comment for today:
After some research (echo date() and more ^^) this is what actually happens to me:
I click the button to pre-load my cache. It caches my last ~50 posts/pages, then ~50 from a few years ago (not the oldest ones) of my total ~300 posts/pages (stating it caches post “100 to 200″. Then it sets a cron timer to pre-load “everything”(i.e. the same 100 posts/pages) again the after the specified time in the future, that is even if the timer is set to 0 (off) the cron timer is set to [start-time of past pre-load + 10 seconds].
I’m on MU if that matters.
And oh, this plugin is not very important to me, I just tought I’d try it out and now when it doesn’t work I just thought I’d tell you about it. So if you can’t find/fix the error, I’ll accept that it maybe is “only me” and disable the plugin
This isn’t related to the development version. I have a question about the difference between WP Cache and WP Super Cache. I’ve enabled “ON WP Cache and Super Cache enabled”.
The Cache Contents tells me:
WP-Cache (58.48KB)
13 Cached Pages
0 Expired Pages
WP-Super-Cache (37.85MB)
1882 Cached Pages
0 Expired Pages
Can you explain why 13 pages are in WP-Cache? Shouldn’t all pages be in WP-Super-Cache. What does this mean to me?
@Niska: Read the readme.txt, that’s just about the first thing explained in it!
@Donncha: I’ve read about the differences, but I still don’t understand why there is both Wp-Cache files and WP-Super-Cache files. I’ve always have had WP-Super-Cache enabled.
Donncha: I found the two errors that causes my troubles (I think).
Firstly there’s no check if the “refresh preloaded files every [] minutes” is disabled(zero) when it’s finished caching, meaning that if it’s set to zero it makes another caching once it’s finished with preloading the cache (which of course must be made with the preload cache now button).
Secondly, my page is too small (<1000 posts/pages), so posts_to_cache is never set which means wp_cache_preload_posts is set to zero which means it only makes one caching ($c =< 0?) and then thinks it is done.
So the cronjobs work just fine.
Thank Daniel, appreciate you digging into the code and figuring that out! I’ll get it sorted later today and leave a reply here.
@Daniel: Just added an else section that defines post_to_cache which will fix your problem. Thanks again!
hi Donncha,
that means we can download this new version with the development version link through wordpress plugin section?
have a good week!
Yeah, the development version is the one to go for to test this out.
@Donncha:
thank you for your answer – i`m going to update to the new dev version with my 5 or 6 blogs today
I was having the same problem as Daniel. Dowloaded the latest and greatest dev build to test. This seems to have fixed it for me too!
Whew! I thought I was going insane
@Ipstenu: Or … not as much as I thought. I got up to “Currently caching from post 500 to 600″ and it stalled. It took about 30 minutes to get there and now it’s hanging. It’d be nice if you could ‘cancel’ the pre-caching.
@Ipstenu: Oh, I get the same “problem” (in my own “fixed” version ^^, gonna change to donncha’s in a minute), but I thought it was because I have 302 posts/pages of which 2 (frontpage and blog page) was set to no caching… (Causing it to think I have 302 while only having 300).
Wellwell, not a large problem anyway…
@Donncha I didn’t see a fix for the plan cronjob after ‘forced’ preloading even if time is 0 problem though, I guess that problem would still remain…. even though posts_to_cache is fixed. Will check it out soon.
I also moderated “away” a comment (an old comment that shouldn’t be visible anymore) and it cleared away my whole cache even though I have “Only refresh current page when comments made.” set to true, bug or intended behaviour?
Was that comment in your spam or trash? I thought I had fixed that.
Yep, the infinite preloading loop when pressing “Preload Cache Now” with the timer set to 0 ( = no scheduled preloading? Should mean that) is still there. (As I said before, a check of timer = 0 should be done before scheduling next preloading).
Daniel – I’ve checked in a number of changes and that problem with the infinite loop is fixed now. The dev version should update in the next 15 minutes.
I got an error
———————————–
Rejected User Agents
Strings in the HTTP ’User Agent’ header that prevent WP-Cache from caching bot, spiders, and crawlers’ requests. Note that super cached files are still sent to these agents if they already exists.
Fatal error: Call to undefined function esc_html() in /www/htdocs/w0asdfff23/domain/wp-content/plugins/wp-super-cache/wp-cache.php on line 1069
Gordon – you probably need to use the latest version of WordPress. esc_html() is a standard WordPress command.
I have WordPress 2.7.1.
Yes, update your version of WordPress. There’s no good reason to be using 2.7.1 when you can be hacked in 2 minutes. I need to update the minimum version requirements if it says that 2.7.1 is supported.
Hi Donncha. Ok. I have an big german site with 16.000 User per day and i have big big Problems with the Wp-chache Plugin. I make all right .htacces, installation and so on, the wp-files where delivered right but in php (X-Powered-By PHP/5.2.12-nmm1). You can take a look at
http://news.preisgenau.de/
sometimes it take 7 seconds to load a site. The other problem. When 20 sites are chached new at the same time, than the hell is going on.
sorry for my bad english.
but i can’t find the mistake, thats the problem.
i have big big Problems with the Wp-super-chache Plugin (right)
the preload function ist absolutly necessary
@Gordon: you need to install WordPress 2.9.2, and if you’re going to use the preload function make sure not to preload them all at the same time.
wordpress should be the last / latest version (final) of course.. and the apache rewrite rules from the super cache plugin should be the latest rules of the plugin
Hi Donncha, ok thanks, but why the wp-cache files delivered as php files (firebug -> X-Powered-By PHP/5.2.12-nmm1). Also your blog posts here at ocaoimh.ie are loaded with php (firebug -> X-Powered-By PHP/5.2.6-1+lenny3) . I don’t understand that.
when you compare for expamle this 2 site (both using wp-super-cache)
1. http://www.vip-chicks.de/2010/multimedia/wp-super-cache-wp-cache-preloader-und-wordpress-3-0.html
2. http://news.preisgenau.de/nr-1-apple-der-erfolgreichste-handy-hersteller-in-den-usa-7094.html
The first one delivered static html files the second on not. Why?
That’s because you’re a “known user” with a cookie set in your browser. Only anonymous users get static files. It’s all in the readme.txt
Hi Donncha, your are right. (hand going to the head)
Hi donncha,
When i delete the cookies the most files are delivered als static HTML Files, but for exempale this file is delivered with php
http://news.preisgenau.de/ab-100-euro-gunstige-lcd-fernseher-handys-notebooks-und-pcs-6934.html
When you check it (you are No logged in User), you will see that. Ist this a bug?
@Gordon: It shows up as a cached page for me (in the source, I can see it).
Hi Ipstenu,
ok. right. Yesterday firebug told me these site is delivered with php. Strange.
@Donncha
I have a few suggestions to make wp-super-cache much better. I would foward to hear your opinon
1. Start the Preload Function with a regular external cronjob (that would be very nice)
2. Input Box for searching a post (per Post_ID) -> to re-chache only the single file (when you have maybe 3000 chached files a list is unhandy)
3. Recache single tags and cats
4. The Preload Function should maybe include the caching of tags and cats (Tags and Cats are very important)
6. When a post is publisched the tag and the cat of the Post should be recached (i use wp-super-cache 0.9.9, think this version don’t have this function)
i think its a good idea to let the user choose if he wants to use wp-cron or a real cron made by server (?)
@Christian Kopp: @Gordon: you can already set up a cron job. Just have it call a script that does the same as wp_cron_preload_cache() in wp-cache.php without the scheduling bits.
@Donncha:
Hi Donncha,
you mean a script thad contents the following (beside the variable definations – maybe wp-load..)
function wp_cron_preload_cache_cron2() {
global $wpdb, $wp_cache_preload_posts;
if ( get_option( ‘preload_cache_stop’ ) ) {
delete_option( ‘preload_cache_stop’ );
return true;
}
$c = (int)get_option( ‘preload_cache_counter’ );
if ( $c == 0 && function_exists( ‘wp_cache_clear_cache’ ) )
wp_cache_clear_cache();
if ( $c get_col( “SELECT ID FROM {$wpdb->posts} WHERE post_status = ‘publish’ ORDER BY post_date DESC LIMIT $c, 100″ );
} else {
$posts = false;
}
update_option( ‘preload_cache_counter’, ($c + 100) );
if ( $posts ) {
$count = $c + 1;
foreach( $posts as $post_id ) {
$url = get_permalink( $post_id );
wp_remote_get( $url, array(‘timeout’ => 60, ‘blocking’ => true ) );
$count++;
}
} else {
update_option( ‘preload_cache_counter’, 0 );
}
}
wp_cron_preload_cache_cron2();
Looks like saving a new post as draft wipes out the cache.
That doesn’t happen for me. I just tried it here and all 5890 cached pages are still cached. Do you have the “clear all cache files when post is published” checkbox enabled?
@Donncha: I do not have “clear all cache files when post is published” checked.
I DO have ” Only refresh current page when comments made.”
I had 36 pages cached. Went in and edited a post in draft, and wham. None. I’m using your dev version from … looks like May 3rd at 3pm US Central Time.
@Donncha: In case it matters, I’m running 3.0 Beta 2 on Multi-Site (though this happened on the nightly from 2 days ago).
Interesting feature. What I’ve done on highly trafficked sites is to regenerate an anonymous version of the latest X posts once a minute. Once posts are no longer within X, they fall back to the normal caching layer. The anonymous version is served to anonymous users via nginx, which sits in front of Apache.
@Ipstenu: The “clear all cache files” trumps any other options I’m afraid. It shouldn’t have cleared the cache when a post wasn’t published, I think. I’ll check that.
Mark – you’ll love this then, but there shouldn’t be any need to refresh every minute as they’ll be refreshed when comments are made. I just moved this site onto the same VPS that inphotos.org is on, on a new install of Ubuntu and once I tamed Postfix (Stop smtp! Down boy!) the load average has plummeted, even with Apache.
@Ipstenu: Ooops, I read your comment wrong. Sorry. Can you enable debugging in the plugin and check that when you save a draft post?
Donncha: Same problem as Ipstenu here, so I disabled the plugin for now =)
(I don’t have time to do the debugging though so I leave that to Ipstenu).
Just so you know it’s not a isolated occurrence (I’m on WPMU 2.9.2 myself).
@Daniel: It’d only take you a minute to activate the debug system, limit it to your own IP and save a new post but what it reports will help me fix the problem. Please do debug it if you have a spare few minutes!
I added a small check to the post change function so cached files aren’t deleted if the post is a draft one. I still don’t know how all the cache files were deleted for you but at least this should stop it. Previewing a post is not cached so there’s no point deleting any cache files.
Okay, tested on my 3.0 Single Site, no problems. Ran it on MU and blam. Well, there’s something. If this doesn’t show up right, let me know where I can email you. I edited out my cookie info
13:17:13 /wp-admin/post.php?post=2389&action=edit&message=10 Cookie detected: wordpress_test_cookie
13:17:13 /wp-admin/post.php?post=2389&action=edit&message=10 Cookie detected: wordpress_xxxxxxxx
13:17:13 /wp-admin/post.php?post=2389&action=edit&message=10 Cookie detected: wordpress_logged_in_xxxxxxx
13:17:13 /wp-admin/post.php?post=2389&action=edit&message=10 supercache dir: /home/jorjafox/public_html/wp-content/cache/supercache/jorjafox.net/wp-admin/post.php/
13:17:13 /wp-admin/post.php?post=2389&action=edit&message=10 Cookie detected: wordpress_test_cookie
13:17:13 /wp-admin/post.php?post=2389&action=edit&message=10 Cookie detected: wordpress_d41d8cd98f00b204e9800998ecf8427e
13:17:13 /wp-admin/post.php?post=2389&action=edit&message=10 Cookie detected: wordpress_logged_in_d41d8cd98f00b204e9800998ecf8427e
13:17:13 /wp-admin/post.php?post=2389&action=edit&message=10 No wp-cache file exists. Must generate a new one.
13:17:14 /wp-admin/post.php?post=2389&action=edit&message=10 Cookie detected: wordpress_test_cookie
13:17:14 /wp-admin/post.php?post=2389&action=edit&message=10 Cookie detected: wordpress_xxxxxxx
13:17:14 /wp-admin/post.php?post=2389&action=edit&message=10 Cookie detected: wordpress_logged_in_xxxxxxx
13:17:14 /wp-admin/post.php?post=2389&action=edit&message=10 In WP Cache Phase 2
13:17:14 /wp-admin/post.php?post=2389&action=edit&message=10 Setting up WordPress actions
13:17:14 /wp-admin/post.php?post=2389&action=edit&message=10 Not caching wp-admin requests.
Upgraded to your modified version, and it appears to be the same error. Only on Multi-site, though.
@Ipstenu: Odd, none of the debug messages above mention deleting the cache at all!
Okay, this is weird. It keeps wiping out my log (I’m saving to a text file) every time I perform some admin action like deleting a spam comment, or edit a post. The cache, though, ONLY gets whacked when I edit a post.
So I do the logical thing and wonder ‘Holy Shmoly! Has this been happening the whole time?’ Roll back to 0.9.9 and guess what? The log gets whacked but the cache stays put.
Back to the dev version, but now I UNCHECK “Only refresh current page when comments made.” Doesn’t help.
Bugger. I’m back on .9.9 because this cache killing on MU is killing me! Argh.
Ok. Preloaded 100 posts (updated the settings after 100 posts which cancels the timer to the next the preloading).
Removed a comment which I before had put as “unmoderated” (on a page if that matters). Cache emptied:
11:36:58 /wp-admin/admin-ajax.php Post 11 changed. Update cache.
11:36:58 /wp-admin/admin-ajax.php Post change: deleting cache files in /home/soilhear/public_html/wp-content/cache/supercache/www.soilheart.com/
11:36:58 /wp-admin/admin-ajax.php wp_cache_post_id_gc clearing cache in /home/soilhear/public_html/wp-content/cache/supercache/www.soilheart.com//om-daniel/.
11:36:58 /wp-admin/admin-ajax.php rebuild_or_gc: deleted /home/soilhear/public_html/wp-content/cache/supercache/www.soilheart.com//om-daniel/feedback/index.html
11:36:58 /wp-admin/admin-ajax.php wp_cache_post_id_gc clearing cache in /home/soilhear/public_html/wp-content/cache/supercache/www.soilheart.com/page/.
11:36:58 /wp-admin/admin-ajax.php Post change: deleting page_on_front and_page_for_posts pages.
11:36:58 /wp-admin/admin-ajax.php wp_cache_post_id_gc clearing cache in /home/soilhear/public_html/wp-content/cache/supercache/www.soilheart.com//.
11:36:58 /wp-admin/admin-ajax.php rebuild_or_gc: deleted /home/soilhear/public_html/wp-content/cache/supercache/www.soilheart.com/blogg/2010/04/02/caolings-historiska-vandringsled/index.html
And so on for the rest of the blog posts.
I also made the same thing, but edited a draft for a post:
11:42:49 /wp-admin/post.php Cookie detected: wordpress_
11:42:49 /wp-admin/post.php Cookie detected: wordpress_logged_in_
11:42:49 /wp-admin/post.php In WP Cache Phase 2
11:42:49 /wp-admin/post.php Setting up WordPress actions
11:42:49 /wp-admin/post.php Not caching wp-admin requests.
11:42:49 /wp-admin/post.php Post change: deleting cache files in /home/soilhear/public_html/wp-content/cache/supercache/www.soilheart.com/
11:42:49 /wp-admin/post.php wp_cache_post_id_gc clearing cache in /home/soilhear/public_html/wp-content/cache/supercache/www.soilheart.com//?p=1292/.
11:42:49 /wp-admin/post.php wp_cache_post_id_gc clearing cache in /home/soilhear/public_html/wp-content/cache/supercache/www.soilheart.com/page/.
11:42:49 /wp-admin/post.php Post change: deleting page_on_front and_page_for_posts pages.
11:42:49 /wp-admin/post.php wp_cache_post_id_gc clearing cache in /home/soilhear/public_html/wp-content/cache/supercache/www.soilheart.com//.
11:42:49 /wp-admin/post.php rebuild_or_gc: deleted /home/soilhear/public_html/wp-content/cache/supercache/www.soilheart.com/om-daniel/feedback/index.html
11:42:49 /wp-admin/post.php rebuild_or_gc: deleted /home/soilhear/public_html/wp-content/cache/supercache/www.soilheart.com/blogg/2010/04/02/caolings-historiska-vandringsled/index.html
Same thing once again.
Or, well. None of my cases isn’t really good I guess.
(One is moderating a post and the other one editing a draft…).
But it will have to do for now =P
But looking into your code the
add_action(‘edit_post’, ‘wp_cache_post_change’, 0)
line do look a little odd… shouldn’t it be wp_cache_post_edit?
And I also do not understand why doing anything with a comment than posting it should clear the whole cache?
if ( [some code] && strpos( $_SERVER[ 'REQUEST_URI' ], ‘wp-comments-post.php’ ) ) {
$all = false;
} else {
$all = true;
}
A little more looking into the code seems like that when a post is updated a two calls to the wp_cache_post_id_gc function is made. This call I guess is supposed to delete frontpage and the blog page. (static homepage option).
What this function does is that it calls the prune function on homepage and blogpage. The problem is that the prune function seem to clear all subfolders.
Correct me if I’m wrong in anything above but to me it seems like this is the case… a hint of this is given by:
11:42:49 /wp-admin/post.php Post change: deleting page_on_front and_page_for_posts pages.
11:42:49 /wp-admin/post.php wp_cache_post_id_gc clearing cache in /home/soilhear/public_html/wp-content/cache/supercache/www.soilheart.com//.
11:42:49 /wp-admin/post.php rebuild_or_gc: deleted /home/soilhear/public_html/wp-content/cache/supercache/www.soilheart.com/om-daniel/feedback/index.html <– The page I removed a comment from
[deleting every post/page in the cache]
11:42:49 /wp-admin/post.php wp_cache_post_id_gc clearing cache in /home/soilhear/public_html/wp-content/cache/supercache/www.soilheart.com/page/.
11:42:49 /wp-admin/post.php wp_cache_post_id_gc clearing cache in /home/soilhear/public_html/wp-content/cache/supercache/www.soilheart.com//blogg/.
11:42:49 /wp-admin/post.php wp_cache_post_id_gc clearing cache in /home/soilhear/public_html/wp-content/cache/supercache/www.soilheart.com/page/.
@Daniel: I noticed something odd immediately – “supercache/www.soilheart.com//?p=1292/” but your blog does have permalinks. Did you save the draft post before you added a post title?
Daniel – Try the dev version in about 15 minutes. I made a change so only the “page for posts” is deleted.
As I said, the test was done with a draft, so that’s why the number…
)
I don’t think wordpress reserves a name before it gets published?
Ok, will do.
That seem to be the main problem right now at least. (We’ll see later
CASE 1: Draft editing and saving:
19:55:08 /wp-admin/post.php wp_cache_post_change: draft post, not deleting any cache files.Nothing deleted, so far so good.
CASE 2: Editing published post:
Clearing cache for post 1282 on post edit.
Post change: deleting cache files in /home/soilhear/public_html/wp-content/cache/supercache/www.soilheart.com/wp_cache_post_id_gc clearing cache in /home/soilhear/public_html/wp-content/cache/supercache/www.soilheart.com//blogg/2010/05/07/sma-ting/.
rebuild_or_gc: deleted /home/soilhear/public_html/wp-content/cache/supercache/www.soilheart.com//blogg/2010/05/07/sma-ting/index.html
wp_cache_post_id_gc clearing cache in /home/soilhear/public_html/wp-content/cache/supercache/www.soilheart.com/page/.
Post change: deleting page_on_front and_page_for_posts pages.
wp_cache_post_id_gc clearing cache in /home/soilhear/public_html/wp-content/cache/supercache/www.soilheart.com//.
rebuild_or_gc: deleted /home/soilhear/public_html/wp-content/cache/supercache/www.soilheart.com/om-daniel/index.html
rebuild_or_gc: deleted /home/soilhear/public_html/wp-content/cache/supercache/www.soilheart.com/foton/index.html
rebuild_or_gc: deleted /home/soilhear/public_html/wp-content/cache/supercache/www.soilheart.com/blogg/2010/04/10/har-last-pluggar-kommer-studera/index.html
rebuild_or_gc: deleted /home/soilhear/public_html/wp-content/cache/supercache/www.soilheart.com/blogg/2010/05/04/alltid-ar-det-da-nagot/index.html
rebuild_or_gc: deleted /home/soilhear/public_html/wp-content/cache/supercache/www.soilheart.com/utbytesaret/index.html
wp_cache_post_id_gc clearing cache in /home/soilhear/public_html/wp-content/cache/supercache/www.soilheart.com/page/.
Still deletes the whole cache (in this case 5 more pages).
CASE 3: Adding a comment:
wp_cache_post_change: comment detected. only deleting post page.wp_cache_post_id_gc clearing cache in /home/soilhear/public_html/wp-content/cache/supercache/www.soilheart.com//blogg/2010/05/07/sma-ting/.
rebuild_or_gc: deleted /home/soilhear/public_html/wp-content/cache/supercache/www.soilheart.com//blogg/2010/05/07/sma-ting/index.html
wp_cache_post_id_gc clearing cache in /home/soilhear/public_html/wp-content/cache/supercache/www.soilheart.com/page/.
Removes the cached copy of that post. Works as intended.
CASE 4: Move the comment to the trash:
Moderated comment deleted or spammed. Don't delete any cache files.Post change: deleting cache files in /home/soilhear/public_html/wp-content/cache/supercache/www.soilheart.com/
wp_cache_post_id_gc clearing cache in /home/soilhear/public_html/wp-content/cache/supercache/www.soilheart.com//blogg/2010/05/07/sma-ting/.
rebuild_or_gc: deleted /home/soilhear/public_html/wp-content/cache/supercache/www.soilheart.com//blogg/2010/05/07/sma-ting/index.html
wp_cache_post_id_gc clearing cache in /home/soilhear/public_html/wp-content/cache/supercache/www.soilheart.com/page/.
Post change: deleting page_on_front and_page_for_posts pages.
wp_cache_post_id_gc clearing cache in /home/soilhear/public_html/wp-content/cache/supercache/www.soilheart.com//.
rebuild_or_gc: deleted /home/soilhear/public_html/wp-content/cache/supercache/www.soilheart.com/om-daniel/index.html
rebuild_or_gc: deleted /home/soilhear/public_html/wp-content/cache/supercache/www.soilheart.com/foton/index.html
rebuild_or_gc: deleted /home/soilhear/public_html/wp-content/cache/supercache/www.soilheart.com/blogg/2010/04/10/har-last-pluggar-kommer-studera/index.html
rebuild_or_gc: deleted /home/soilhear/public_html/wp-content/cache/supercache/www.soilheart.com/blogg/2010/05/04/alltid-ar-det-da-nagot/index.html
rebuild_or_gc: deleted /home/soilhear/public_html/wp-content/cache/supercache/www.soilheart.com/utbytesaret/index.html
wp_cache_post_id_gc clearing cache in /home/soilhear/public_html/wp-content/cache/supercache/www.soilheart.com/page/.
Deletes the whole cache once again.
On the whole: Works better, still deletes whole cache on comment or published posts editing, which in my opinion it should not do.
And actually the log states it only deletes the “page on front” (with all subfolders, i.e. the whole cache) and not the “page for posts”.
If I do a quick edit of posts, I don’t lose the cache, but if I do a FULL edit and save, I’m still loosing the cache. Ugh.
hi Donncha,
i upgraded WP to 2.9.2 and installed the new wp-super-cached plugin. All is working fine, but i can not set a Refresh preloaded time. When i put in for example “2″ and press “Update Settings” my input is resetet to 0. Other inputs like setting up the Expired Time are working. I checked all pressmissions on the server. Seems all looking fine. The sites are cached correctly. Do you have an idea?
Greets from Germany.
ok, find the mistake, the intervall must be “minimum 30 minutes”
@Donncha: I’ve build a plugin that removes the front page from the cache every 15 minutes. Now I need to rebuild it as soon as it has been deleted. Is it possible to use a function in your plugin to acchieve that?
Niska – no, just fetch the front page using wget, curl, fsockopen, wp_remote_get() or whatever suits your script. The plugin will recreate the supercache page.
I have a question:
When i have “the preloaded mode” on with a time range of for exmample 30 min, did that mean that
a) All chached files are recached every 30 min? or
b) all files which are not chached (this last cron), because they are new, are chached every 30min?
Thanks for answer
All the preload files (single posts) are refreshed every 30 minutes in your example. The files are deleted and recreated. During the refresh it will now delete the cache of the single post before creating it again. All the cache isn’t deleted in one go.
This morning I added code to clear out supercache files older than the refresh time after the cache is refreshed. The only files this should affect are tags and archive pages created by visitors to your site.
Hi Donncha,
thanks for this important information.
Think i find a bug. When i change a chached posts or created a new posts, the plugin delete all chached Tags und Cat Pages. Think this is a bug, because the plugin should only delete the tags and cat pages which are assosiated with the post. The chached single posts Pages are fine.
Can anyone confirm this?
Is that in half-on mode or full?
BTW – please stop changing your email on every comment, I’m hardly going to spam you!
I’ve downloaded the latest dev version from yesterday (latest entry in changelog is 2010-02-08 14:24). I’ve got “WP Cache and Super Cache enabled = ON” and “Super Cache Compression = ON”. ALL other settings are unchecked. Expire time is set to 0 seconds (never expire).
Current Cache Contents:
WP-Cache (609.46KB) 147 Cached Pages 0 Expired Pages
WP-Super-Cache (655.89MB) 32766 Cached Pages 0 Expired Pages
My problem is that everyting seems to be working fine when logged in. I’m reloading a post several times. Everytime footer reads
Page loads very fast. It seems to be cached!
Now. I log out. I go to the same page, and get this error in footer.
I’ve checked the source code of wp-cache-phase2.php, and it seems as if line 388 @wp_mkdir_p( $dir ); is the source of the problem. It returns false, wich means that the directory wasn’t created.
I have two questions about this:
1) When I’m logged in I get the feeling that the cache is working. However, when manually checking the existanse of the cache using FTP, it isn’t found in the “wp-content/cache/supercache” directory. Why is that?
2) How come the directory wont be created? Could it be that there is too many files in the directory? I currently have 32766 files…
The html comments are not visible in comment above. I try again:
When logged in I get:
Dynamic page generated in 2.137 seconds.
Cached page generated by WP-Super-Cache on 2010-05-11 11:05:55
Compression = gzip
When logged out I get
Dynamic page generated in 2.014 seconds.
File not cached! Super Cache Couldn’t write to: wp-content/cache/supercache/www.domain.com/my-post.html/2599829494be928f16172d0.14739459.tmp
I’ve now removed the cache completely. And now I get cached pages when logged out. But I’m still confused.
Was there too many files in the supercache directory?
Why did I get the message that a post was cached when I was logged in, although it wasn’t?
Hi Donncha,
@Is that in half-on mode or full?
I run WordPress 2.9.2 normal version and using the full mode, with super-cache compression
@Donncha: I’m testing the dev version today again. The problem (described above) seems to affect only cat pages and not tags pages.
-> I gave a cached posts with the quick edit function a new tag. Than i checked out the footer comments on differnt posts, cats and tags. All tags stayed in chache, but all cat pages where rechached after the short editing of the post. The post is only assoziated with one cat.
@Niska: are you sure, when you set expired time o 0 seconds that means never expire?
Yes. 0 = posts should never expire.
Had a question about the rewrite rules for mobile support. Link to mu forums
I’d like to add to my previous comment that my disk has 16 GB free. Maby I had too many files in the cache directory? I’ve read on another place that “One of the things to watch for is that you can’t put too many files, more than a few hundreds, in the same directory on Unix or performance will suffer.”.
Do anyone else have problem with too many files? Maby the cache directory structure should be by using the first four characters in the filename? So that “12345.html” would go into /1/2/3/4/12345.html
Just an idea…
But why did I get the message that a post was cached when I was logged in, although it wasn’t (I manually checked the cache directory)?
Donncha, this feature sounds like just what I’ve been looking for – thanks! Would you consider adding support for tag, category and archive pages? I rely on those being fast (and not just as fast as WP can serve them with low server load).
I finally got around to doing more work on the plugin. Grab the latest dev version if you’re using a static front page. When you publish a post it won’t clear out the whole cache now!
+1 Kena’s request. I dunno about tag pages but I’d really like to see category pages cached, at least at the top level if the categories are nested.
If it’s too complex and stops you adding other cool stuff then it’s not a deal-breaker. If the category pages are that popular then the 1st one there can take the hit.
Thx. I missed that Preload-Feature a lot. Now I dont need to use a Link-Checker any more to get all my pages cached.
Pingback: WP Super Cache 0.9.9.2
It is probably me, but I’m having a problem getting WP Super Cache Preload Cache to work. Every time I click ON and then Update, it disables Preload. Then, if I enable Preload and set the time to 30 minutes, and hit Update Settings, Preload appears to switch ON to HALF ON. Hence, only 3 pages have been cached (and I’m surprised and don’t know how that many got through). Note that I’m using WP 3.0.
Pingback: The Blackboard » More Blogging Issues: Trying something today.
Pingback: More Blogging Issues: Trying something today. - My Habari
When I clicked preload the first time it got stuck at caching posts 100-200 and only appeared to have cached 40ish pages. I am using wp as a cms and using pages for everthing. So I clicked it again and now it just reloads the page and seems to do nothing. Any ideas?
If you’re having problems try the development version. It’s on the “Other Versions” page on the WordPress.org homepage for the plugin. It may work better for you as I’ve made a number of improvements to it.
Ok I think I have a better idea of what is going on now. I came back the next day and it had preloaded something like 80 pages. So it was just taking a long time. My page load with out cache are over 30 seconds so I am guessing that wp super cache has to load the page in some way to create the html version. This being the case it probably does take over a minute per page.
So I let it run and it made it to 94 pages preloaded. It seemed like it was going alright but I eventually got an email saying that it may have stalled. When I went back to check on it there were no pages “super cached”. I have not installed the development version as yet since I don’t think my original diagnosis was correct. Any thoughts on what seems to be going on now? Should I just go ahead with the development version and see if that helps?
Thanks
Looks like it’s not preloading. Try the development version, it might help you.
Hi,
where exactly does it store preloaded files? Is it the same as “directly cached files”?
I have the same problem as Kris. I might try the development version now.
Also, I’m still getting this error when visitors come from Google Images:
PHP Fatal error: Call to a member function get() on a non-object in /wp-includes/cache.php on line 93
I really don’t understand why it does serve a dynamic page to the Googlebot when I used the webmaster tools to check how Google sees my page.
Anyway, great work, appreciate this plugin a lot.
sOliver – wp-content/cache/supercache/ is where they go. Not the same as those other files.
That get() function is not a Supercache problem, that’s another plugin trying to use the WordPress object cache after the object cache has been destroyed by PHP.
If Googlebot sees a dynamic page use the debug system in the plugin to figure out what it’s doing.
You said: “That get() function is not a Supercache problem, that’s another plugin trying to use the WordPress object cache after the object cache has been destroyed by PHP.”.
Are you absolutely certain of this? Can you explain why the error message describes your cache file on a line that actually has a get() function rather than the file of the other plugin that is using the WP object cache improperly?
What other plugin?
I am getting this error regularly and I have only a few plugins installed.
Yes, a recent version of Supercache (after this post was written) accidentally used get() in the PHP shutdown process when it used get_option() but that’s not the case in the current release. I think the problem may sometimes occur in WordPress core code too. There’s a trac ticket on the subject but I don’t have a url for it.
hello,
i like the preload function, however with qtranslate it doesn’t preload the languages! any idea to to fix?
Not really, you’d have to hack the plugin to change the language headers in the request sent to itself.
hi there,
thanks for the amazing work, i notice a great performance increase on my blog with more than 68.000 posts.
i have everything preloaded
this took about a week or so and i’m happy with the result.
only thing is, i have a little update to be made in the footer of every page and i wonder what the behavior will be of “Refresh preloaded cache files every * minutes”.
will it grab 100 pages a time to be re-cached leaving the cache in place, or will it clear the complete cache in once and then starts caching the pages?
i have quite a few broken links on these pages and use “broken links remover”, this combined with the huge number of posts makes my page load very slow with the preloaded cache so hence my question.
thanks,
Randall
Randall – it leaves the cache in place and only deletes the cached page being requested so it can be cached again.
thanks for the fast reply.
so, if i set,
“Refresh preloaded cache files every 720 minutes”
it will re-cache a page if a page is
A) older then 720 minutes
and
B) the page is visited by either a visitor or a bot
question: doesn’t that make the requested pages slow?
No, it will do a full refresh of all preloaded files every 720 minutes. The refresh is done by a WP Cron job so it doesn’t rely on a page being requested by a visitor.
ok, clear
will give it a try and see how it works
thanks
was thinking,
if i set it to refresh every 720 minutes it shows it will start refreshing in 12 hours.
because i have 68.000 pages the refresh will take about a week so i’m guessing this could lead me to a problem, not sure if the second cron job will start again if the first is still running.
would it be beter to set it to a 2 week schedule to be safe (this would mean tough i would have to wait 2 weeks before the first refreshing starts.)
is it possible to initiate a single refresh?
sorry for all the questions, normally i don’t mind to just try out all the options but the shear number of pages in this case makes me a little nervous
since i have been caching for the last month already (i keep changing things)
Just to let you know,
the pre-load schedule behaved perfectly.
i had 68000 posts pre-loaded and wanted to have the pre-loaded cache to be refreshed, was worried that setting the refresh every 720 minutes would give troubles since the caching of that many pages would take longer than those 720 minutes.
no problem whatsoever, the re-preloading took several days and the 720 minute schedule only initiated again after the complete run was finished.
Thanks again for the great plugin
You said: “Can be configured to only delete the page a comment is left on, rather than the front page and associated pages.”
How?
Check “Only refresh current page when comments made.” on the Advanced Settings page.
Please reword the check box label from:
“Only refresh current page when comments made”,
which means:
“Do not refresh current page until a comment is made”
to:
“Refresh only the current page when a comment is made”,
which means:
“when a comment is made do not refresh any page(s) except (other than) the current one”.
Lee – thanks for the great suggestions!
Request: Please change the description of the preload interval. Do not say “every N minutes”. Instead say “N minutes after the completion of the preceding reload”
Hi Donncha ,
Thank you for the very useful caching plugin. I have an issue right now. I have enabled preload mode in my blog (so it disables the cache expiration/garbage collection thing). I have confirmed in the /wp-content/cache directory. It did create those superstatic HTML files for all my blog posts.
I have set preload to refresh every 2880 minutes. But my problem is that after this period, some of my blog posts does not have an updated sidebar?
Take note that I have added posts daily to my blog however even after 2880 minutes, some of the blog posts did not have an updated sidebar (where it shows the most recent posts).
Is this an error or am I missing something. Please let me clarify how preloading works. As what I read, it is supposed to refresh the entire super-cache files?(all blog posts). Or only some of them?
I do not want to refresh manually by pressing “preload cache now” again. It seems it defeat the purpose of setting it automatically. Thank you for your clarification.
Turn off preload mode if you want supercache files to be updated when they expire. With the mode on they won’t be updated until preload happens again!
I am confused, would that mean that If I enable preload to refresh every 2880 minutes (with preload mode on), the preload cache would then be refreshed but not updated?
What is the difference between refreshed and updated in this case? Or the scenario below:
Preload mode on- refresh
vs.
Preload off- cache expired then updated
Do they have the different results? Sorry if for asking a very noob question, but I do not understand this either. So bear patience. Thanks.
refresh = update. When the preload process runs it updates all the supercache files and deletes expired ones. When the cache is refreshed it’s updated
Pingback: Best WordPress Cache Plugin – Make Web Faster
Hi Donncha,
Good stuff – really save my server workload.
A couple of question regarding preload, in my site – the preload run very well if I initiate to “Preload Cache Now” manually. However, when I schedule the preload by 1 hour, it doesn’t work – since I can’t see a different in the cache result.
My question is :
1. How do we check if the cron job work / no ? Is there any menu or log that we can find ?
2. Is it possible to run a command to run this preload cache? Let’s say I will run a cron command to request a certain URL to initiate the preload cache activity.
Thanks a bunch for your response in advance..
1. use the cronview plugin that I linked to from the settings page.
2. Yeah, the function wp_cron_preload_cache() in wp-cache.php does the preloading. You’ll have to run that.