Hey Milan,
Love the GDSR plugin btw. Can’t wait for 2.0!
You’ll want to put,
define('DOING_CRON', true);
at the beginning of any cron script you run. I had a tough time finding this. Must be one of those, “we’ll leave it out so people pay for support” type of things. Hey, you get what you pay for!
😉
I thought that WP does that for any cron job. Thanks, I will try this.
GDSR 2.0 will be great, I am having fun making it, and that says a lot.
Milan, did @john-michael’s suggestion work for you?
Nope. As longs as the database and object cache are active cron is not running as it should. It’s not starting in set time, and all jobs still use W3 database object.
M
(@infolegal)
I have issues with the crons as well. I’ve installed a plugin (crontrol) to see what they are doing and I see these two lines:
w3_pgcache_prime [] 11/29/10 12:08:40 (1 minute 49 seconds) 1800 (30 minutes)
w3_pgcache_prime [470] 11/29/10 12:29:44 (22 minutes 53 seconds) Non-repeating
Not sure why there are two crons for the same operation, out of which one is non-repeating. Also, this morning the argument for the second entry was 340. What does that mean?
Usually, I wouldn’t ask about crons, but this time they are interfering with the post publishing in the admin (it gets really slow or even stuck).
I’m on a shared server at HG, if that helps.
Many thanks in advance for any suggestions.
@milan,
Try un checking all the settings for auto prime cache and increase the garbage collection intervals.
I have also solved cron problems by manually deleting the content from cron entry in the wp_options table which will force WordPress rebuild it.