Tag Archives: wp super cache

WP Super Cache 1.4

WP Super Cache version 1.4 is out now. This release finally removes the mfunc, mclude and dynamic-cached-content tags as I warned about three months ago.

If your site uses that dynamic cached content functionality do not upgrade yet. There is a replacement dynamic cached content system but it’s not compatible so you’ll need to update your themes and helper plugins. It’s not difficult but there’s a lot to take in. I hope the example plugin and explanation in that post gets you most of the way there.

If you don’t use mfunc and it’s friends then you should upgrade immediately and it should be painless.

This release also has a few bug fixes and other features. It will now try to repair broken installs after a site migrates. It will update the wp-config.php and rebuild wp-content/advanced-cache.php. It will also delete tags and category cache files when a post publish status changes.

The shiny new dynamic content in WP Super Cache

With the next release of WP Super Cache in a day or two the long awaited move away from mfunc, mclude and friends will be complete.

This means that if you have been using mfunc, mclude or dynamic-cached-content the dynamic portions of your sites will go blank if you upgrade WP Super Cache without updating that dynamic code. This may seem complicated but there’s an example script included and detailed explanations below. A lot of effort was made to make this backwards compatible but unfortunately it wasn’t possible.

In their place is a new cacheaction filter called wpsc_cachedata and it’s sidekick wpsc_cachedata_safety. In the future when a site owner using WP Super Cache wants to make part of their website dynamic they will use those filters to modify pre-defined text strings and replace them with the data they want displayed to the end user. There’s an example script ready to be ripped apart to help you figure all this out.

There are two ways of using this:

  1. The dynamic content is the return value of a simple process, be it date() or any of the numerous get_*() functions in WordPress. That data can simply be slotted in place of the pre-defined text mentioned above.
  2. The more difficult bit comes when you need to use an output buffer to collect the data for display. Due to a limitation in PHP it’s impossible to run an output buffer in the callback function of another output buffer, which is when the wpsc_cachedata filter runs. We need to collect that data before the callback function executes.

The first way above is easy. Simply add a text string of random characters to your theme where you want the dynamic content to appear, then hook a function on to the wpsc_cachedata filter to str_replace() it with your dynamic content. These functions in this script do that:

  • dynamic_cache_test_filter()
  • dynamic_cache_test_template_tag()
  • dynamic_cache_test_init()

You’ll have to hook on to the wpsc_cachedata_safety action and return the numeral 1 to actually run the wpsc_cachedata filter. This is a fail safe used by the plugin to make sure things are ok when the filter runs.

Unfortunately if you want to use an output buffer it’s a lot harder. As stated above an output buffer can’t run in the callback function of another output buffer. This means you have to generate your dynamic content earlier in the PHP process.
This could be as easy as calling your dynamic content function (dynamic_output_buffer_test() in the example script) from the wp_footer action, or calling it from any action before shutdown, whichever is appropriate. You’ll also need to add a template tag of your own choosing to your theme.
Your dynamic content function will run just fine for cached pages, so after the new page has run it store the output in a constant or global variable that the same function can look for when the wpsc_cacheaction runs it. If it finds that information, it can do the search and replace of your template tag without running the output buffer again.
Some pages won’t run the dynamic content function however. This includes feeds and sitemaps. Those pages will generate a PHP error because the output buffer will try to run in the callback!

“PHP Fatal error: ob_start(): Cannot use output buffering in output buffering display handlers in…”

To stop that happening you must check that there’s text to shove in the cached page. That’s what happens in the function dynamic_output_buffer_test_safety() in the example script. It fires on the wpsc_cachedata_safety filter and returns the numeral 1 if successful.

Anatomy of an Output Buffer

I’m going to try and explain the output buffer functions in more detail here. They’re only example functions and if you spot a bug or can suggest improvements please do!

define( 'DYNAMIC_OUTPUT_BUFFER_TAG', '' ); // CHANGE THIS!

This is the string you add to your theme where your dynamic content will appear. The plugin will replace this string with the code generated by your dynamic content function.

function dynamic_output_buffer_test( &$cachedata = 0 ) {
	if ( defined( 'DYNAMIC_OB_TEXT' ) )
		return str_replace( DYNAMIC_OUTPUT_BUFFER_TAG, DYNAMIC_OB_TEXT, $cachedata );
	ob_start();
	// call the sidebar function, do something dynamic
	echo "<p>This is a test. The current time on the server is: " . date( 'H:i:s' ) . "</p>";
	$text = ob_get_contents();
	ob_end_clean();

	if ( $cachedata === 0 ) // called directly from the theme so store the output
		define( 'DYNAMIC_OB_TEXT', $text );
	else // called via the wpsc_cachedata filter. We only get here in cached pages in wp-cache-phase1.php
		return str_replace( DYNAMIC_OUTPUT_BUFFER_TAG, $text, $cachedata );

}
add_cacheaction( 'wpsc_cachedata', 'dynamic_output_buffer_test' );
  • 1. dynamic_output_buffer_test() is the function that will generate the dynamic content inserted into the cached page.
  • 2-3. DYNAMIC_OB_TEXT stores the previous output of this function. If it’s set that means we’re in the wpsc_cachedata filter and should insert it into the cached page and return it.
  • 4-8. This creates the output buffer, echoes a string with the current time and copies the buffer into a variable called $text before closing the output buffer.
  • 10-13. This is how we decide to return data. If $cachedata is 0 that means this function was called from the theme so we should define the constant DYNAMIC_OB_TEXT for later use. Otherwise, we must be dealing with an already cached page so insert the dynamic content into the page and return it.
  • 16. Add the dynamic_output_buffer_test() function to the wpsc_cachedata action. “add_cacheaction” is used as it loads before the regular WordPress action code loads.
function dynamic_output_buffer_test_safety( $safety ) {
	if ( defined( 'DYNAMIC_OB_TEXT' ) )
		return 1; // ready to replace tag with dynamic content.
	else
		return 0; // tag cannot be replaced.
}
add_cacheaction( 'wpsc_cachedata_safety', 'dynamic_output_buffer_test_safety' );
  • 1-6. dynamic_output_buffer_test_safety() is a function that checks if dynamic content was generated correctly. If that constant is not defined the output buffer will run within the callback function of the main WP Super Cache output buffer and generate a PHP error.
  • 7. Add the wpsc_cachedata_safety() function to the dynamic_output_buffer_test_safety action.

sidebar.php

As an example, if I wanted to display my dynamic content in the sidebar of my blog I would load sidebar.php in my theme’s directory and add the following code.

if ( function_exists( 'dynamic_output_buffer_test' ) )
    dynamic_output_buffer_test();
?>WORDPRESS ROCKS THE WORLD<?php

I had previously edited the example script, uncommented it and changed the appropriate tag:

define( 'DYNAMIC_OUTPUT_BUFFER_TAG', 'WORDPRESS ROCKS THE WORLD' ); // CHANGE THIS!

Final Note and Download Link

Please grab the development version of the plugin and try it on a staging server before you put it live. Feedback would be appreciated!

Warning! Keep the tags you use secret. You don’t want someone leaving a comment on your blog with that string! Do not use the same function names or constant names as in this post or example script. They’re in this very public post. Someone is bound to use them and cause you problems when you install their plugin.

Finally, barring any last minute major bugs this version of WP Super Cache will be released on Wednesday. Be careful upgrading. Pass the word around if you know someone is using mfunc as their site will stop working!

mfunc in WP Super Cache 1.4 and beyond

WP Super Cache is a full page caching plugin for WordPress. It creates static pages that are served quickly by the web server. Sometimes however, users still want parts of their pages to remain dynamic and be non static. That’s where mfunc, mclude and dynamic-cached-content came in.

Security

Unfortunately it was reported recently that remote visitors to sites using the plugin could execute any code they like by simply leaving a comment containing the right mfunc code. These functions are now disabled by default, and a filter removes harmful code from comments but if enabled they pose a security risk. I considered adding a security code to the mfunc tag but unfortunately the best way of dealing with this problem is to replace it completely with something different. The next release of the plugin will do away with mfunc, mclude and dynamic-cached-content entirely.

The new dynamic cache system

The development version of WP Super Cache has already been updated with a new filter based system. It uses a cacheaction filter called “wpsc_cachedata”. This filter runs when a page is first cached and also when a cached page is subsequently served. It also runs when caching is disabled for known users, something that has always been broken when using mfunc.

Almost all the data that is displayed on your website will run through the cacheaction filter “wpsc_cachedata”. When a page is first cached, the data that is shown to the first visitor of that page goes through that filter. The second visitor gets a cached page and that page too goes through the filter. What this allows us to do is define a template tag (or more than one) that a function hooked on that filter can search for in the filtered data. It can replace that tag with some other text, usually derived from code that has to run on each request. The visitor is then shown the page with the replaced tag.

Example code

The readme.txt hasn’t been updated yet but an example plugin, dynamic-cache-test.php is included in WP Super Cache. It’s fairly simple but it’s documented so it should be easy enough to follow. A template tag is inserted at the bottom of the page using the wp_footer action, and a filter then replaces that tag with text and the current server time. That test plugin replaces mfunc code that would look like this, excluding the necessary code to hook on to wp_footer and print it.

<!--mfunc echo "<!-- Hello world at " . date( 'H:i:s' ) . " -->"; -->
<?php echo "<!-- Hello world at " . date( 'H:i:s' ) . " -->" ?>
<!--/mfunc-->

WP Super Cache has it’s own action hooks using add_cacheaction() and do_cacheaction(), and work like WordPress actions or filters. The reason the plugin needs those is because they are available before WordPress is loaded. They allow developers to hook into the plugin from the very start of the PHP process and modify how it works using plugins. Those plugins are usually copied into wp-super-cache/plugins/ but I encourage you to move that directory elsewhere because when WordPress updates the plugin it will delete any custom changes you make. The next time a new version of WP Super Cache comes out WordPress will delete the wp-super-cache folder, replacing it with the new update. In your wp-config.php set $wp_cache_plugins_dir to the location of the new plugins directory.

If you use this filter system in your own plugin for distribution do not ever define the template tag for the user. Let the user decide what it is or generate a random tag and save it somewhere. It’s important to keep the tag secret so visitors cannot trigger your function maliciously. It is however better than the remote user running any code they like as was the case with mfunc!

I hope to release a new version with this code late next week. If your plugin or site uses mfunc please download the development version on a test server and start the process of updating your code.
On the other hand, if you don’t want to update your mfunc tags you could try W3 Total Cache instead. It uses the mfunc tag with a secret code.

WP Super Cache 1.3.2

WP Super Cache is a full page caching plugin for WordPress that will speed up your website.

This is a security release and any users of the plugin should update as soon as possible. This release and the last 2 (1.3 and 1.3.1) address the following issues:

  • A visitor to a website using WP Super Cache can remotely execute code by way of a specially crafted comment left on the blog. The comment may even be moderated and it will still cause a problem. If you allow untrusted user content on your site through other means it should also be filtered in a similar way. See the function no_mfunc_in_comments for the existing filter. This will be mitigated in the next release by using a security keyword in the mfunc/mclude/dynamic-cached-content tag.
  • An XSS vulnerability was found in the plugins settings page of the plugin. This has been fixed as well.

The dynamic cached content features are now disabled by default as they should really have been a long time ago. This was announced in the Upgrade Notice of the previous release so hopefully site owners will be prepared for it. If you depend on this feature you can enable it again on the Advanced Settings page. I would encourage you to use Javascript instead for any dynamic features or use a short cache expiration time.

Support for the mobile theme in Jetpack has been added in this release by way of a helper plugin. If you enable this feature in Jetpack you should visit the Plugins tab of WP Super Cache and enable the Jetpack plugin there. Caching will be changed to PHP mode, and mobile device support enabled but you may have to manually remove the WP Super Cache mod_rewrite rules in the .htaccess at the root of your site.

I would like to thank WordPress.org user kisscsaby for finding the mfunc problem in WP Super Cache and W3 Total Cache and Frank Goossens for his help fixing it.

Edit: I should have stated this above. I did not know about the issue with mfunc until 3 weeks after kisscsaby posted it to a public forum. I don’t read every post on the support forum unfortunately and the user did not email me. I released version 1.3 within a day of hearing about the problem. Unfortunately the XSS vulnerability became known 24 hours after that requiring another release within 36 hours of the previous one. When it became clear that mfunc could be exploited still I released version 1.3.2

I’m leaning towards removing the mfunc/mclude/dynamic-cached-content feature completely. It’s only used by a tiny minority of users (who will be inconvenienced, sorry) but it’s dangerous code to have in the plugin.

WP Super Cache 1.2

UPDATE! I have just updated the plugin version number to 1.2. Thanks to everyone who tested it!

A new version of WP Super Cache is almost out and here are the changes in this full page caching plugin for WordPress.

OH! Hang on. Almost out? Yeah. I’m going to release it tomorrow but I would love a couple of hardy folks to try it first. People on the forums have been using the development version for several weeks without incident but I would really appreciate it if a few more tried it before the general public gets it. You know what to do, I don’t need to explain. Here’s wp-super-cache.zip. This is the version running on this very site right now and it’s very stable. Go at it! I’ll update this post in the morning, UTC. Thanks.

So, those changes eh?

  • Garbage collection of old cache files is significantly improved. I added a scheduled job that keeps an eye on things and restarts the job if necessary. Also, if you enable caching from the Easy page garbage collection will be enabled too.
  • Editors can delete single cached files from the admin bar now. (thread)
  • Fixed the cached page counter on the settings page (thread)
  • Some sites that updated to 1.0 experienced too much garbage collection. There are still stragglers out there who haven’t upgraded but that’s fixed now! (thread)
  • Supercached mobile files are now used as there was a tiny little typo that needed fixing. (thread)
  • If your site is in a directory and you saw problems updating a page then that should be fixed now. (thread)
  • The deactivate hook has been changed so your configuration isn’t hosed when you upgrade. Unfortunately this will only happen after you do this upgrade.
  • Some sites use custom cookies with the LOGGED_IN_COOKIE constant. Added support for that.
  • Added support for WPTouch Pro, but it appears to be flaky still. Anyone have time to work on that? I don’t.
  • Some sites had problems with scheduled posts. For some reason the plugin thought the post was in draft mode and then because it only checked the same post once, when the post magically became published the cache wasn’t cleared. That’s fixed, thanks to the debug logging of several patient users.
  • And more bug fixes and translation updates.

If you have problems the first place to look should be the forums (or try here too where things lived for a long time). Chances are someone else had the same issue before you and maybe they fixed it.

WP Super cache 1.1

This is a bugfix release of the full page caching plugin WP Super Cache for WordPress.

Not much has changed in the week or so since I asked for testers but in case you missed that post here are the changes since 1.0:

  • Use $_SERVER[ 'SERVER_NAME' ] to create cache directories. No more non existant blogs appearing in your cache supercache and blogs folders.
  • Only create blogs cached directories if valid requests and blogs exist.
  • Only clear current blog’s cache files if navigation menu is modified
  • Added clean_post_cache action to clear cache on post actions
  • Removed garbage collection details on Contents tab
  • Added wp_cache_check_mobile cacheaction filter to shortcircuit mobile device check.
  • Don’t delete cache files for draft posts
  • Added action on wp_trash_post to clear the cache when trashed posts are deleted
  • Show a warning when 304 browser caching is disabled (because mod_rewrite caching is on)
  • New check for safe mode if using less that PHP 5.3.0
  • Added wp_supercache_remove_cookies filter to disable anonymous browsing mode.
  • Fixed garbage collection schedule dropdown
  • Fixed preload problem clearing site’s cache on “page on front” sites.
  • Fix for PHP variable not defined warnings
  • Fixed problem refreshing cache when comments made as siteurl() sometimes didn’t work
  • Preloading of taxonomies is now optional
  • Domain mapping fixes.
  • Better support for https sites. Remove https:// to get cache paths.
  • Added AddDefaultCharset .htaccess rule back in and added an option to remove it if required.
  • Added multisite plugin that adds a “Cached” column to Network->Sites to disable caching on a per site basis.
  • Added WPTouch plugin to modify browser and prefix list in mobile detection code. Added support for that plugin’s exclude list.
  • Fixed cache tester
  • Filter the tags that are used to detect end-of-page using the wp_cache_eof_tags filter.
  • Removed debug level from logging as it wasn’t helpful.
  • Removed mention of wp-minify.

As ever, the support forum is the best place to go for help as I monitor it all the time. Before you post there use Google to search for any error strings and use the debug system in the plugin as it will probably tell you what’s going on.

Super Cache for the Weekend

WP Super Cache 1.0 came out several months ago and while it worked fine for most people there’s always room for improvement and bug fixes. Here are some of the bug fixes and improvements coming in the next version which I plan on releasing next week.

There are a lot of changes there so if you have a self hosted blog I would really appreciate if you download the development version, wp-super-cache.zip and install it in your plugins folder.

  • Use $_SERVER[ 'SERVER_NAME' ] to create cache directories.
  • Only create blogs cached directories if valid requests and blogs exist.
  • Only clear current blog’s cache files if navigation menu is modified
  • Added clean_post_cache action to clear cache on post actions
  • Removed garbage collection details on Contents tab
  • Added wp_cache_check_mobile cacheaction filter to shortcircuit mobile device check.
  • Don’t delete cache files for draft posts
  • Added action on wp_trash_post to clear the cache when trashed posts are deleted
  • Show a warning when 304 browser caching is disabled (because mod_rewrite caching is on)
  • New check for safe mode if using less that PHP 5.3.0
  • Added wp_supercache_remove_cookies filter to disable anonymous browsing mode.
  • Fixed garbage collection schedule dropdown
  • Fixed preload problem clearing site’s cache on “page on front” sites.
  • Fix for PHP variable not defined warnings
  • Fixed problem refreshing cache when comments made as siteurl() sometimes didn’t work
  • Preloading of taxonomies is now optional
  • Domain mapping fixes.
  • Better support for https sites. Remove https:// to get cache paths.
  • Added AddDefaultCharset .htaccess rule back in and added an option to remove it if required.
  • Added multisite plugin that adds a “Cached” column to Network->Sites to disable caching on a per site basis.
  • Added WPTouch plugin to modify browser and prefix list in mobile detection code. Added support for that plugin’s exclude list.
  • Fixed cache tester
  • Filter the tags that are used to detect end-of-page using the wp_cache_eof_tags filter.

A cache directory is a temporary directory

WOAH! Do not put symlinks to your uploaded files in a temporary cache directory. Nginx users running WordPress should beware if they followed these instructions and put a symlink to uploaded files in the wp-content/cache/ directory. I’m going to rewrite that page right now suggesting they use a different directory, possibly wp-content/uploads/ or maybe wp-content/files/.

WP Super Cache (and I presume other caching plugins) will delete everything in the cache directory. It’s like putting important files in /tmp/ where files are routinely cleaned out on reboot.

My replies on the thread above might paint me as a cold heartless bastard but I am sorry those websites suffered data loss. However I’m shocked that they put links to uploaded images in a folder containing temporary files!

Edit (20 minutes later): the codex page has been updated, thanks Westi for your help. It now recommends using wp-content/ms-filemap/ rather than wp-content/cache/

WP-Super-Cache: bug fixing and PHP object destruction

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.

WP Super Cache 1.0

WP Super Cache is a fast page caching plugin for WordPress that can significantly speed up websites.

The first release of this plugin was in September 2009 so this has been a bit too long in the making. Back then the main caching plugin was WP Cache, which this plugin is based on, but now there are quite a few including W3 Total Cache, Hypercache, Quick Cache and many more.

Version 1.0 is an incremental upgrade from the previous release but it has a number of bugfixes and new features:

  1. The all new scheduler and admin bar link should please many people, especially those who want to clear the cache on their site at particular times. The “Delete Cache” admin bar link is something people have been asking about for as long as WordPress has had that bar!
  2. You can preload categories and taxonomies although this hasn’t really been tested as well as I’d like. It works for me but YMMV.
  3. There’s better support for mobile and https users now. Mobile support should scale a lot more than previously.
  4. The cache tester is fixed now and the plugin traps as many errors as possible. It’ll also spit out some helpful text if there is a problem. 99% of the time it’s because the server can’t request a page from itself.
  5. At the risk of annoying users who comment on your site you can make them appear to be anonymous users which will drastically help your server if they like commenting a lot. Unfortunately it stops the comment form populating with their details so it might be worth using an external comment system like Intense Debate or Disqus!
  6. The Advanced Settings page now lists a “do not cache page” secret key. Use this key to view any page of your site uncached.
  7. The cache file listing and delete links should work again now.
  8. And many many more bug fixes.

Once you upgrade go visit the settings page and check out what’s new there. The upgrade worked fine for me, but there’s no harm looking. Pay close attention to the new garbage collector. The scheduler is rather powerful and flexible so it’s worth setting up right.

If you have any problems please leave a comment here or use the support forum.