If you use the WPTouch mobile plugin, or the preload function in my caching plugin, or noticed that annoying but random and (thankfully) rare “front page isn’t showing my front page” bug then you might like to try the development version of WP-Super-Cache located on this page.
Mobile plugins need to tell WP Super Cache what user agents they support. I documented the filters you can use (“cached_mobile_browsers” and others) to do this but I don’t think they’ve been used by any plugin. It’s not hard to do and I added code that checks for WPTouch so when you visit the WP Super Cache settings page it updates the mobile user agents. So far it works for me but please feel free to view this site on your mobile phone and tell me if it looks ok! I also added support for the theme switcher in WPTouch based on code posted on the wporg forum.
It appears that the “random post on the front page” problem is a side effect of how PHP works. WordPress incorrectly reported that the current page wasn’t a search page, even though it was. I put an extra bit of code in checking if $_GET is non empty and that fixed it, so far.
Just in case anyone else is interested, this is why is_search() fails randomly when run during PHP shutdown. When a PHP process shuts down it starts by killing off objects. Unfortunately this happens before PHP stops executing your code, something that changed after PHP4.
Anything that runs when the output buffer finishes or that is registered by register_shutdown_function() better not depend on objects or classes. That means no using $wpdb, the object cache may disappear or to be completely paranoid don’t expect $wp_query to be around either! The functions is_search(), is_feed() and other related WordPress functions depend on $wp_query so you should cache the values of those functions earlier in the process. I’m thinking of hooking into wp_head but that depends on the theme unfortunately. Not every theme uses that action.
Many years ago I changed the format of the cache “meta file” from an object to an array because of the way the PHP desctruction process works. More recently, but still two years ago I had to remove all calls to get_option() and update_option() in the output buffer handler because occasionally people saw the error, “Call to a member function get() on a non-object in cache.php” in their error log. The object cache object had been destroyed by PHP! That was a right pain to figure out as the code looked perfect yet didn’t work right some of the time.
To help figure out problems I’ve added a lot more debugging to the plugin too. If $wp_query disappears it’ll appear in your debug log, and preloading will generate a lot more messages now.
Next up is caching is_search(), is_feed(), is_single() etc. Where should those be cached? The “init” action is too early for is_search and probably others but I don’t want to depend on actions that may not be in a theme.
? i have quite a few sites using the “WP Super Cache” plug-in.
and yes, I continue to get the “infamous” front page error
will the new plug-in update cure what ails me?i keep going back to sites thinking i entered something wrong but other sites, set up the same way do NOT give me the error…please straighten ME out
thanks
mconroy
Would like your opinion on my .htaccess SuperCache changes. I’ve seen quite a bit of performance improvement on my site with this: Check it out at http://www.r3now.com
P.S. I would like your opinion or critique of this. Let me know what you think…
# BEGIN R3Now supercache
ForceType text/html
FileETag None
AddEncoding gzip .gz
AddType text/html .gz
SetEnvIfNoCase Request_URI \.gz$ no-gzip
BrowserMatch ^Mozilla/4 gzip-only-text/html
BrowserMatch ^Mozilla/4\.0[678] no-gzip
BrowserMatch \bMSIE !no-gzip !gzip-only-text/html
BrowserMatch \bMSI[E] !no-gzip !gzip-only-text/html
AddOutputFilterByType DEFLATE text/css application/x-javascript text/html text/richtext text/plain image/x-icon
# 12/09/2011 Change standard supercache settings for performance
# supercache header cookie rules are below under FilesMatch directive
Header append Vary User-Agent env=!dont-vary
# Header set Vary “Accept-Encoding, Cookie”
# Header set Cache-Control ‘max-age=3, must-revalidate’
# Force expiration dates on various site objects to reduce checking.
ExpiresActive On
ExpiresByType text/html A43200
ExpiresByType text/css A86400
ExpiresByType application/x-javascript A86400
ExpiresByType image/gif A31536000
ExpiresByType image/jpeg A31536000
ExpiresByType image/png A31536000
ExpiresByType image/x-icon A31536000
ExpiresByType application/pdf A31536000
ExpiresByType text/plain A86400
ExpiresByType application/x-gzip A43200
# ExpiresByType application/zip A43200
# Set cache settings for unchanged objects
# Revalidate every 180 days
Header set Cache-Control “max-age=15552000, public”
FileETag MTime Size
# Revalidate every 7 days
Header set Cache-Control “max-age=604800, must-revalidate”
# Revalidate every day
Header set Vary “Accept-Encoding, Cookie”
Header set Cache-Control “max-age=86400, must-revalidate”
FileETag MTime Size
# END R3Now supercache
Those are pretty good rules, although it’s been a while since I looked at that sort of thing so I can’t say how effective they’ll all be.
You should use the ‘wp’ hook for this.
template_redirectis probably what you want.Thanks Mark and John, I’ll give both of those a go and test each of the functions!
Cached the output of those is_* functions, hopefully that’ll be an end to those weird bugs!
Just added multisite support with a “Cached” column on the Network Admin Sites page. Quite a few people have asked about that over the years..
get this error, tried update, tried debug, can’t get rid of the error Warning! WP Super Cache caching broken! The script advanced-cache.php could not load wp-cache-phase1.php.
Please edit /home/xxxx/public_html/xxxx.com/wp-content/advanced-cache.php and make sure the path to /home/xxxx/public_html/xxxx.com/wp-content/plugins/wp-super-cache/wp-cache-phase1.php is correct.
Outbackjack – Edit your advanced-cache.php and make sure the path in the code to wp-cache-phase1.php is correct! The correct path is in the error message. Make sure that file exists too in case something went wrong during the update.
Not sure where this should go but I have a suggestion for a dramatic enhancement and improvement for WP Super Cache.
Why not work directly with the developers who maintain some of the supplemental plugins so that you can manage them all from your WP Super Cache interface?
You could add the settings into your plugins tab for:
DB Cache Reloaded
WP Minify
WP Widget Cache
This would provide you a comprehensive and overall caching solution while allowing those other developers to continue to maintain their own plugins. In other words, let them focus on their specialties but work together to create a powerful overall caching solution.
It would be a great to have a selection button for the others such as
Install — Activate — Settings
You could also add a set of selection buttons on your Contents tab to clear each of the cache plugin info… Then when troubleshooting, updating, developing, etc., all of the different plugins could be cleared with one button while still keeping their own separate settings through an iFrame window or some other integrated mechanism on your Plugins tab.
Just a thought to take this to the next level and create a great direct competitor to W3 Total Cache which I do not believe is as efficient as all of these plugins together.
Bill – that’s a great idea and could be implemented easily. The tabs in the plugin are run through a filter (AFAIR) and the external plugin could show a simplified interface perhaps. Or I could try supporting them if I detected they were installed..
Thanks for the complement too!
I just installed the dev version and was glad, that it has a native support of wptouch now. But together with the support of wptoch I found out, that Super Cache supports only the fee version and not the pro version of Wptouch.
It would be great, also to support the pro version. I can’t imagine, that there are many differences between the versions and the way they work with Super Cache and maybe it might be just the different pathname of the pro-plugin which is “wptouch-pro” instead of “wptouch”.
If that’s the only difference between the plugins then it should be easy to support the pro version.