This problem deals specifically with Laravel 6.10 and queue processing. On my local machine, the program runs fine, and all queued jobs load well and process to completion. On my GoDaddy server, I get a mysterious error when the job tries to load that reads:
Error thrown on line 805 in /home/jaredclemence/public_html/theninjaassistant.com/vendor/laravel/framework/src/Illuminate/Container/Container.php with message:
Target class [] does not exist.
Trace:
#0 /home/jaredclemence/public_html/theninjaassistant.com/vendor/laravel/framework/src/Illuminate/Container/Container.php(681): Illuminate\Container\Container->build(NULL)
#1 /home/jaredclemence/public_html/theninjaassistant.com/vendor/laravel/framework/src/Illuminate/Container/Container.php(629): Illuminate\Container\Container->resolve(NULL, Array)
#2 /home/jaredclemence/public_html/theninjaassistant.com/vendor/laravel/framework/src/Illuminate/Foundation/Application.php(776): Illuminate\Container\Container->make(NULL, Array)
#3 /home/jaredclemence/public_html/theninjaassistant.com/vendor/laravel/framework/src/Illuminate/Queue/Jobs/Job.php(215): Illuminate\Foundation\Application->make(NULL)
#4 /home/jaredclemence/public_html/theninjaassistant.com/vendor/laravel/framework/src/Illuminate/Queue/Jobs/Job.php(88): Illuminate\Queue\Jobs\Job->resolve(NULL)
#5 /home/jaredclemence/public_html/theninjaassistant.com/vendor/laravel/framework/src/Illuminate/Queue/Worker.php(354): Illuminate\Queue\Jobs\Job->fire()
#6 /home/jaredclemence/public_html/theninjaassistant.com/vendor/laravel/framework/src/Illuminate/Queue/Worker.php(300): Illuminate\Queue\Worker->process('database', Object(Illuminate\Queue\Jobs\DatabaseJob), Object(Illuminate\Queue\WorkerOptions))
#7 /home/jaredclemence/public_html/theninjaassistant.com/vendor/laravel/framework/src/Illuminate/Queue/Worker.php(134): Illuminate\Queue\Worker->runJob(Object(Illuminate\Queue\Jobs\DatabaseJob), 'database', Object(Illuminate\Queue\WorkerOptions))
#8 /home/jaredclemence/public_html/theninjaassistant.com/vendor/laravel/framework/src/Illuminate/Queue/Console/WorkCommand.php(112): Illuminate\Queue\Worker->daemon('database', 'default', Object(Illuminate\Queue\WorkerOptions))
#9 /home/jaredclemence/public_html/theninjaassistant.com/vendor/laravel/framework/src/Illuminate/Queue/Console/WorkCommand.php(96): Illuminate\Queue\Console\WorkCommand->runWorker('database', 'default')
#10 [internal function]: Illuminate\Queue\Console\WorkCommand->handle()
#11 /home/jaredclemence/public_html/theninjaassistant.com/vendor/laravel/framework/src/Illuminate/Container/BoundMethod.php(32): call_user_func_array(Array, Array)
#12 /home/jaredclemence/public_html/theninjaassistant.com/vendor/laravel/framework/src/Illuminate/Container/Util.php(36): Illuminate\Container\BoundMethod::Illuminate\Container\{closure}()
#13 /home/jaredclemence/public_html/theninjaassistant.com/vendor/laravel/framework/src/Illuminate/Container/BoundMethod.php(90): Illuminate\Container\Util::unwrapIfClosure(Object(Closure))
#14 /home/jaredclemence/public_html/theninjaassistant.com/vendor/laravel/framework/src/Illuminate/Container/BoundMethod.php(34): Illuminate\Container\BoundMethod::callBoundMethod(Object(Illuminate\Foundation\Application), Array, Object(Closure))
#15 /home/jaredclemence/public_html/theninjaassistant.com/vendor/laravel/framework/src/Illuminate/Container/Container.php(590): Illuminate\Container\BoundMethod::call(Object(Illuminate\Foundation\Application), Array, Array, NULL)
#16 /home/jaredclemence/public_html/theninjaassistant.com/vendor/laravel/framework/src/Illuminate/Console/Command.php(201): Illuminate\Container\Container->call(Array)
#17 /home/jaredclemence/public_html/theninjaassistant.com/vendor/symfony/console/Command/Command.php(255): Illuminate\Console\Command->execute(Object(Symfony\Component\Console\Input\ArgvInput), Object(Illuminate\Console\OutputStyle))
#18 /home/jaredclemence/public_html/theninjaassistant.com/vendor/laravel/framework/src/Illuminate/Console/Command.php(188): Symfony\Component\Console\Command\Command->run(Object(Symfony\Component\Console\Input\ArgvInput), Object(Illuminate\Console\OutputStyle))
#19 /home/jaredclemence/public_html/theninjaassistant.com/vendor/symfony/console/Application.php(1011): Illuminate\Console\Command->run(Object(Symfony\Component\Console\Input\ArgvInput), Object(Symfony\Component\Console\Output\ConsoleOutput))
#20 /home/jaredclemence/public_html/theninjaassistant.com/vendor/symfony/console/Application.php(272): Symfony\Component\Console\Application->doRunCommand(Object(Illuminate\Queue\Console\WorkCommand), Object(Symfony\Component\Console\Input\ArgvInput), Object(Symfony\Component\Console\Output\ConsoleOutput))
#21 /home/jaredclemence/public_html/theninjaassistant.com/vendor/symfony/console/Application.php(148): Symfony\Component\Console\Application->doRun(Object(Symfony\Component\Console\Input\ArgvInput), Object(Symfony\Component\Console\Output\ConsoleOutput))
#22 /home/jaredclemence/public_html/theninjaassistant.com/vendor/laravel/framework/src/Illuminate/Console/Application.php(93): Symfony\Component\Console\Application->run(Object(Symfony\Component\Console\Input\ArgvInput), Object(Symfony\Component\Console\Output\ConsoleOutput))
#23 /home/jaredclemence/public_html/theninjaassistant.com/vendor/laravel/framework/src/Illuminate/Foundation/Console/Kernel.php(131): Illuminate\Console\Application->run(Object(Symfony\Component\Console\Input\ArgvInput), Object(Symfony\Component\Console\Output\ConsoleOutput))
#24 /home/jaredclemence/public_html/theninjaassistant.com/artisan(37): Illuminate\Foundation\Console\Kernel->handle(Object(Symfony\Component\Console\Input\ArgvInput), Object(Symfony\Component\Console\Output\ConsoleOutput))
#25 {main}
I believe the problem starts and will be solved by fixing the trace at item #4 where the following is called: Illuminate\Queue\Jobs\Job->resolve(NULL). I see this in both failing jobs on the GoDaddy server, but it does not happen in local. I don't know enough about laravel to understand where the NULL value is coming from and how to fix it. This occurs before the job class is loaded, but it does not happen for all queued jobs. Only jobs of this class.
In both the local copy and the production copy I use the GoDaddy databases, so both systems talk to the same database host. I use a database named CMP_dev and CMP_core to differentiate between the development and production tables. Because I am using the same database source, I can rule out changes in the mysql settings.
I upgraded all composer packages and retested. Then, I committed the composer.lock file and updated the GoDaddy server to match. So, I can rule out problems with old buggy code that have already been fixed by someone else.
The PHP version on the server is 7.3.11, and the PHP version on local dev is 7.3.6. The good news is that they are both 7.3.X, which reduces risk of language variations, but there still may be an issue between 7.3.6 and 7.3.11, but GoDaddy does not allow me to control the PHP setting beyond the minor version number of 7.3.
---- Added on January 09, 2020------
I thought it might be the difference in web servers. On my local machine, I use php artisan serve to host the software. On GoDaddy, I use Nginx. However, then I realized that it is not the server that runs the queue. The command line runs the queue, and both commands are being run using php artisan schedule:run. This rules out the web server software and all its components.
---------
I have successfully run queued mail jobs, which means that the queue works. This should localize the issue to the two classes that are generating problems for me. If I can find the issue with one, I will likely find the issue with the second, so I will include the first job causing issue here:
app/Jobs/ConvertCsvFileToIntermediateFile.php:
namespace App\Jobs;
use Illuminate\Bus\Queueable;
use Illuminate\Contracts\Queue\ShouldQueue;
use Illuminate\Foundation\Bus\Dispatchable;
use Illuminate\Queue\InteractsWithQueue;
use Illuminate\Queue\SerializesModels;
use App\ContactCsvFile;
use Illuminate\Support\Facades\Log;
class ConvertCsvFileToIntermediateFile implements ShouldQueue
{
use Dispatchable, InteractsWithQueue, Queueable, SerializesModels;
public $timeout = 500;
/** #var ContactCsvFile */
private $file;
private $delegate;
/**
* Create a new job instance.
*
* #return void
*/
public function __construct(ContactCsvFile $file, $delegate = null)
{
$this->file = $file;
$this->delegate = $delegate;
}
/**
* Execute the job.
*
* #return void
*/
public function handle()
{
$this->file->process($this->delegate);
}
}
The error is occurring before handle() is ever called. I know this because, when I include a dd($this->file) as the first line of handle, the line is never reached.
Also, I think it is important to note that when most jobs fail, their class name is listed in the queue:failed table. But in this case, the queue:failed table reads the time: "2020-01-08 09:23:23."
+----+------------+---------+---------------------+-----------+
| ID | Connection | Queue | Class | Failed At |
+----+------------+---------+---------------------+-----------+
| 2 | database | default | 2020-01-08 09:23:23 | |
+----+------------+---------+---------------------+-----------+
You have to read laravel 6.10 release notes.. Some functions deprecated and fixes.
I think you have to add php unit 9 instead of v8 not supported and add it to composer required not dev
I still do not know what the meaning of the error is or how to fix it. However, I found a way around the issue, which I will describe here in case it helps any others with this problem.
I began to suspect that the strange database entries that appeared in the queue:failed table were an indication that something terrible happened to cause the program to fail during execution, which maybe led to a partial write to the database. This does not make sense to me as a logical solution since I have the jobs running within a transaction that should roll back on failure.
That being said, I looked at a potential memory bloat issue and a timeout issue. I've been having trouble with the timeouts, but the classes are already set for public $timeout = 500;, which should guarantee a full 500 seconds before the job fails (These jobs were failing in less than one minute). Even though the class allows for 500 seconds, GoDaddy can limit the amount of time that a process runs, so it is possible that the process took too long.
GoDaddy can also limit the amount of memory allowed to each process. Since the jobs worked on large arrays of data, it is possible that the length of time issue and the memory bloat issue could be solved by creating one job for each item instead of creating one job to iterate the array.
This is how I solved the problem. I did create a job that processed just one item. Instead of sending the whole array to one job, I iterated the array and sent each item to a job. I thought that this would increase the amount of time it took for the system to process each item, since the program has to bootstrap the application for each job as it loads, and now I have hundreds of jobs instead of one. However, if the total time increased, the time to process a single job would certainly decrease, because the job only processed a single item and then closed. Once I made this change, the GoDaddy server stopped throwing the NULL errors, and everything ran well.
I was also surprised to see that the smaller jobs also completed faster than the single job with the array. Even though the system had to bootstrap the application on each job, the system ran much faster when memory was not overloaded.
First things first I am new to Prestashop.
I have two issues. First is when I'm in the maintenance mode and I add my ip adres to gain access, I still can't access my frontoffice. This gives server error in my Chrome Browser.
But the bigger issue is when I turn the Maintenance mode off (and deleting my IP adress from the list) There is nothing. Just a blank screen. After a little research I found how to turn the error reporting on in defines.inc.php like this:
/* Debug only */
define('_PS_MODE_DEV_', true);
After this I got this error(s):
Fatal error: Uncaught exception 'SmartyCompilerException' with message 'Syntax Error in template "/home/.sites/78/site58/web/modules/categoriesbar/category-bar-level.tpl" on line 8 "{include file=$tpl_dir./category-tree-branch.tpl node=$child last='true'}" - Unexpected "/", expected one of: "{" , "$" , "identifier" , INTEGER' in /home/.sites/78/site58/web/tools/smarty/sysplugins/smarty_internal_templatecompilerbase.php:665 Stack trace: #0 /home/.sites/78/site58/web/tools/smarty/sysplugins/smarty_internal_templateparser.php(3144): Smarty_Internal_TemplateCompilerBase->trigger_template_error() #1 /home/.sites/78/site58/web/tools/smarty/sysplugins/smarty_internal_templateparser.php(3209): Smarty_Internal_Templateparser->yy_syntax_error(40, '/') #2 /home/.sites/78/site58/web/tools/smarty/sysplugins/smarty_internal_smartytemplatecompiler.php(105): Smarty_Internal_Templateparser->doParse(40, '/') #3 /home/.sites/78/site58/web/tools/smarty/sysplugins/smarty_internal_t in /home/.sites/78/site58/web/tools/smarty/sysplugins/smarty_internal_templatecompilerbase.php on line 665
any help would be appreciated :)
P.S.
I upgraded the Prestashop from 1.2.x to the 1.5.4 version...
Maybe it has something to do with this?
The error tells you there is an error in the template. Try changing the line to
{include file="$tpl_dir./category-tree-branch.tpl" node=$child last='true'}
I'm currently receiving the following error message with Zend Framework and Doctrine. I'm trying to figure out how to solve this issue..
Fatal error: Uncaught exception 'LogicException' with message 'Passed array does not specify an existing static method (class 'Doctrine' does not have a method 'modelsAutoload')' in /home/bellalun/library/Smallunch/lib/Bootstrap.php:173 Stack trace: #0 /home/bellalun/library/Smallunch/lib/Bootstrap.php(173): spl_autoload_register(Array) #1 /etc/ZendFramework/1.9.0/Zend/Application/Bootstrap/BootstrapAbstract.php(660): Bootstrap->_initDoctrine() #2 /etc/ZendFramework/1.9.0/Zend/Application/Bootstrap/BootstrapAbstract.php(613): Zend_Application_Bootstrap_BootstrapAbstract->_executeResource('doctrine') #3 /etc/ZendFramework/1.9.0/Zend/Application/Bootstrap/BootstrapAbstract.php(577): Zend_Application_Bootstrap_BootstrapAbstract->_bootstrap(NULL) #4 /etc/ZendFramework/1.9.0/Zend/Application.php(324): Zend_Application_Bootstrap_BootstrapAbstract->bootstrap() #5 /home/bellalun/application/bootstrap.php(14): Zend_Application->bootstrap() #6 /home/bellalun/public_html/dev.php(8): require('/home/bellalun/...') #7 {main} thrown in /home/bellalun/library/Smallunch/lib/Bootstrap.php on line 173
Here's what's on line 173
$this->getApplication()->getAutoloader()
->pushAutoloader(array('Doctrine', 'autoload'));
spl_autoload_register(array('Doctrine', 'modelsAutoload'));
$manager = Doctrine_Manager::getInstance();
$manager->setAttribute(Doctrine_Core::ATTR_AUTO_ACCESSOR_OVERRIDE, true);
My hosting company made some changes over the weekend that messed up a few of my sites, taking them down. They switched me from Apache to LiteSpeed and my PHP handler from DSO to SuPHP. Not sure if this is related or not..
I don't use Doctrine, but the code sample you've posted doesn't make a lot of sense. On the first line you're registering Doctrine's autoload function with the ZF autoloader. This looks good, and seems to match this tutorial. On the next line, you're registering another autoloader with SPL directly (this is bad), and doing so using another, apparently non-existent function (modelsAutoload). Since this is the line that's erroring I'd guess commenting that line out will fix your problem.
I need to convert a dynamic web page to pdf... So as a start, I use this code for practice,
This works fine as long as I use the directory c:/test.php. But everytime I change the directory to something like d:/xampp/htdocs/test.php I get the error message:
Fatal error: Uncaught exception 'PDFlibException' with message 'pdf_begin_document() expects exactly 3 parameters, 2 given' in D:\xampp\htdocs\mypdftest\pdf_file.php:1… Stack trace: #0 D:\xampp\htdocs\mypdftest\pdf_file.php(1… pdf_begin_document(Resource id #2, 'test.pdf') #1 {main} thrown in D:\xampp\htdocs\mypdftest\pdf_file.php on line 18
Please tell me what's going wrong and how to fix it... Any help is appreciated...
Read the documentation on this one. It seems that the function pdf_begin_document() accepts 3 mandatory parameters, which are:
PDF_begin_document($pdfdoc, $filename, $optlist );
where $optlist is an option list (not much documentation here), like this example:
$optlist = "destination={page=1 type=fixed zoom=1 top=100 left=50}";
I am trying to athenticate from the elgg local server.
by refering
http://www.danielansari.com/wordpress/2008/12/how-to-use-the-rest-api-in-elgg-11/
I am getting following error:
Status: **** ERROR (-1) ****
Message: Method call 'login' has not been implemented.
Result: exception 'APIException' with message 'Method call 'login' has not been implemented.' in C:\xampp\htdocs\elgg1.6.1\engine\lib\api.php:562
Stack trace:
#0 C:\xampp\htdocs\elgg1.6.1\services\api\rest.php(46): execute_method()
#1 C:\xampp\htdocs\elgg1.6.1\engine\lib\api.php(1219): include('C:\xampp\htdocs...')
#2 C:\xampp\htdocs\elgg1.6.1\engine\lib\pagehandler.php(42): api_endpoint_handler('login', Array, '')
#3 C:\xampp\htdocs\elgg1.6.1\engine\handlers\pagehandler.php(23): page_handler(Array, 'api')
#4 {main}
Basically my aim is to upload an image in a community made by using ELGG. But In this place only I am stuck.
How to solve it?
Well, I can't help you with that exception, but I can tell you that there is no way directly in Elgg's REST API to upload an image. I tried doing this and had to replicate the logic of the upload.php action in my own huge honking function.