XF 2.1 Possibly a cron problem?

[spicer]

If registration takes place shortly before midnight, the user is not automatically promoted.
I have to move the user by hand.
The addon AndyB register email 3.3 does not send any email either.
Can this be a bug in the cron?

 

[Chris D]

No very unlikely.

Cron isn’t even involved in promoting newly registered users and the time they registered is irrelevant.

My hunch is that you have an add-on which is extending some of our code and not letting our code run.

You likely need to disable all add-ons and register a test account to see if you can reproduce. Then reenable each add-on and register more test accounts to see if you can figure out which is causing it.

 

[spicer]

The problem is that it works otherwise (e.g. between 0:01 and 23:45).
I can not reproduce the error.

"Cron isn’t even involved in promoting newly registered users and the time they registered is irrelevant." >
But usergroup promotion ist a cronjob!

 

[Chris D]

That doesn’t make any logical sense unfortunately.

As I mentioned promotions are run as soon as the user registers and it doesn’t defer it to a cron to do so.

I can’t say whether or not that add-on requires a cron either but my hunch is it doesn’t - Crons are for tasks that need to happen repeatedly on a schedule rather than things that happen on demand, like a user registering.

You may want to verify that with the author of the add-on.

At least then you can rule out cron issues but my hunch is still that a bugged add-on is involved somewhere; though I’m not sure why it would only affect things happening at a specific time.

 

[spicer]

See the screenshots.
The "promotions" are clearly cron jobs.

The user in question was correctly registered. However, he was not promoted to "0post member".

 

[Chris D]

What I'm saying is that we have code explicitly which handles user group promotions on registration that does not rely on the cron to run.

What is the exact criteria of your 0post member promotion?

 

[Chris D]

It's also worth noting that the user group promotion cron only runs once an hour. So if someone registers at 23:45 the cron - if needed - would not run until 00:20 by default.

 

[spicer]

Criteria:
User status: Valid
The user has made no more than X posts: 0

"User group promotions" cron runs every 5 minutes

 

[spicer]

What about: $userFinder->where('last_activity', '>', time() - 2 * 3600)

<?php

namespace XF\Cron;

/**
* Cron entry for executing user group promotions.
*/
class UserGroupPromotion
{
    /**
     * Runs the cron-based check for new promotions that users should be awarded.
     */
    public static function runPromotions()
    {
        /** @var \XF\Repository\UserGroupPromotion $promotionRepo */
        $promotionRepo = \XF::repository('XF:UserGroupPromotion');

        $promotions = $promotionRepo->getActiveUserGroupPromotions();
        if (!$promotions)
        {
            return;
        }

        /** @var \XF\Finder\User $userFinder */
        $userFinder = \XF::app()->finder('XF:User');
        $userFinder->where('last_activity', '>', time() - 2 * 3600)
            ->with(['Profile', 'Option'])
            ->order('user_id');

        $users = $userFinder->fetch();

        $userGroupPromotionLogs = $promotionRepo->getUserGroupPromotionLogsForUsers($users->keys());

        foreach ($users AS $user)
        {
            $promotionRepo->updatePromotionsForUser(
                $user,
                isset($userGroupPromotionLogs[$user->user_id]) ? $userGroupPromotionLogs[$user->user_id] : [],
                $promotions
            );
        }
    }
}

activity more or less than 2h ?

 

[Chris D]

Having "User status: Valid" likely does mean that the promotion is deferred until the user has confirmed their email address or otherwise had their account manually approved.

If your intention is for this promotion to apply immediately then you would be better to remove that criteria.

Otherwise it would have to wait for the Cron to run.

This isn't exclusive to user registrations that happen in a 15 minute window, though. This is something that would likely be true regardless of what time they registered.

 

[spicer]

If I remove "User status: Valid", the user will be promoted even if he has not confirmed the email.

 

[Chris D]

Right. But they can't use their account effectively until they confirm their email anyway, so it doesn't really make a difference. Until they confirm their email regardless of what additional permissions promoting them to "0 posts" gives them, they still have the same permission set as unregistered/unconfirmed users.

To slightly correct what I said earlier though...

The last_activity check in the Cron makes it so that it only runs for users who have been active recently (I implied the opposite before).

So that's irrelevant as when a user registers their initial value for last_activity is the same as register_date so a newly registered user will always have been active within the last 2 hours.

So without changing the criteria, and you running the Cron every 5 minutes, the maximum time a newly registered user would have to wait for the promotion is 5 minutes after they've confirmed their email.

So we're not really any further forward.

My only two theories at the moment are:

1. perhaps that the last_activity value is not being updated as expected
2. The cron system actually requires site activity to run

That second point may be relevant. There's really no concept of PHP being able to execute itself on a schedule so for things like Cron and other job triggers to run, it requires a user (registered or not) to visit your forum, and then that allows us to trigger any outstanding jobs including the cron system.

However, it would be pretty rare for most sites to have no activity whatsoever as even things like search engine crawlers would trigger what is necessary to fire off the cron entries.

So I don't know if that means 1. is more likely.

Ultimately, though, my advice still stands. User promotions aren't supposed to be time critical, there also may be performance implications by running it very frequently especially if you have a lot of users active at a time and lots of promotions. XenForo updates would reset the changes you made to the cron as well, btw.

So my advice really is still to remove that user status criteria and return the cron to running hourly and that should really mitigate any problems you're having.