Cron Handling

[Entriple]

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;

 

[Deceptor]

Not really a bug, all cron scripts are executed with a unique parameter (r=timestamp), and guest caching always ensures the input to the page matches one already stored before serving cache.

 

[Entriple]

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.

 

[Entriple]

Also just noticed, not having a simple method to disable the script per plugin has messed up my registrations.

 

[Entriple]

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.

 

[Deceptor]

Entriple - Even if guest cache "initialised" it's a two-stage system, in order to cache print_output() (vbulletin stock function within functions.php) needs to be called with HTML output - this is the function that's called on every page that spits out HTML. No cron job ever uses this functions so no data within cron (or any other systematic scripts, like AJAX actions and such) are ever cached by the system - if there's no cache found execution will run as normal (uncached).

I'll take a look at the registrations, they are normally entered via POST normally and no script with POST data is cached, do you have terms and conditions disabled or any setting/modification that makes registrations jump straight to the form where the user inputs username/password/etc..?

Appreciate the feedback

 

[Entriple]

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 script was installed as my scheduled task log stopped printing anything beyond that install time.

 

[Deceptor]

Understood Thanks for the info, I think the best approach here is to provide an option within vBO configurations to add scripts to cache whitelist so in situations like yours (heavy modifications) they can be fixed, as for stock installations I'll include some default scripts just to be on the safe side (like cron/reg/login)

 

[snakev]

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.

I installed this plugin, because i see very interesting and never seen before.

But i have one problem with vBOptimise when i run the cronjob:
PHP Fatal error: require_once(): Failed opening required '/htdocs/domain/vboptimise/core/class_vboptimise.php' (include_path='.:') in /htdocs/domain/includes/init.php(304) : eval()'d code on line 97

I have Guest Full Page Caching off.

Any workaround for this?

 

[Deceptor]

snakev - I presume /htdocs/domain/ is your root directory (as includes/ is next), so you should have htdocs/domain/vboptimise/core/class_vboptimise.php

I've installed the mod myself but not getting any inclusion errors myself.

 

[snakev]

When i disable vB Optimise it works, so the problem is in vB Optimise, i'm using vB 3.8.5 in what version are you testing?

 

[Deceptor]

Tested on both vB 3.8.x/vB4.0.x, did you confirm this file is in this location: /htdocs/domain/vboptimise/core/class_vboptimise.php ?

 

[snakev]

I fixed it, it was a problem with file permissions.

 

[Deceptor]

Gotcha, thanks for letting us know