Cron (liebig/cron) breaks Artisan on a fresh Laravel 5 install - laravel

In step 4 of the installation process, I get an error (below) when trying to run the Artisan migration:
Digging around, I've found a discussion on the Laracasts forums where it's pointed out this could be related to the new structure of Laravel 5.
Anybody has any idea about this?
exception 'BadMethodCallException' with message 'Call to undefined method [package]' in /home/vagrant/myApplication/vendor/laravel/framework/src/Illuminate/Support/ServiceProvider.php:226
Stack trace:
#0 /home/vagrant/myApplication/vendor/liebig/cron/src/Liebig/Cron/CronServiceProvider.php(22): Illuminate\Support\ServiceProvider->__call('package', Array)
#1 /home/vagrant/myApplication/vendor/liebig/cron/src/Liebig/Cron/CronServiceProvider.php(22): Liebig\Cron\CronServiceProvider->package('liebig/cron')
#2 [internal function]: Liebig\Cron\CronServiceProvider->boot()
#3 /home/vagrant/myApplication/vendor/laravel/framework/src/Illuminate/Container/Container.php(523): call_user_func_array(Array, Array)
#4 /home/vagrant/myApplication/vendor/laravel/framework/src/Illuminate/Foundation/Application.php(631): Illuminate\Container\Container->call(Array)
#5 /home/vagrant/myApplication/vendor/laravel/framework/src/Illuminate/Foundation/Application.php(613): Illuminate\Foundation\Application->bootProvider(Object(Liebig\Cron\CronServiceProvider))
#6 [internal function]: Illuminate\Foundation\Application->Illuminate\Foundation\{closure}(Object(Liebig\Cron\CronServiceProvider), 19)
#7 /home/vagrant/myApplication/vendor/laravel/framework/src/Illuminate/Foundation/Application.php(614): array_walk(Array, Object(Closure))
#8 /home/vagrant/myApplication/vendor/laravel/framework/src/Illuminate/Foundation/Bootstrap/BootProviders.php(15): Illuminate\Foundation\Application->boot()
#9 /home/vagrant/myApplication/vendor/laravel/framework/src/Illuminate/Foundation/Application.php(165): Illuminate\Foundation\Bootstrap\BootProviders->bootstrap(Object(Illuminate\Foundation\Application))
#10 /home/vagrant/myApplication/vendor/laravel/framework/src/Illuminate/Foundation/Console/Kernel.php(192): Illuminate\Foundation\Application->bootstrapWith(Array)
#11 /home/vagrant/myApplication/vendor/laravel/framework/src/Illuminate/Foundation/Console/Kernel.php(89): Illuminate\Foundation\Console\Kernel->bootstrap()
#12 /home/vagrant/myApplication/artisan(36): Illuminate\Foundation\Console\Kernel->handle(Object(Symfony\Component\Console\Input\ArgvInput), Object(Symfony\Component\Console\Output\ConsoleOutput))
#13 {main}
Issue posted in Cron's GitHub.

There is no need for this package with Laravel 5.
The ability to schedule crons is built in from the beginning now.
$schedule->command('foo')->daily();
You can read about scheduling artisan commands in the Laravel 5 Docs

Related

Laravel queued emails throws exception after some are sent

I have an Laravel 5.4 app.
My issue is that I have a weekly job that queues some emails.
Like this:
Mail::to($user)->queue(new \App\Mail\INBND10\i01($user));
Everything looks fine, and some of the emails were delivered, but I got a Trying to get property of non-object Exception after a couple of emails are sent.
Sentry tells me that is in the Mail build method, as seen here:
Any ideas what causes this oddly behavior?
EDIT
StackTrace
ErrorException: Trying to get property of non-object
#40 vendor/laravel/framework/src/Illuminate/Mail/Mailable.php(462): handleError
#39 vendor/sentry/sentry/lib/Raven/Breadcrumbs/ErrorHandler.php(34): handleError
#38 vendor/laravel/framework/src/Illuminate/Mail/Mailable.php(462): setAddress
#37 vendor/laravel/framework/src/Illuminate/Mail/Mailable.php(346): from
#36 app/Mail/INBND10/i01.php(35): build
#35 app/Mail/INBND10/i01.php(0): call_user_func_array
#34 vendor/laravel/framework/src/Illuminate/Container/BoundMethod.php(29): Illuminate\Container\{closure}
#33 vendor/laravel/framework/src/Illuminate/Container/BoundMethod.php(87): callBoundMethod
#32 vendor/laravel/framework/src/Illuminate/Container/BoundMethod.php(31): call
#31 vendor/laravel/framework/src/Illuminate/Container/Container.php(539): call
#30 vendor/laravel/framework/src/Illuminate/Mail/Mailable.php(116): send
#29 vendor/laravel/framework/src/Illuminate/Mail/SendQueuedMailable.php(52): handle
#28 vendor/laravel/framework/src/Illuminate/Mail/SendQueuedMailable.php(0): call_user_func_array
#27 vendor/laravel/framework/src/Illuminate/Container/BoundMethod.php(29): Illuminate\Container\{closure}
#26 vendor/laravel/framework/src/Illuminate/Container/BoundMethod.php(87): callBoundMethod
#25 vendor/laravel/framework/src/Illuminate/Container/BoundMethod.php(31): call
#24 vendor/laravel/framework/src/Illuminate/Container/Container.php(539): call
#23 vendor/laravel/framework/src/Illuminate/Bus/Dispatcher.php(94): Illuminate\Bus\{closure}
#22 vendor/laravel/framework/src/Illuminate/Pipeline/Pipeline.php(114): Illuminate\Pipeline\{closure}
#21 vendor/laravel/framework/src/Illuminate/Pipeline/Pipeline.php(102): then
#20 vendor/laravel/framework/src/Illuminate/Bus/Dispatcher.php(98): dispatchNow
#19 vendor/laravel/framework/src/Illuminate/Queue/CallQueuedHandler.php(42): call
#18 vendor/laravel/framework/src/Illuminate/Queue/Jobs/Job.php(69): fire
#17 vendor/laravel/framework/src/Illuminate/Queue/Worker.php(317): process
#16 vendor/laravel/framework/src/Illuminate/Queue/Worker.php(267): runJob
#15 vendor/laravel/framework/src/Illuminate/Queue/Worker.php(113): daemon
#14 vendor/laravel/framework/src/Illuminate/Queue/Console/WorkCommand.php(101): runWorker
#13 vendor/laravel/framework/src/Illuminate/Queue/Console/WorkCommand.php(85): fire
#12 vendor/laravel/framework/src/Illuminate/Queue/Console/WorkCommand.php(0): call_user_func_array
#11 vendor/laravel/framework/src/Illuminate/Container/BoundMethod.php(29): Illuminate\Container\{closure}
#10 vendor/laravel/framework/src/Illuminate/Container/BoundMethod.php(87): callBoundMethod
#9 vendor/laravel/framework/src/Illuminate/Container/BoundMethod.php(31): call
#8 vendor/laravel/framework/src/Illuminate/Container/Container.php(539): call
#7 vendor/laravel/framework/src/Illuminate/Console/Command.php(182): execute
#6 vendor/symfony/console/Command/Command.php(251): run
#5 vendor/laravel/framework/src/Illuminate/Console/Command.php(167): run
#4 vendor/symfony/console/Application.php(946): doRunCommand
#3 vendor/symfony/console/Application.php(248): doRun
#2 vendor/symfony/console/Application.php(148): run
#1 vendor/laravel/framework/src/Illuminate/Foundation/Console/Kernel.php(122): handle
#0 artisan(35): null
In case someone stumble on this.
We use Laravel Forge to deploy our app, and although I run the php artisan queue:restart command in every deploy, some of the workers were never restarting, some of them were up for more than 12 days.
So, when one of those workers were assigned to run the job they crashed, because they didn't have the updated code.
That's why some of emails were sent before it crashed.
HOW TO FIX
To fix that when I create the queue workers on Forge I had to set a timeout value. So in that way, none of the workers will get frozen, and they will be restarted as expected.
https://laravel.com/docs/5.7/queues#job-expirations-and-timeouts

Artisan won't work in production but works fine locally

I am pulling my hair out over a problem in production: I cannot get my migrations to run. And, not only that but simply running 'php artisan' generates an error. The odd thing is that everything is working fine locally.
I am using Laravel 5.1 and have tried re-cloning my app on the server, re-installing vendor (after flushing the composer cache), redoing .env and giving permissions to the appropriate bootstrap/cache and storage files. I have also manually dropped all of my tables and then, when that didn't work, deleted and remade the database itself. I have run 'composer dump-autoload' many times as I tried to isolate the source of the problem with no luck.
I had a look at my log file and this is what comes up:
[2016-06-24 06:07:16] production.ERROR: exception 'ErrorException' with message 'Trying to get property of non-object' in /var/www/html/foobooks/app/Services/PrivacyService.php:157
Stack trace:
#0 /var/www/html/foobooks/app/Services/PrivacyService.php(157): Illuminate\Foundation\Bootstrap\HandleExceptions->handleError(8, 'Trying to get p...', '/var/www/html/l...', 157, Array)
#1 /var/www/html/foobooks/app/Services/DateService.php(69): Foobooks\Services\PrivacyService->getPrivacyLevelIdWithPrivacyLevel('everyone')
#2 /var/www/html/foobooks/vendor/laravel/framework/src/Illuminate/Cache/Repository.php(239): Foobooks\Services\DateService->Foobooks\Services\{closure}()
#3 [internal function]: Illuminate\Cache\Repository->rememberForever('everyone_privac...', Object(Closure))
#4 /var/www/html/foobooks/vendor/laravel/framework/src/Illuminate/Cache/CacheManager.php(318): call_user_func_array(Array, Array)
#5 /var/www/html/foobooks/vendor/laravel/framework/src/Illuminate/Support/Facades/Facade.php(217): Illuminate\Cache\CacheManager->__call('rememberForever', Array)
#6 /var/www/html/foobooks/vendor/laravel/framework/src/Illuminate/Support/Facades/Facade.php(217): Illuminate\Cache\CacheManager->rememberForever('everyone_privac...', Object(Closure))
#7 /var/www/html/foobooks/app/Services/DateService.php(70): Illuminate\Support\Facades\Facade::__callStatic('rememberForever', Array)
#8 /var/www/html/foobooks/app/Services/DateService.php(70): Illuminate\Support\Facades\Cache::rememberForever('everyone_privac...', Object(Closure))
#9 [internal function]: Foobooks\Services\DateService->__construct(Object(Foobooks\Repositories\Models\DbEventRepository), Object(Foobooks\Services\PrivacyService), Object(Foobooks\$
#10 /var/www/html/foobooks/vendor/laravel/framework/src/Illuminate/Container/Container.php(780): ReflectionClass->newInstanceArgs(Array)
#11 /var/www/html/foobooks/vendor/laravel/framework/src/Illuminate/Container/Container.php(631): Illuminate\Container\Container->build('Foobooks\...', Array)
#12 /var/www/html/foobooks/vendor/laravel/framework/src/Illuminate/Foundation/Application.php(674): Illuminate\Container\Container->make('Foobooks\...', Array)
#13 /var/www/html/foobooks/vendor/laravel/framework/src/Illuminate/Container/Container.php(220): Illuminate\Foundation\Application->make('Foobooks\...', Array)
#14 /var/www/html/foobooks/vendor/laravel/framework/src/Illuminate/Container/Container.php(738): Illuminate\Container\Container->Illuminate\Container\{closure}(Object(Illuminate\Foundation\Application), Array)
#15 /var/www/html/foobooks/vendor/laravel/framework/src/Illuminate/Container/Container.php(631): Illuminate\Container\Container->build(Object(Closure), Array)
#16 /var/www/html/foobooks/vendor/laravel/framework/src/Illuminate/Foundation/Application.php(674): Illuminate\Container\Container->make('Foobooks\...', Array)
#17 /var/www/html/foobooks/vendor/laravel/framework/src/Illuminate/Container/Container.php(842): Illuminate\Foundation\Application->make('Foobooks\...')
#18 /var/www/html/foobooks/vendor/laravel/framework/src/Illuminate/Container/Container.php(805): Illuminate\Container\Container->resolveClass(Object(ReflectionParameter))
#19 /var/www/html/foobooks/vendor/laravel/framework/src/Illuminate/Container/Container.php(776): Illuminate\Container\Container->getDependencies(Array, Array)
#20 /var/www/html/foobooks/vendor/laravel/framework/src/Illuminate/Container/Container.php(631): Illuminate\Container\Container->build('Foobooks\...', Array)
#21 /var/www/html/foobooks/vendor/laravel/framework/src/Illuminate/Foundation/Application.php(674): Illuminate\Container\Container->make('Foobooks\...', Array)
#22 /var/www/html/foobooks/vendor/laravel/framework/src/Illuminate/Console/Application.php(115): Illuminate\Foundation\Application->make('Foobooks\...')
#23 /var/www/html/foobooks/vendor/laravel/framework/src/Illuminate/Console/Application.php(129): Illuminate\Console\Application->resolve('Foobooks\...')
#24 /var/www/html/foobooks/vendor/laravel/framework/src/Illuminate/Foundation/Console/Kernel.php(226): Illuminate\Console\Application->resolveCommands(Array)
#25 /var/www/html/foobooks/vendor/laravel/framework/src/Illuminate/Foundation/Console/Kernel.php(107): Illuminate\Foundation\Console\Kernel->getArtisan()
#26 /var/www/html/foobooks/artisan(36): Illuminate\Foundation\Console\Kernel->handle(Object(Symfony\Component\Console\Input\ArgvInput), Object(Symfony\Component\Console\Output\ConsoleOutput))
#27 {main}
The app seems to be actually trying to instantiate my class DateService somewhere in the autoload process (which in turn instantiates PrivacyService) and this is what is causing the problem. I have searched my app for all instances where it is injected but none seem to be part of the autoloading process - and, it doesn't explain why things are working just fine locally.
Initially, when artisan complained, it gave me a 'missing base table error' and, for whatever reason, if I 'fake' created the table in database and then dropped it manually, the app moved on to complaining about another table until I did the manual create/drop again. I was able to move through table errors this way until I hit this 'Trying to get property of non-object' error.
Does anyone have any idea what might be the problem? It feels like there is some kind of database caching file that I don't know about that is hanging about somewhere and causing this problem, making the app think the migrations/seeds have already occurred. It just seems odd that creating fake tables and dropping them seemed to be doing something until this error popped up - also, odd that only the production environment is affected.
Any help or insight would be greatly appreciated - thank you!
The solution: for some reason the permissions were different on some folders in my cache folder than others so the flush() method did not fully clear the cache. Legacy folders/files were conflicting with artisan's bootstrapping efforts. I was able to solve the problem by reapplying permissions to the storage/framework/cache directory, running flush() again. Once I did and made sure that ALL subfolders and files were deleted from the cache, I was able to run php artisan without a hitch.

Magento with RedisLab Redis Cluster Backend

Magento RedisLab cluster Integration Problem
After we deploy cluster redis database , FPC and Session working perfectly but when we add cluster redis ( RedisLab ) instance with Magento Cache section we are facing one problem.
When click ADD TO CART >> show cannot add product
Backend Error
Next exception 'Zend_Cache_Exception' with message 'Error cleaning cache by mode matchingAnyTag: ERR CROSSSLOT Keys in request don't hash to the same slot (command='SUNION', key='zc:ti:da3_QUOTE_2156255')' in /var/www/magento/lib/Zend/Cache.php:209
Stack trace:
3
#6 /var/www/magento/app/code/core/Mage/Core/Model/Abstract.php(464): Mage_Core_Model_Abstract->cleanModelCache()
#7 /var/www/magento/app/code/core/Mage/Sales/Model/Quote.php(333): Mage_Core_Model_Abstract->_afterSave()
#8 /var/www/magento/app/code/core/Mage/Core/Model/Abstract.php(319): Mage_Sales_Model_Quote->_afterSave()
#9 /var/www/magento/app/code/core/Mage/Sales/Model/Quote.php(1966): Mage_Core_Model_Abstract->save()
#10 /var/www/magento/app/code/core/Mage/Checkout/Model/Cart.php(459): Mage_Sales_Model_Quote->save()
#11 /var/www/magento/app/code/core/Mage/Checkout/controllers/CartController.php(223): Mage_Checkout_Model_Cart->save()
#12 /var/www/magento/app/code/core/Mage/Core/Controller/Varien/Action.php(418): Mage_Checkout_CartController->addAction()
#13 /var/www/magento/app/code/core/Mage/Core/Controller/Varien/Router/Standard.php(254): Mage_Core_Controller_Varien_Action->dispatch('add')
#14 /var/www/magento/app/code/core/Mage/Core/Controller/Varien/Front.php(172): Mage_Core_Controller_Varien_Router_Standard->match(Object(Mage_Core_Controller_Request_Http))
#15 /var/www/magento/app/code/core/Mage/Core/Model/App.php(365): Mage_Core_Controller_Varien_Front->dispatch()
#16 /var/www/magento/app/Mage.php(684): Mage_Core_Model_App->run(Array)
#17 /var/www/magento/index.php(85): Mage::run('', 'store')
#18 {main}
If i disable the exception then its working file
/var/www/magento/lib/Zend/Cache.php:209
Just got the same exception like you , I believe that case belong to your custom work try to make magento working with redis-cluster
My solution :
just remove exception in redis-client.php library first and return IP:PORT
find the correct client by byHash function in redis-cluster.php
execute the command with correct client
Need to overwrite load , remove , _removeByMatchingTags...

Magento Zend Mail using Google SMTP

I'm having troubles with mail sending in Magento: simply emails are not being sent in case of customer registration, order confirmation ecc.
I checked the exception log and this is what I found:
exception 'Zend_Mail_Protocol_Exception' with message '5.7.1 Username and Password not accepted. Learn more at
5.7.1 http://support.google.com/mail/bin/answer.py?answer=14257 q42sm2096509eem.14 - gsmtp
' in /srv/www/htdocs/lib/Zend/Mail/Protocol/Abstract.php:431
Stack trace:
#0 /srv/www/htdocs/lib/Zend/Mail/Protocol/Smtp/Auth/Login.php(95): Zend_Mail_Protocol_Abstract->_expect(235)
#1 /srv/www/htdocs/lib/Zend/Mail/Protocol/Smtp.php(217): Zend_Mail_Protocol_Smtp_Auth_Login->auth()
#2 /srv/www/htdocs/lib/Zend/Mail/Transport/Smtp.php(200): Zend_Mail_Protocol_Smtp->helo('localhost')
#3 /srv/www/htdocs/lib/Zend/Mail/Transport/Abstract.php(348): Zend_Mail_Transport_Smtp->_sendMail()
#4 /srv/www/htdocs/lib/Zend/Mail.php(1194): Zend_Mail_Transport_Abstract->send(Object(Zend_Mail))
#5 /srv/www/htdocs/app/code/core/Mage/Core/Model/Email/Template.php(465): Zend_Mail->send(Object(Zend_Mail_Transport_Smtp))
#6 /srv/www/htdocs/app/code/core/Mage/Core/Model/Email/Template.php(517): Mage_Core_Model_Email_Template->send(Array, Array, Array)
#7 /srv/www/htdocs/app/code/core/Mage/Core/Model/Email/Template/Mailer.php(79): Mage_Core_Model_Email_Template->sendTransactional('customer_create...', 'general', Array, Array, Array, '1')
#8 /srv/www/htdocs/app/code/core/Mage/Customer/Model/Customer.php(650): Mage_Core_Model_Email_Template_Mailer->send()
#9 /srv/www/htdocs/app/code/core/Mage/Customer/Model/Customer.php(577): Mage_Customer_Model_Customer->_sendEmailTemplate('customer/create...', 'customer/create...', Array, '1')
#10 /srv/www/htdocs/app/code/core/Mage/Customer/controllers/AccountController.php(344): Mage_Customer_Model_Customer->sendNewAccountEmail('confirmation', 'http://test.col...', '1')
#11 /srv/www/htdocs/app/code/core/Mage/Core/Controller/Varien/Action.php(419): Mage_Customer_AccountController->createPostAction()
#12 /srv/www/htdocs/app/code/core/Mage/Core/Controller/Varien/Router/Standard.php(250): Mage_Core_Controller_Varien_Action->dispatch('createpost')
#13 /srv/www/htdocs/app/code/core/Mage/Core/Controller/Varien/Front.php(176): Mage_Core_Controller_Varien_Router_Standard->match(Object(Mage_Core_Controller_Request_Http))
#14 /srv/www/htdocs/app/code/core/Mage/Core/Model/App.php(354): Mage_Cor_Controller_Varien_Front->dispatch()
#15 /srv/www/htdocs/app/Mage.php(683): Mage_Core_Model_App->run(Array)
#16 /srv/www/htdocs/index.php(87): Mage::run('', 'store')
#17 {main}
I didn't know about the Zend Mail Protocol, anyway, from what I see, this is trying to use SMTP authentication on a Google server; the fact is I have not installed any extension to use SMTP in Magento, so I have never set up any username or password; besides I'm using localhost in Magento mail sending settings, so anyone has an idea of what happened and can suggest me a workaround?
Thank you!

Error Processing Request: Mage registry key "_singleton/inchoo_notes/feed_updates" already exists

I get this error message whenever im trying to login to magento admin after installation of inhcoo featured 2.0 (magento extension) through magento connect:
There has been an error processing your request
Mage registry key "_singleton/inchoo_notes/feed_updates" already exists
Trace:
#0 /home/.../public_html/app/Mage.php(222): Mage::throwException('Mage registry k...')
#1 /home/.../public_html/app/Mage.php(476): Mage::register('_singleton/inch...', false)
#2 /home/..../public_html/includes/src/__default.php(20995): Mage::getSingleton('inchoo_notes/fe...')
#3 /home/...../public_html/app/Mage.php(447): Mage_Core_Model_App->dispatchEvent('controller_acti...', Array)
#4 /home/..../public_html/includes/src/__default.php(13663): Mage::dispatchEvent('controller_acti...', Array)
#5 /home/..../public_html/includes/src/Mage_Adminhtml_Controller_Action.php(160): Mage_Core_Controller_Varien_Action->preDispatch()
#6 /home/..../public_html/includes/src/__default.php(13543): Mage_Adminhtml_Controller_Action->preDispatch()
#7 /home/..../public_html/includes/src/__default.php(17899): Mage_Core_Controller_Varien_Action->dispatch('login')
#8 /home/..../public_html/includes/src/__default.php(17456): Mage_Core_Controller_Varien_Router_Standard->match(Object(Mage_Core_Controller_Request_Http))
#9 /home/..../public_html/includes/src/__default.php(20033): Mage_Core_Controller_Varien_Front->dispatch()
#10 /home/..../public_html/app/Mage.php(683): Mage_Core_Model_App->run(Array)
#11 /home/..../public_html/index.php(89): Mage::run('', 'store')
#12 {main}
Error log record number: 214959287644
how can I fix this problem? please help
This specific error happens when a singleton (model or helper) is attempted to be invoked but cannot be mapped. Based on the path which I'm seeing in the stack trace, it looks as though you have compilation enabled. You should disable compilation while attempting to install this module, which can be done in the admin GUI at System > Compilation.

Resources