Template Caching

[Entriple]

So here is the basic situation. Today has had a lot of template changes here and there. In one particular case the styleid is being overridden by a plugin for various particular pages. Today, randomly, the entire page showed blank. I disabled vBO and the page worked, I enabled it and it died again. I cleared the cache and it worked again.

This leads me to believe there is one of one potential bug. The template cache is not being flushed correctly when a template it updated. I can't reproduce this at this time unfortunately as I don't particularly like the idea of breaking my forum again just to locate the bug. For whatever reason it seems like the wrong style id was cached, or a non-existent template was cached.

 

[Entriple]

After clearing the cache and it working, approximately an hour later it broke again. This time I've disabled the mod entirely.

 

[Entriple]

Just isolated the bug more, it's in 'Cache Styles' NOT 'Cache Templates',

 

[Entriple]

Okay, it appears the styleid that is saved isn't always the one that it should be saving. Here is my diff:

Index: cacher_style.php
===================================================================
--- cacher_style.php	(revision 184)
+++ cacher_style.php	(working copy)
@@ -35,8 +35,12 @@
 		LIMIT 1
 	");
 
-	vb_optimise::$cache->set('style_' . $argumentb, serialize($argument));
-
-	vb_optimise::report('Cached Style (ID: ' . $argumentb . ')');
+	if ($argumentb == $argument['styleid'])
+	{
+		vb_optimise::$cache->set('style_' . $argumentb, serialize($argument));
+		vb_optimise::report('Cached Style (ID: ' . $argumentb . ')');
+	}
+	else
+		vb_optimise::report('Style Cache Mismatch (ID: ' . $argumentb . ' ID: '.$argument['styleid'].')');
 }
 ?>

 

[Entriple]

Just found the trigger of this too. If for some reason you end-up with a template that not all users are allowed to select, and one of those users triggers the cache, the wrong styleid will be returned from the query and mess up the style for the rest of the users. Therefore there is a slightly different fix to this necessary. Here is my less than pretty fix that could be a little more efficient:

if (($styleinfo = vb_optimise::$cache->get('style_' . $argumentb)) !== false)
{
	$argument = unserialize($styleinfo);
	if (!($vbulletin->userinfo['permissions']['adminpermissions'] & $vbulletin->bf_ugp_adminpermissions['cancontrolpanel']) AND !$argumentc && $argument['userselect'] != '1')
	{
		unset($styleinfo);
		if (($styleinfo = vb_optimise::$cache->get('style_' . $vbulletin->options['styleid'])) !== false)
		{
			$argument = unserialize($styleinfo);
		}
		else
			$argument = null;
	}
	unset($styleinfo);

	vb_optimise::report('Fetched Style from cache (ID: ' . $argument['styleid'] . ')');
	vb_optimise::stat(1);
}
else
{
	$argument = $vbulletin->db->query_first_slave("
		SELECT *
		FROM " . TABLE_PREFIX . "style
		WHERE (styleid = $argumentb" . iif(!($vbulletin->userinfo['permissions']['adminpermissions'] & $vbulletin->bf_ugp_adminpermissions['cancontrolpanel']) AND !$argumentc, ' AND userselect = 1') . ")
			OR styleid = " . $vbulletin->options['styleid'] . "
		ORDER BY styleid " . iif($argumentb > $vbulletin->options['styleid'], 'DESC', 'ASC') . "
		LIMIT 1
	");

	vb_optimise::$cache->set('style_' . $argument['styleid'], serialize($argument));
	vb_optimise::report('Cached Style (ID: ' . $argument['styleid'] . ')');
}
?>

 

[Deceptor]

Thanks for the info Entriple, I'll make the suggested changes you've brought forward to check style permissions before serving cache/saving cache