We have just upgraded a site from 5.8 to 5.9. The site has a lot of automated jobs which have just been converted to Tasks. We are having problems with some of the Core not being loaded when the tasks are scheduled and run from the cron.
An example is UserInfo and UserList which we need to pull users and access user attributes. The old jobs were fine and it also works when run manually from the dashboard but is obviously not being loaded correcty when run from from a cron.
What has changed between jobs and tasks for this to stop working?
I’m including this at the top of my task handler
use Concrete\Core\User\UserInfo;
Yes, I’m passing in an ID. The task runs fine when I run it manually from the dashboard but fails when run as a schduled task from cron. I’m having trouble getting it to output an error from a cron, tasks seem way more complicated than the old jobs system.
If I use UserInfo or UserList it fails which leads me to believe that some core dependencies are not being loaded when a task is run from a cron using command line php.
I’m using Log which is core functionality and that is working fine so it seems to be something to do with user related classes
Agree with @hutman. One problem I’ve run into is that if there’s an error when running from the console, it will fail silently unless you have some logging.
Also take a look at this documentation which explains the rational behind Tasks.
Also, I could be mistaken, but I think Jobs are still technically supported and probably will be until version 10. That doesn’t fix your problem, but at least might relive some stress (?)
I’ve simplified things right down to pinpoint where it’s failing. The two things I need in the task is a UserList filtered by a group and UserInfo objects so I can access attributes. It’s definitely looking like some core functionality is not loaded when run from console. I may have to get the data I need directly from the database rather than using these which is a pain.
<?php
namespace Concrete\Package\MyPackage\Src\Command;
use Concrete\Core\Command\Task\Output\OutputAwareInterface;
use Concrete\Core\Command\Task\Output\OutputAwareTrait;
use Concrete\Core\User\UserInfo;
use Concrete\Core\User\UserList;
use Core;
use Log;
class BulletinDigestCommandHandler implements OutputAwareInterface
{
use OutputAwareTrait;
public function __invoke(BulletinDigestCommand $command)
{
// log function works fine
Log::addDebug('Task Bulletin Digest Emails Started');
// user list code
$uList = new UserList();
// log on this line works
Log::addDebug('Task Bulletin Digest Emails - got user list');
$uList->filterByGroup("Administrators");
// breaks before log on this line reached so likely no $uList object to call filterByGroup on
Log::addDebug('Task Bulletin Digest Emails - filtered by group');
$adminList = $uList->getResults();
// Another example
// user info code
$ui = UserInfo::getByID(1);
// log on this line works
Log::addDebug('Task Bulletin Digest Emails - got user info');
$sendBulletin = $ui->getAttribute('subscribed_to_bulletin');
// breaks before log on this line reached so likely no $ui object
Log::addDebug('Task Bulletin Digest Emails - got subscribed to bulletin');
return;
}
}
The $adminList is a list of UserInfo objects, so there is no reason to do this $ui = UserInfo::getByID(1); but you’re also not looping over the $adminList so this code doesn’t make a ton of sense. Which line is the last one you get in the Log?
This isn’t my exact code. Just a simplified example of the two functions I’m having trouble with. I use the UserList to get a list of all the admins to get copied into the email digests and I use UserInfo in a separate area. If I run just this code
// user list code
$uList = new UserList();
// log on this line works
Log::addDebug('Task Bulletin Digest Emails - got user list');
$uList->filterByGroup("Administrators");
// breaks before log on this line reached so likely no $uList object to call filterByGroup on
Log::addDebug('Task Bulletin Digest Emails - filtered by group');
$adminList = $uList->getResults();
The log entry after the filterbygroup is not sent so it’s the filterbygroup that is failing. Same with UserInfo it’s the getAttribute method call that’s failing. It seems that the objects are not being created but only when run on a schedule. It runs fine from the dashboard when the task is run manually.
I’m beginning to wonder if it’s an issue with the fact this is an upgraded site from version 5.8. Maybe something not happy with the new core being in the Updates folder. I’m going to do some more testing on a different server and fresh version 9 site.
use Concrete\Core\User\Group\GroupRepository;
use Concrete\Core\User\UserInfoRepository;
$app = \Concrete\Core\Support\Facade\Application::getFacadeApplication();
$group_repository = $app->make(GroupRepository::class);
$admin_group = $group_repository->getGroupByName('Administrators');
// user list code
$uList = new UserList();
// log on this line works
Log::addDebug('Task Bulletin Digest Emails - got user list');
$uList->filterByGroup($admin_group);
// breaks before log on this line reached so likely no $uList object to call filterByGroup on
Log::addDebug('Task Bulletin Digest Emails - filtered by group');
$adminList = $uList->getResults();
$app->make(UserInfoRepository::class)->getByID($uID);
Just tried that and the same thing. Works manually but fails on a schedule. I just tested it on our dev server and it worked there. This is weird. Must be something to do with the live environment maybe the command line php. I’m going to have to do some more testing. Thanks for your help.
No, this site doesn’t have a .env file. I gave up trying to work this out as spent too many hours on it and really needed to get it working. I just created my own functions to get the user lists and user attributes I needed directly from the database instead. Thanks for your help though.