Another reason an Entry can't be created from console CLI

[narration-sd]

Description

Your #1562 fixed one issue on this, but here is another. Probably a similar repair, but will leave you to know where to accurately pull the missing id.

2017-03-30 03:45:03 [-][-][-][][yii\base\UnknownMethodException] yii\base\UnknownMethodException: Calling unknown method: craft\console\User::getId() in /home/vagrant/Code/newprime_encounsel_html/vendor/yiisoft/yii2/base/Component.php:290
Stack trace:
#0 /home/vagrant/Code/newprime_encounsel_html/vendor/craftcms/cms/src/elements/Entry.php(506): yii\base\Component->__call('getId', Array)
#1 /home/vagrant/Code/newprime_encounsel_html/vendor/yiisoft/yii2/base/Object.php(107): craft\elements\Entry->init()
#2 /home/vagrant/Code/newprime_encounsel_html/vendor/narrationsd/standardsagent/src/services/ActivitiesService.php(579): yii\base\Object->__construct()

Steps to reproduce

1. console command which results in due course to create an Entry from a Task
2. task runs directly from command, but still silently fails
3. logged stack trace is as above

Additional info

PHP version 7.1.2-4+deb.sury.orgxenial+1
Database driver & version MySQL 5.7.17-0ubuntu0.16.04.1
Image driver & version GD 7.1.2-4+deb.sury.orgxenial+1
Craft edition & version Craft Personal 3.0.0-beta.9
Yii version 2.0.11.2
Twig version 2.1.0
Guzzle version 6.2.1
Imagine version 0.7-dev
Plugins

Trimmer 1.0.0
Bactrian 1.0.0
Standards Agent 2.0.4

[narration-sd]

Ok, this may not be a bug.

I was reading up Yii2 with idea of just creating a pull request with solution, but it looks like the answer is actually to configure a User especially for consoles that need one -- as element operations like creating Entry objects and their database records do.

I have such a creating user identity already in my (other kind of) config for this application, so shoujldn't be a problem.

Not quite time to do it just now, but will report how it goes, and then close this issue I rather suspect.

[narration-sd]

Just to spend ten minutes on this for a Sunday, I did what I thought to do before getting more involved with the ins and outs of console apps.

This is to subclass Entry so as to add a constructor, allowing the local intent for authorId to be put into place in the right order, so that Entry won't try to set it from the User which won't exist under console apps.

May be useful to Yuri @intoeetive or anyone else hung on this for the moment. Be sure to be aware it doesn't deal with any of the more sly issues likely caused by missing setup listed in #1587. You'd have to copy the relevant code over from bootstrap/web.php to bootstrap/console.php if important to you, and will lose this on any beta updates until that one is addressed.

Here's a code example for the subclass -- very simple. Put it in your plugin's elements folder, rename the class as you like, and use it instead of Entry where you create via new. Fill in the authorId when you want something other than admin.

<?php                                           
                                                
namespace yoursignature\yourplugin\elements;  
                                                
use craft\elements\Entry;                       
                                                
                                                
class SAEntry extends Entry                     
{                                               
    /**                                         
     * @inheritdoc                              
     */                                         
    function __construct($authorId = 1)         
    {                                           
        $this->authorId = $authorId;            
                                                
        parent::__construct();                  
    }                                           
}                                                                                               

[narration-sd]

One more thought. If craft\elements\Entry looked at the nature of the $app, it could just plug in a default for console -- 1 for admin.

But in fact, I'm not quite sure why you are trying to preset the authorId in such a way for Craft 3:

• this didnt happen, or at least in an interfering way involving User, in Craft 2
• it's always possible to override it after the Entry is created -- and we should
• who's to say the current user would be the correct authorId anyway?
• I can't see any place in parents where this authorId is used in object construction

Maybe you are trying to do something to safety use better for Twig?

All of the above, though, seems to suggest that simply defaulting the authorId to 1, admin, here in Entry::init(), would be the better solution regardless of the type of app -- and save the maximum amount of hassle.

[brandonkelly]

Considering there is already a craft\console\User::getIdentity() (and setIdentity()), I’m considering this a bug, and just added a getId() method.

[narration-sd]

hmm, I'm going to have to do what was thinking about anyway after @andris mentioned it, go to using the dev version in composer for at least this particular site, to see if this operates...still thinking there is no User for console execution, but I might be wrong about that...salty hands-on proof works best...

[narration-sd]

Ok, I switched over to dev-develop in composer.json and all requisite plugin composer.jsons, updated, popped up the rsynced Vagrant, and now invoked console w/agent tasks running fine, without my inherited object patch.

So your thinking here def works, so does my agent clocking, signing off on this one -- Cheers, Brandon...

Also, I need to add some console line-visible warnings in case of unexpected on my stuff, just as i issue-recommended for yours in #1580. todo