Announcement

Collapse
No announcement yet.

Promotions scheduled task problem

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Lynne
    replied
    Originally posted by Freddie Bingham View Post
    Well the 3.0.12 code looks to be a bug as $timerun should be larger than TIMENOW so it results in getting all users. That just happens to be what you are wanting.

    The 3.6.8 code only retrieves the users that have been active since the previous run.
    Yep, it does look that way. Now I need to decide if I should leave it how it's supposed to work or 'fix' it to be 'wrong'.

    Leave a comment:


  • Freddie Bingham
    replied
    Well the 3.0.12 code looks to be a bug as $timerun should be larger than TIMENOW so it results in getting all users. That just happens to be what you are wanting.

    The 3.6.8 code only retrieves the users that have been active since the previous run.

    Leave a comment:


  • Lynne
    replied
    Originally posted by Wayne Luke View Post
    Manually running the cron from the Admin CP does not have the time limit on users processed. It could be that your scheduled tasks are not processing completely or another is failing to complete. Only one scheduled task is ran per page load to prevent a large burden on a single user.

    What are the last run times for your other scheduled tasks? Are they all accurate? If not, we might need to look at them as well.
    Originally posted by Freddie Bingham View Post
    My memory is that promotions have always had the last login restriction.
    I just looked at my vb3.0.12 promotions.php script and the 3.6.8 one and the line has changed:

    3.0.12:
    Code:
    iif(VB_AREA != 'AdminCP', "WHERE user.lastactivity >= " . (TIMENOW - $nextrun))
    3.6.8:
    Code:
    iif(VB_AREA != 'AdminCP', "WHERE user.lastactivity >= " . (TIMENOW - ($nextrun - TIMENOW)))
    I looked through my old User Promotion Logs and it seemed to be moving the users pretty steadily to the new usergroup prior to the upgrade, so I'm thinking that this line change is the difference.

    Leave a comment:


  • Freddie Bingham
    replied
    My memory is that promotions have always had the last login restriction.

    Leave a comment:


  • Lynne
    replied
    Originally posted by Wayne Luke View Post
    Manually running the cron from the Admin CP does not have the time limit on users processed. It could be that your scheduled tasks are not processing completely or another is failing to complete. Only one scheduled task is ran per page load to prevent a large burden on a single user.

    What are the last run times for your other scheduled tasks? Are they all accurate? If not, we might need to look at them as well.
    I think this is what is going on - if I run the script by hitting Run Now, the time limit is ignored and all users that meet the criteria are moved to the new usergroup. However, if I let the script run through cron, it only processes users who have logged in since the last time the script was run. So, even though several users have met the criteria of having been registered for x days, they don't get moved to the new usergroup unless they have logged on since they met the criteria. I'm not sure, but I think this may have been changed since 3.0.12 which I was running up until last Monday. It looks like I could just remove the iif statement in the query to have it how I want it.

    All the other vbulletin supplied cron jobs are running fine. (Notice the vbulletin qualifier... I still have to rewrite a few of my own cron jobs to be 3.6 compliant. )

    Thanks to all of you who replied. I continue to think that vbulletin support is excellent!

    Leave a comment:


  • Andy Huang
    replied
    I don't believe the cronadmin script performs it any differently; here's how cronadmin triggers the cron job for any job:
    Code:
    		echo "<p><b>" . (isset($vbphrase['task_' . $nextitem['varname'] . '_title']) ? htmlspecialchars_uni($vbphrase['task_' . $nextitem['varname'] . '_title']) : $nextitem['varname']) . " </b></p>";
    		require_once(DIR . '/includes/functions_cron.php');
    		include_once(DIR . '/' . $nextitem['filename']);
    		echo "<p>$vbphrase[done]</p>";
    cron.php, the image, calls exec_cron, which triggers the action like so:
    Code:
    		if ($nextrun = build_cron_item($nextitem['cronid'], $nextitem))
    		{
    			include_once(DIR . '/' . $nextitem['filename']);
    		}
    It would appear that what it does is it includes the same procedures as the cron image would trigger, so it should perform everything the same.

    What I would recommend, if you're absolutely keen on not disabling the plugins to verify this, is for you to continuou to monitor this issue, and see if this is a regular occurance (IE: it adds only 1 or 2 users, and then you manually execute it shortly after to get it to pick up a lot more users). You may also wish to check into your plugins and see if cron_start, init_startup, and global_* have any code that may cause the script to end early (IE: memory limit, execution time limit etc.).

    Other than that, there's nothing else that comes to mind for something like this for me...

    Leave a comment:


  • Wayne Luke
    replied
    Manually running the cron from the Admin CP does not have the time limit on users processed. It could be that your scheduled tasks are not processing completely or another is failing to complete. Only one scheduled task is ran per page load to prevent a large burden on a single user.

    What are the last run times for your other scheduled tasks? Are they all accurate? If not, we might need to look at them as well.

    Leave a comment:


  • Steve Machol
    replied
    The best I can tell this is either a problem with your modifications, or it's a previously undiscovered bug. If the latter, then I'm surprised no one else has reported this problem before now. For instance this works perfectly fine on my essentially unmodified 3.6.8 PL2 forum.

    Unfortunately troubleshooting this will require removing your modifications which you have indicated you do not want to do. Given this I do not know what else to suggest.

    I'll see if the other staff members have any ideas about this.

    Leave a comment:


  • Lynne
    replied
    I do have other modified templates in which I've added some javascript, but that is all. I can't disable the mods on my site. I did go to my (htaccess protected) test site and disable all plugins and clicked around on the site using a style that is all default. There are just a couple of scripts on my site that are modifed, but not any of them related to the cron job, and the promotions still didn't work. None of the users were moved... however, the database is a backup from my site back in November.

    I've got a question for you.... I was looking at the cron script and it says this "We only check the users that have been active since the lastrun to save a bit of cpu time" in the promotion.php script. Do you know if when you run the script from cronadmin.php instead of cron.php if this 'rule' is bypassed? Perhaps when I hit Run Now it moves all users regardless of whether they have been active since the last time the script was run? And, was this changed from vb 3.0.12? (And, boy, if that is the issue, I am so sorry to have taken your time!)

    Leave a comment:


  • Steve Machol
    replied
    Do you have any other templates that have scripting added?

    Leave a comment:


  • Lynne
    replied
    I've reverted my footer template and the global.php, cron.php, and functions_cron.php are all non-modified vb3.6.8.PL2 scripts. As I said though, it *does* run, but something is funny in the way it only moves a couple of users and then stops. And hitting Run Now works just fine.

    Leave a comment:


  • Steve Machol
    replied
    Revert your footer template, reupload the original vB files and disable your add-ons. Then see if this works again.

    Leave a comment:


  • Lynne
    replied
    OK, I put the cronimage back to how it was originally (although I don't think what I did was 'bad') and it is still having problems. The next User Promotions time came along and it moved one user as documented in the Scheduled Task Log. I then went and ran it by hitting Run Now just a couple of minutes later and it moved about 75 users. This definitely seems to be something that is related to the difference between letting cron run the job and having me do it manually which is a difference in running cron.php versus running cronadmin.php I believe.

    I upgraded my board from 3.0.12 to 3.6.8 last Monday and that is when this problem started.

    Leave a comment:


  • Lynne
    replied
    Originally posted by Kerry-Anne View Post
    You should not modify the cron image code at all. Disable that modification and it will resolve the issue.
    I actually just modified this line in the global.php page (line 428)

    original:
    Code:
    $cronimage = '<img src="' . create_full_url('cron.php?' . $vbulletin->session->vars['sessionurl'] . '&amp;rand=' .  vbrand(1, 1000000)) . '" alt="" width="1" height="1" border="0" />';
    modified:
    Code:
    $cronimage = '<img src="' . create_full_url('/forums/cron.php?' . $vbulletin->session->vars['sessionurl'] . '&amp;rand=' .  vbrand(1, 1000000)) . '" alt="" width="1" height="1" border="0" />';
    I wouldn't think that would cause the problems but I can try that tomorrow. But, if that was the problem, wouldn't the job just not run instead of only move one or two users? That is what is confusing to me.

    Leave a comment:


  • peterska2
    replied
    You should not modify the cron image code at all. Disable that modification and it will resolve the issue.

    Leave a comment:

widgetinstance 262 (Related Topics) skipped due to lack of content & hide_module_if_empty option.
Working...
X