Programmatically add new Sites with Sites ModuleCreated 5 years ago by brunsi
Hey Guys, I wanted to add new sites via an API Endpoint in my PyroCMS installation. As a scaffold I already installed the sites module. I created a new Site:
$site = SiteModel::create($data); with all the necessary data. After this I wanted to start the installation of site asynchronously which does not work:
\Artisan::queue('install', [ '--app' => $data['reference'], '--ready' => true ]);
After some time I only got my process killed:  3529 killed php artisan queue:work
Any ideas on that? ..
EDIT: When I disable command queueing and run it by hand: php artisan install --app=foo --ready it works as usual. Even after waiting my queue to have run several minutes no database table was created -> install command seems to have not started.
Sorry, a little bit confusing what I wrote :D
Because the Queue does not produces any output when starting work on a task, I don't see what's going on there (like the progress output of usual install command). I only see that the
attempts-Column moves from 0 to 1, so that I assume, the Queue starts work on the streams install command.
One of the first tasks of the install command is to create the database tables for the new site. So that's why I expected to see the new tables just a moment after the queue starts the install command. But nothing happens. Even when I wait 5 minutes, no table was created. Don't know what the job is doing, no Exception comes up...
There is a known issue with queueing the command though
Aah okay .. do you have any idea on that?
Have you checkout your
failed_jobs table? Otherwise I would suggest modifying the code for testing purposes and add some additional logging but I ASSUME.. that the Artisan console that the queue is using is different than the one in Streams Platform.. I think that happens in Artisan so maybe we'll need to modify that.
Can you queue a job that logs the result of
get_class(app('artisan')); or the kernel in general? That will tell us what it is/if it's different than when queued or not.
Hey Ryan, thanks for your reply!
Have you checkout your failed_jobs table?
Yep, the job does not fail and is very long running. Also after 5 minutes the
attempts-Column is still on
1.. I tried queueing it with some misconfiguration, then the job moves to the failed_jobs table.
I will check your tasks later or tomorrow!
Regarding your edit - are you saying it works as usual but no database tables are created?
There is a known issue with queueing the command though.. Haven't had a chance to look at it. I suspect the Streams override for the kernel is not being used..