WP Super Cache version 0.9.7 is now available. WP Super Cache is a page caching plugin for WordPress that will significantly speed up your website.
Since the last release of the plugin a number of new features have been adding, bugs fixed, and documentation updated. For a taster, here are the changes from the readme.txt:
- Fixed problem with blogs in folders.
- Added cache file listing and delete links to admin page.
- Added “Newest Cached Pages” listing in sidebox.
- Made admin page translatable. (work in progress)
- Added “How do I make certain parts of the page stay dynamic?” to FAQ.
- Disable supercaching when GET parameters present instead of disabling all caching. Disable on POST (as normal) and preview.
- Fixed problem with cron job and mutex filename.
- Warn users they must enable mobile device support if rewrite rules detected. Better detection of when to warn that .htaccess rules must be updated (no need when rewrite rules not present)
- Use the wordpress_test_cookie in the cache key.
- Show correct number of cache files when compression off.
- Fixed problem with PHP safe_mode detection.
- Various bugfixes and documentation updates. See Changelog.txt
- Advanced: added “late init” feature so that plugin activates on “init”. Set $wp_super_cache_late_init to true in config file to use.
- Advanced: Added “wpsupercache_404” filter. Return true to cache 404 error pages.
If you’re upgrading and your blog is installed in a sub directory the mod_rewrite rules may not have been created correctly. You’ll know this because the timestamp on your cached pages will change on every load. If that happens, remove the Supercache rewrite rules and recreate them through the admin page.
You can list all the blog’s cache files now, ordered by generation time. From that listing you can delete individual files.
The debug function is very powerful. You can choose the level of logging. Level 1 logs errors and warnings of a serious nature. Level 5 logs them plus lots of normal functions. Here’s what level 5 logging looks like for one single request:
20:49:34 /was-the-janitor-really-in-the-fugitive/ No wp-cache file exists or user agent rejected.
20:49:35 /was-the-janitor-really-in-the-fugitive/ In WP Cache Phase 2
21:49:35 /was-the-janitor-really-in-the-fugitive/ Setting up WordPress actions
21:49:35 /was-the-janitor-really-in-the-fugitive/ Created output buffer
21:49:35 /was-the-janitor-really-in-the-fugitive/ supercache dir: /www/wp-content/cache/supercache/ocaoimh.ie/was-the-janitor-really-in-the-fugitive/
21:49:35 /was-the-janitor-really-in-the-fugitive/ Output buffer callback
21:49:35 /was-the-janitor-really-in-the-fugitive/ supercache dir: /www/wp-content/cache/supercache/ocaoimh.ie/was-the-janitor-really-in-the-fugitive/
21:49:35 /was-the-janitor-really-in-the-fugitive/ Anonymous user detected. Only creating Supercache file.
21:49:35 /was-the-janitor-really-in-the-fugitive/ Gzipping buffer.
21:49:35 /was-the-janitor-really-in-the-fugitive/ Writing non-gzipped buffer to supercache file.
21:49:35 /was-the-janitor-really-in-the-fugitive/ Writing gzipped buffer to supercache file.
21:49:35 /was-the-janitor-really-in-the-fugitive/ Renamed temp supercache file to /www/wp-content/cache/supercache/ocaoimh.ie/was-the-janitor-really-in-the-fugitive/index.html
21:49:35 /was-the-janitor-really-in-the-fugitive/ Renamed temp supercache gz file to /www/wp-content/cache/supercache/ocaoimh.ie/was-the-janitor-really-in-the-fugitive/index.html.gz
21:49:35 /was-the-janitor-really-in-the-fugitive/ Sending buffer to browser
That’s a lot of text. Keep an eye on the load on your server because logging that much data on a busy server will add extra load. Start by limiting the logging to your own IP and test with various browsers.
The error messages that are normally sent to the browser about “missing html tag”, “404 error” and “blank page” are now only shown if debugging is enabled. This will hopefully avoid problems with PHP scripts that generate Javascript.
This release adds a new “late init” feature. This is only useful in half-on mode however. This causes the plugin to create the “cache key” and display the cached page at the end of the “init” action, after all WordPress include files and plugins have been loaded. This is very useful if your application needs to interrogate the database to modify the cache key. Activate it by setting $wp_super_cache_late_init to true in the config file.
Lots to digest and new toys to try out. Hope you enjoy this new version of the plugin!
Thanks for your work !
Thanks, I got problems with canonical/redirect as mentioned by DailyBlogTips and deactivated it. Now, it seems working properly with new released version, many thanks for your great effort. Tinh
Congrats on the latest release. A couple of things:
1) In the options page, this line has 2 links:
“Uninstall using the uninstall script to remove files and directories created by the plugin. (Please see readme.txt for instructions on uninstalling this script.)”
Both links expect to find wp-super-cache in the plugins directory. As I’m using WPMU, both result in 500s.
2) Aside from noticing the changes described in the changelog, how can I tell which version of WP Super Cache I have running? Could you add it somewhere in the options page? On WPMU, it’s not listed in the plugins page where I would normally find that info.
Keep up the great work!
i am always wondering why i only ever have only 1 super-cache page. i have never ever in the whole time I have been running the plugin had more than 1 super-cache page
That is really weird. I just glanced at mine I have 29 in WP Cache and 268 in WP-Super-Cache.
On side note, I hadn’t selected Super Cache Compression in the past noticed a nice difference after selecting it. Does anyone know if it will conflict with my server if I am enable Gzip compression on my server?
I’m interested in the answer to concurrent GZIP compression as well. I have it enabled for our entire server. I suppose that I could disable it for the WPMu directory and subs and let WP_Super_Cache do its thing as it sees fit but knowing the most efficient method would be welcome.
Wow, so many nice new features! Gonna upgrade this now and hopefully no problem exists on the new version 😀 Keep up the good work!
Donncha, now that Digg is dead it might be time to change your text to Tweeter proof. Just a thought.
hello,
i have a problem, wp super cache is working but the problem that it creates cache for each visit. for exemple if i visit a post after i refresh i will have an other date on “Cached page generated by WP-Super-Cache”
thank you
*sigh* you didn’t read the post above did you? This is probably why you’re seeing that.
Hi,
I got the same issue as hafield. I deleted the htaccess directives (from /.htaccess and /wp-content/cache/.htaccess, but the admin section of WP Super Cache still tells me the directives have been detected).
I even deleted the .htacess files to try and got the same message.
WPSC is fully on.
other strange behaviour, now that the directives have been deleted and with WPSC half-on, it seems to work (I’ve got “wp-cache file exists” and “Serving wp-cache static file” in the debug file). Thanks 🙂
Ever since the first time I tried using WP Super Cache, I’ve had trouble getting Twitter status posts to update on my site. Does anyone know if there is a Twitter plugin that displays the latest tweet that works with WP Super Cache out of the box? Maybe the Wickett Twitter Widget? That would be an incredibly awesome feature for any Twitter plugin, because I’ve seen a lot of people have issues with this. Thanks!
Hello!
I have a small WordPress MU with ~70 blogs, and if the user change anything your theme (widget, or theme settings), the cache don’t clear. How to make this functions? (if the user modifying widgets, the cache is clearing, and/or regenerate)
Thx.
It won’t regenerate unfortunately. I couldn’t find a useful hook to use. The only hack I could add is to clear the cache when someone POSTs data to the themes/widgets pages.
Hi!
I have some dynamic widgets and don’t want WP Super Cache to cache them. Is it possible somehow? Editing widget code is not a problem for me.
I was using your WP SuperCache plugin on WP site and noticed in the ‘newest cached pages’ sidebox listing that the url had a /blog/ in it, but this wordpress install is set up per WordPress article ‘Giving WordPress its own directory’ so /blog/ is in NO site urls. The actual cache links shown in your ‘Fresh Links’ box are fine.
So I tried WP supercache on a site where WP is installed in the root and ‘newest cached pages’ links in sidebox were correct.
I don’t think it affects anything operationally, but clicking on the links in the ‘newest cached pages’ sidebox could get a 404 error. WP can actually resolve some of them, which is kinda cool.
Hope that helps – stellablue
PS: had trouble searching wordpress forum…they need a big search box on topic page and plugin topic filter.
I can’t figure out a way to uninstall Wp Super Cache. I deactivated it and then tried deleting it but it gave this
“This file must be copied into the same directory where WordPress is installed. The file wp-load.php is in this directory”
I don’t want to break my website so, I did not do anything further. Can you please point me to some resource where I can learn to uninstall it?
Thanks
Hi,
I’m trying to cache 404 pages but am stuck. I’m using .9.9.9
Any ideas?
Thanks,
Daniel
Yup, the plugin doesn’t cache 404 pages on purpose in case the 404 error is fixed. If you want to change this look for “is_404()” in the code and remove those checks.