Hello i have installed Parse server and parse sdk for php on my Linux Centos Server.
Parse Dashboard: 1.3.3,
Server version: 4.3.0
I'm managing those db's using php code. This parser was installed by someone else. The thing is I'm not sure how to install LiveQuery for my server. I don't know if my version of server is good for this kind of operations. I found some solutions how to enable this feature, but there was something like "index.js" - in my file system it's app.js. Screen of file system
In app.js i added lines:
liveQuery: {
classNames: ["Test"] //List of classes to support for query subscritions
}
I've created class in my db named "Test", then i found solution i need to add
this line
liveQueryUrl: keyLiveQueryUrl, // Required if using LiveQuery
I don't really know how to get this key.
How can i check if LiveQuery works? It will be used by flutter code, but i'd like to check it first in PHP.
My problem has been solved in my other extended topic here.
When making call to sodium_crypto_pwhash_str I get the following in my Apache error log file.
PHP Fatal error: Uncaught Error: Call to undefined function
sodium_crypto_pwhash_str()
My php version, as noted is 7.3.17 running on an Amazon EC2 instance.
My php-info() does not return any relevant libsodium information other than module author info:
Sodium Frank Denis
Given the above author information references a module author am I supposed to enable the sodium module? If the answer is yes is it referenced in the php.ini file? Such as:
extension=sodium
or perhaps:
extension=libsodium
What am I missing here?
Am I not supposed to use the documented function sodium_crypto_pwhash_str?
Am I supposed to use some other method of accessing the desired functionality?
Yes normally it's included in PHP 7.2+ but when you use the AWS EC2 instances this is a bit minimalistic and not everything is included.
https://www.php.net/manual/de/sodium.installation.php
Here you can see that you have to enable it during the compiling with --with-sodium[=DIR]. So you can compile it on your own or you try another distro to get it from your package manager or you use another lib to make it work.
https://forums.aws.amazon.com/thread.jspa?threadID=293187
In PHP (version 7.1), I am attempting to use a MAP as opposed to a two dimensional array to handle implicit data type conversion across different data type groups. However, I am receiving the following run-time error:
Class 'Ds\Map' not found
The error occurs on this line of code:
protected $hive_data_type_group_map = new \Ds\Map();
I have checked online, but there is little documentation on Ds\Map, even on PHP's website (click here). Does anyone know how to fix this?
Data Structures is not a built-in PHP extension.
It needs to be installed before use. The installation instructions are available on php.net.
For windows
Download compiled-dll file "php_ds.dll" from https://pecl.php.net/package/ds. Place it in your dir wamp\bin\php\[your_php_version_folder]\ext and include it in your ".ini" file.
It worked for me.
the easiest way on ubuntu:
pecl install ds
Reference: https://www.php.net/manual/en/ds-deque.allocate.php
I installed the MongoDB PHP driver on Windows 10 (I'm using WAMP equipped with PHP 5.6.25. following the istructions I found at http://php.net/manual/en/mongodb.installation.windows.php and I installed also the libbson and libmongoc libraries (requested as requirements) as written at http://php.net/manual/en/mongodb.requirements.php.
Then, I added the bin folders of MongoDB, libbson and libmongoc to system path.
However, even if I can see the php_mongodb extension in the extensions list of WAMP, launching phpinfo() the mongo extension doesn't appear with the others.
Furthermore, tryng to connect to my database with
<?php
$mongo=new MongoClient("");
$db=$mongo->galileo;
$collection= $db->items;
print_r("Number of documens: "); ?>
I got the error
Fatal error: Class 'MongoClient' not found in C:\wamp64\www\galileo\index.php >on line 21
At a first look, reading this error, it might seem like that PHP is looking for php_mongodb extension in the uncorrect folder i.e. C:\wamp64\www\galileo\index.php (where the index page of my project is placed) instead of the correct one C:\wamp64\bin\php\php5.6.25\ext where all the extensions are.
But, looking at php log file php_error.log I find also a warning that says:
PHP Warning: PHP Startup: Unable to load dynamic library 'c:/wamp64/bin/php/php5.6.25/ext/php_mongodb.dll' - Il sistema operativo non pu� eseguire %1.
in Unknown on line 0.
(for not Italian speaking, the phrase after - means the operating system can't execute %1, even if I can't imagine what %1 stands for).
Even using the new class MongoDB\Driver\Manager I get the error
Fatal error: Class 'MongoDB\Driver\Manager' not found in C:\wamp64\www\galileo\index.php on line 21
and the same warning.
Do you notice some error or forgetfulness in the installation process as I described and, if not, do you know how to fix the problem?
The problem is certainly related to WAMP and I think is related to the multiple php.ini in his folders. In fact, in the apache folder you can find a php.ini file that cannot be modified, otherwise nothing works at all; at the same time any changes made to the php.ini file in the php folder seems have no effect except making appear the mongodb extension in the extensions list.
So, I try using XAMPP, as suggested in this video tutorial and it works. Using Composer I was able to install also the PHP library and not only the driver.
you should not use 'MongoClient class' anymore, this extension that defines this class is deprecated. look at here.
instead, you should use MongoDB\Driver\Manager class. please read http://php.net/manual/en/class.mongodb-driver-manager.php.
and the setup must be like this in php:
$mongo = new MongoDB\Driver\Manager("mongodb://localhost:27017");
And if you still use the old class; you either need to install the old legacy extension (pecl install mongo) and use PHP 5.x, or update your code to use this new driver's classes as the old driver is not available for PHP 7. There is an upgrade guide at here.
the last part is from derickr's answer in this issue on github: https://github.com/mongodb/mongo-php-driver/issues/300
When a PHPUnit test fails normally on my dev box (Linux Mint), it causes a "Segmentation Fault" on my Continous Integration box (Centos). Both machines are running the same version of PHPUnit. My dev box is running PHP 5.3.2-1ubuntu4.9, and the CI is PHP 5.2.17. I'd rather leave upgrading the PHP as a last resort though.
As per this thread: PHPUnit gets segmentation fault
I have tried deactivating / reinstalling Xdebug. I don't have inclue.so installed.
On the CI box I currently only have two extensions active: dom from php-xml (required for phpunit) and memcache (required by my framework), all the others have been turned off.
Next to what cweiske suggests, if upgrading PHP is not an option for you and you have problems to locate the source of the segfault, you can use a debugger to find out more.
You can launch gdb this way to debug a PHPUnit session:
gdb --args php /usr/bin/phpunit quiz_service_Test.php
Then type in r to run the program and/or set environment variables first.
set env MALLOC_CHECK_=3
r
You might also consider to install the debugging symbols for PHP on the system to get better results for debugging. gdb checks this on startup for you and leaves a notice how you can do so.
I've had an issue with PHPUnit segfaulting and had trouble finding an answer, so hopefully this helps someone with the same issue later.
PHPUnit was segfaulting, but only:
If there was an error (or more than one)
After all tests had run but before the errors were printed
After a while I realized that it was due to failures on tests that used data providers, and specifically for data providers that passed objects with lots of recursive references. A bell finally went off and I did some digging: the problem is that when you're using data providers and a test fails, PHPUnit tries to create a string representation of the provided arguments for the failure description to tell you what failed, but this is problematic when one of the arguments has some infinite recursion. In fact, what PHPUnit does in PHPUnit_Framework_TestCase::dataToString() (around line 1612) is print out all the arguments provided by the data provider using print_r, which causes the segfault when PHP tries to create a string representation of the infinitely recursive object.
The solution I came to was:
Use a single base class for all my test classes (which fortunately I was already doing)
Override dataToString() in my test base class, to check for these kinds of objects in the data array (which is possible in my case because I know what these objects look like). If the object is present, I return some special value, if not I just pass it along to the parent method.
I had similar problem and by disabling the garbge collactor in
PHPStorm => Edit configuration => Interpreter option : -d
zend.enable_gc=0
Or if you are running your tests from the command line you may try adding :
-d zend.enable_gc=0
When you get a segfault, upgrade your PHP to the latest version. Not only the latest in your package manager, but the latest available on php.net. If it still segfaults, you are sure that the problem has not been fixed yet in PHP itself. Don't bother trying to get rid of a segfault in old version of PHP because it might have been fixed already in a newer one.
Next step is to locating the problem: Make your test smaller and smaller until you can't remove anything (but it still segfaults). If you have that, move the test into a standalone php script that segfaults. Now you have a test script for your bug in the PHP bug tracker.
In addition to https://stackoverflow.com/a/38789046/246790 which helped me a lot:
You can use PHP function gc_disable();
I have placed it in my PHPUnit bootstrap code as well with ini_set('memory_limit', -1);
I had the same problem and could nail it down, that I tried to write a class variable which was not definied:
My class (it's a cakePHP-class) which caused segmentation fault:
class MyClass extends AppModel {
protected $classVariableOne;
public function __construct($id = false, $table = null, $ds = null) {
parent::__construct($id, $table, $ds);
$this->classVariableOne =& ClassRegistry::init('ClassVariableOne');
// This line caused the segmentation fault as the variable doesn't exists
$this->classVariableTwo =& ClassRegistry::init('ClassVariableTwo');
}
}
I fixed it by adding the second variable:
class MyClass extends AppModel {
protected $classVariableOne;
protected $classVariableTwo; // Added this line
public function __construct($id = false, $table = null, $ds = null) {
parent::__construct($id, $table, $ds);
$this->classVariableOne =& ClassRegistry::init('ClassVariableOne');
$this->classVariableTwo =& ClassRegistry::init('ClassVariableTwo');
}
}
Infinite recursion is normally what causes this issue for us. The symptoms of infinite recursion seem to be different when running code under phpunit, than they are when running it in other environments.
If anyone comes across this in relation to PHPunit within Laravel
It took a while to figure out what the issue was. I was going over the differences between my current code and the previous revision and through some trial and error finally got there.
I had two different models that were both including each other with the protected $with override.
This must have been causing some kind of loop that phpunit could not deal with.
Hopefully someone finds this useful.
Please update to the newest XDEBUG. Got the same error while using v3.1.5, and after upgrading to 3.1.6 eveything works.
I got into the same problem. I upgraded the PHPUnit to the 4.1 version (to run the tests) and it was able to show me the object, as pointed by Isaac.
So, if you get to this very same problem, upgrade to PHPUnit >= 4.1 and you'll be able to see the error instead of getting "Segmentation fault" message.
I kept getting a Segmentation fault: 11 when running PHPUnit with Code coverage. After doing a stack trace of the segmentation fault, I found the following was causing the Segmentation fault error:
Program received signal SIGSEGV, Segmentation fault.
0x0000000100b8421a in xdebug_path_info_get_path_for_level () from /usr/lib/php/extensions/no-debug-non-zts-20121212/xdebug.so
I replaced my current xdebug.so in the path above with the latest version from the Komodo Remote Debugging Package the sub-folder of the corresponding downloaded package with the PHP version I have (which is 5.5 for me) and everything worked.
The following fixed a similar issue for me (when the output of the gdb backtrace included libcurl.so and libcrypto.so):
disable /etc/php.d/pgsql.ini:
; Enable pgsql extension module
; extension=pgsql.so
edit /etc/php.d/curl.ini to ensure that pgsql.so is included before curl:
; Enable curl extension module
extension=pgsql.so
extension=curl.so
curl.cainfo=/home/statcounter/include/config/cacert.pem
if you have an object with property pointing to the same object, or other sort of pointer loops, you will have this message while running
serialize($object);
And if you are a Laravel user, and you are dealing with models. And if you think, you will never have this problem, because you avoiding pointer loops by using $hidden property on your models, please be advised, the $hidden property does not affect serialize, it only affects casting to JSON and array.
I had this problem, when I had a model saved into a property of a Mailable object.
fixed with
$this->model->refresh();
in a __construct method , just before the whole object is serialized.
This related to code not extension. In my case i had these two files
Test Case
Example Test
In Test Case there is method called createApplication. Just leave it empty.
In Example Test you can create the method and fill with
$this->assertTrue(true)
Above is basic setup hope you can extend the requirement as you need.