pinoyca

WP Super Cache, whether “on” or “half-on”, caches blog page renderings, so if you require that a blog page is rendered (e.g., the virtual() is run) on each blog page load, then you cannot have WPSC cache that blog page.

(I’m talking about any blog page here, not Pages.)

It’s the same situation as those “Most Visited Pages” plugins. WPSC cannot cache them because their code needs to be run on every blog page load.

The index\.php exclusion is for something else.

However, if you insist, there’s a mod you can do. You can make WPSC run your own PHP after it readfiles the page HTML from the ‘half-on’ cache. Add your PHP before the die(); on line 109 of wp-cache-phase1.php.

if ( $meta[ 'dynamic' ] ) {
	include($cache_file);
} else {
	readfile( $cache_file );  // <-- readfile from cache/
	}
// <-- add your PHP here. Go crazy.
die();

I hope this helps.

Unknownplanet, if you activate wp_cache_debug in your wp-content/wp-cache-config.php, then the plugin will send you emails whenever cleaning expired pages has taken too long and will give you a hint that you have too many cached pages and your expiry time is too long.

No emails, you’re fine.

Is there a way to specify what order I want them in?

Guys, use the widget_links_args filter. It’s very easy.

function widget_links_args_filter($args) {
	$args['orderby'] = 'rating';  // Sort links by rating
	$args['order'] = 'DESC';      // descending
	return $args;
}
add_filter('widget_links_args','widget_links_args_filter');

You can paste this code anywhere, such as your theme’s function.php.

I hope this helps.

it may be possible that the cpu overhead of parsing the cache is equal to the i/o overhead of calling the database if you are dealing with small queries. I’d be interested to get some input from others on this.

This is seen very easily with a define('SAVEQUERIES', true); (as per http://codex.wordpress.org/Editing_wp-config.php#Save_queries_for_analysis ) and a simple hack on db-module.php (and also to the copy in /wp-content/db.php). Add the following somewhere near line 720:

if ( defined('SAVEQUERIES') && SAVEQUERIES )
	$this->queries[] = array( $query, $this->timer_stop(), $this->get_caller(), "Cache hit" );

(Posterd, you may like to commit this hack to your code.)

Then load a page in two browser windows, one minute apart.

It will be evident that DB Cache shaves milliseconds on some queries such as queries with JOINs.

I posted the same question at http://wordpress.org/support/topic/306375 .

Next time when asking for help please elaborate. We’re not mind-readers. There are a thousand things that can go wrong but can be easily fixed.

1) Oui, monsieur.

2) dbc_clear only deletes expired cache files.

3) some queries and situations are automatically skipped:

// cache only frontside
if (
	defined('DOING_CRON') || strpos($_SERVER['REQUEST_URI'],'wp-admin') ||
	strpos($_SERVER['REQUEST_URI'],'wp-login') || strpos($_SERVER['REQUEST_URI'],'wp-register') || strpos($_SERVER['REQUEST_URI'],'wp-signup') ||
	preg_match("/\\s*(insert|delete|update|replace|alter|SET NAMES|FOUND_ROWS)/si",$query)
) $dbc_cachable = false;

// for hard queries
if (preg_match("/\\s*(JOIN | \* |\*\,)/si",$query)) $dbc_cachable = true;

3) Yes
4) No, see #2
5) See above conditions.

MySQL has limited or no support for differential backup, transactional log backup, mirroring, replication or log shipping. There is no “sync” option.