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...
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 @@...
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...
I've got a lot of custom modifications. My registration system is completely recoded from scratch, and yeah, it was definitely being guest cached. I've since put in a temp patch for a bunch of different scripts for THIS_SCRIPT == cron/reg/etc... and I know for a fact cron broke as soon as the...
Actually, while I think about it, vBO should not be guest caching any script that isn't whitelisted in the first place, at least then it can't unintentionally screw things up.
Large communities should not be using image based cron's as they are very unreliable. Instead they should be using something like this http://www.vbulletin.org/forum/showthread.php?t=164477 which does break because of your code.
When the cron script is executed by a guest (or cronjob) it becomes guest cached. This can be fixed by adding the following to the init_startup plugin.
if (THIS_SCRIPT == 'cron')
$vbulletin->options['vbo_online'] = false;
3.8
ajax
bug
cache
caching
cron
different
disable
error
failed
fatal error
forum
full
full page caching
guest cache
html
image
modification
optimise
options
permissions
php
post
ten
timestamp
url
user
vboptimise
vbulletin
version