I am creating a data queue using SplQueue php class and storing the queue in memcache :
$queue = new \SplQueue();
$queue->enqueue($data);
print_r($queue);
$this->getServiceLocator()->get('memcached')->setItem('key', $queue);
$queue = $this->getServiceLocator()->get('memcached')->getItem('key');
print_r($queue);
Last print_r is giving blank result like this :
SplQueue Object
(
[flags:SplDoublyLinkedList:private] => 4
[dllist:SplDoublyLinkedList:private] => Array
(
)
)
But first print_r is giving generated queue as expected. This code is working fine on my local system but generating above mentioned issue on production server.
Note:- Memcahced version is same on both machines 1.4
Any help will be appreciated..!!
While googling, i found here that it's a issue with serialization of SplDoublyLinkedList class in PHP version lower that 5.4. SplDoublyLinkedList::serialize was not working on production server (as server was running with PHP 5.3) and there is no alternative solution to do that except upgrading the PHP version to 5.4.
Related
My goal is to make new Laravel app that is going to use old database created by Yii.
The database hash is $2a$07$6c2eb62b00df224f3d20$.qzdiDRZejMnGytXWsA7Jid7RpWazDc6.
When I run password_verify('...','$2a$07$6c2eb62b00df224f3d20$.qzdiDRZejMnGytXWsA7Jid7RpWazDc6) in a test.php (by php test.php) in PHP 7.4, it returns true.
When I run the same code inside Laravel (e.g. in php artisan tinker or a web route), in PHP 8.2, it returns false.
What can be the reason, and how to validate hashes that were previously made by, supposedly, older version of PHP (but they work in 7.4), with laravel in the latest PHP version?
In both cases the algo is unknown:
Array
(
[algo] =>
[algoName] => unknown
[options] => Array
(
)
)
Getting this error when trying to send a simple email:
Class setQueue does not exist at vendor/laravel/framework/src/Illuminate/Container/Container.php:779)
Here is the code causing it:
Mail::raw($data['email_body'], function (Message $message) use ($email_or_url, $data) {
$message->to($email_or_url);
$message->subject($data['email_subject']);
});
Why would Laravel be trying to queue this and how do I make it stop?
bug case in laravel project for this issue. https://github.com/laravel/framework/issues/26819
It turned out to be a problem in php. Laravel has patched it so you have 2 options to fix. Use the patch version and hope there aren't other places php 7.3 breaks laravel, or downgrade your project to 7.2
I am also facing the same issue in MacBook Pro. For MacBook Users just use command
"valet restart"
In my case, it's working now. Try to restart your server that might be helpful.
Note: I am using PHP 7.3.*
Make sure you rename your QUEUE_DRIVER environment variable to QUEUE_CONNECTION in both config/queue.php and .env - it was renamed in 5.7
https://laracasts.com/discuss/channels/laravel/trying-to-send-email-class-setqueue-does-not-exist
Why would Laravel be trying to queue this and how do I make it stop?
It's not trying to queue this email, but MailServiceProvider still registers a queue driver (for when an email implements the ShouldQueue interface).
it happens to me because i was running php 7.3, when i downgrade to php 7.2.13 it works, and i also change the QUEUE_DRIVER variable in .env and config/queue.php
What I've found by now in my research for the solution is that in my case it is not about the php version (I even reinstalled everything and changed my servers providers because of the laracasts answers) but it was a code caused error, and I know because i reverted to previous commit and it worked fine.
In my case it was because I had a transaction before the email sending
$suma = $user->transactionsAsUser->filter(
function ($transaction) {
return $transaction->status == 'successful' || $transaction->kanjea_ammount < 0;
}
)->sum('kanjea_ammount');
$user->kanjea_balance = $suma;
$user->save();
\Mail::to($user->email)->send(new \App\Mail\JustRegistered($user));
When I removed that fragment before the last line, it just worked fine. Even using PHP 7.3.
By the way. this problem doesn't occur in my local environment w7+xampp, but only dokku
My solution was to valet install again as I got the error after running brew update/upgrade
related details:
PHP 7.3.0 (cli) (built: Dec 7 2018 11:00:11) ( NTS )
I'm using the PECL D-Bus extension with PHP 5.5 on Ubuntu 14.04 to interract with Clementine.
As for now I'm able to connect to the session bus (exceptions are throwns when any error occurs), but when I initialize the proxy object I get an empty DbusObject, so I'm unable to call the D-Bus methods.
Here is the code I use (inspired from the extension usage examples) :
$dbus = new Dbus(Dbus::BUS_SESSION);
$clementine_player_proxy = $dbus->createProxy('org.mpris.clementine', '/Player', 'org.freedesktop.MediaPlayer');
var_dump($clementine_player_proxy); // returns "object(DbusObject)#3 (0) {}"
Of course I checked with d-feet if the bus name, the object path and the interface exists :
I'm stuck for two days.
Edit : submitted bug on the PHP bugreport.
Edit 2 : tested with another method (Addtrack(string, bool)) with another object path (/TrackList). It works. I don't understand.
I ended up to learn Python to properly use D-Bus with ease via the dbus module (as said in the Clementine's wiki).
I recommend to everyone who wants to use the PHP D-Bus extension to not do so : it is buggy, tricky and it has no documentation (except example scripts).
I have a php web application that needs to access a PI-Datasource using an application-library written for windows on dll form to fetch the data. Due to the non-polimorphism of PHP we are using a wrapper written in C#-Dotnet in order to use the polimorphism library.
PHP->Wrapper->Lib->PI-System
The problem: PHP crashes, without leaving a log, on the creation of the com object (almost always on every second request). My thought was that probably something in the existing php code could be wrong that causes this fatal-error and after a lot of debugging and trying I simplified the code to this:
$connection = new Com('Something.SomethingClass');
with the variable $connection not being used NEVER! and still every 2nd time I get php-crash (documented in windows error log with an 1000-Error and an 1001-Information)
>Faulting application name: php-cgi.exe, version: 5.4.11.0, time stamp: 0x511a30ec
>Faulting module name: KERNELBASE.dll, version: 6.1.7601.17932, time stamp: 0x503275ba
>Exception code: 0xc0000005
>Fault offset: 0x0000d3cf
>Faulting process id: 0x14d0
>Faulting application start time: 0x01ce89dd0ae23748
>Faulting application path: C:\Program Files\Zend\ZendServer\bin\php-cgi.exe
>Faulting module path: C:\Windows\system32\KERNELBASE.dll
So i tried to generate even more com objects..
$connArray = array();
for($i = 0; $i < 50 ; $i++){
Core_System_Log::getInstance()->logWithoutMessageId('Before: ' . $i ,Core_System_Log::DEBUG);
$connArray[i] = new Com('Something.SomethingClass');
Core_System_Log::getInstance()->logWithoutMessageId('After: ' . $i, Core_System_Log::DEBUG);
}
All 50 were generated with no problem, and again every 2nd time i tried i got a php fatal error.
I tried to used all 50 of them, and they all read values from the PI-System with no problem.
I tried to unset the variables and call also the gc, call the destructor from C#, check the constructor from C# (which just makes an object of the library and had no exception, the object was normally created and still php crashed) but the problem did not disappear.
So, is there any idea? am i doing something wrong (how can it be wrong when every 2nd time it is properly reading the values)?
Environments Tested:
OS:Windows Server 2008 R2 64Bit / Windows 7 Prof SP1 32/64Bit
PHP: 5.3.9/ 5.3.14 / 5.3.21 / 5.4.11
WS: Apache and IIS (few different versions)
UPDATE: The problem was finally in the C# code. There was a call to GC which did not allow the COM object to be closed/deleted correctly having as a result C# to hang (again with no exception) and "triggering" the php fatal error.
Thanks for the responses.
If returns crashed without logging into file it look that in code contains sign #.
Example:
#some_function()
This will call function, but if has any errors it will not showing to you, just skipping. Due to some errors PHP can be stopped.
But, can you try upgrade PHP to 5.5 on Windows server?
If you know in which of lines of code throws an error and want to skip, just put isset()
If isset($somevar) or isset(function()) returns true that means are not errors, but if you don't want to stop a function on errors put isset() on a line of code where errors occurred.
I'm not sure how looks class and function inside PHP->Wrapper->Lib->PI-System code so I can tell fully corrected answer.
UPDATE: The problem was finally in the C# code. There was a call to GC which did not allow the COM object to be closed/deleted correctly having as a result C# to hang. The object was somewhere kept in Ram and the second time the wrapper was called it just hanged/exited (again with no exception) which "triggered" the php fatal error.
There already is a working WAMP instance in a Windows 7 in which the line
$x = new COM("X");
does instantiate a COM object.
I was trying to locate a bug, and decided to use a fresh new WAMP installation on the same Windows 7 system as the previous one.
In the new one, the same line produces:
Failed to create COM object 'X': Class not registered ( Error code: 0x80040154 )
Now, since the first WAMP comes with it's own installation application (along with its DLL which holds the COM class) I can't exactly figure out what I need to change in the new WAMP so the line above will instantiate the object.
My WAMP version is: 2.2 and
Apache version : 2.2.21
PHP version : 5.3.10
Any idea what I need to set up properly?
You need to register the DLL, using
regsvr32 yourdll.dll
Managed to solve the problem by changing the working directory (using chdir) to be the same as the php.exe just before $x = new COM("X");.
I think the DLL wasn't propery registered, or lacked something in itself.