I want to generate a report with PHPUnit: sudo phpunit --coverage-html ./phpunit-report src/ but I get the following error: Error: No code coverage driver is available. After some research on web I found that I've to enable the PHP extension xdebug and I do so in the file /opt/lampp/etc/php.ini on line: zend_extension="/usr/lib/php5/20131226/xdebug.so" After doing it so, I realize that the extension is enable as I can see it on symfony toolbar:
But when I try to see the xdebug extension using CLI :php -m | grep xdebug I get null. Same thing with php -i | grep xdebug. Then at that point I really don't know whether the extension has not been enabled properly or ... any help please. Notice that when I load phpinfo() I also see the xdebug extension like this:
You need to activate Xdebug for the CLI SAPI. That binary uses a separate PHP configuration file (php.ini), not the one used by the webserver.
Related
good day!
I installed arcanist with:
git clone https://github.com/phacility/libphutil.git
git clone https://github.com/phacility/arcanist.git
but when I'm doing arc help, I get error like this:
$ arc help
PHP CONFIGURATION ERRORS
You need to install the cURL PHP extension, maybe with 'apt-get
install php5-curl' or 'yum install php53-curl' or something similar.
but I can run this: curl " XXXX ", it's ok. and curl_init() also is run . with phpinfo()， I can see curl enable. But I don't know why get this error when I'm doing arc command.
Can you help me? Thanks!
and system information:
my php version : 5.6.3
vagrant box on mac
You need to make sure curl extension is enabled for CLI SAPI (likely in /etc/php5/cli/conf.d/ folder). CLI and web (mod-php or fpm) configurations are separate, so it very well may happen that extension is enabled when PHP is used through web server, but disabled when you run in as a CLI executable.
Before adding the extension to php.ini file using a php script, I want to check if the extension is a zend extension just to avoid the error that happened when I load it as normal extension.
Interesting question, and it still needed and answer.
You can check a PHP extension (a shared object file on linux)
is a zend extension and
it can be loaded from a specific PHP version from the CLI SAPI [doc].
Here a shell example asserting that a compiled .so file can be loaded:
php -n -dzend_extension="$PWD/modules/xdebug.so" \
-r 'echo implode("\n", get_loaded_extensions(true)), "\n";' \
| LC_ALL=C grep -i xdebug
This (complex) shell command returns non-zero when the file ./modules/xdebug.so does not result in having PHP the extension named "xdebug" (case insensitive).
If you need this within a PHP script, you could use passthru() [doc] or exec() [doc] with the $result_code out-parameter.
For example to test before installing the file in the extension directory [ini] and activate it in the ini.
On standard error you'll find as well diagnostic messages when it fails to load.
E.g. loading a zend extension for PHP 5.3 with PHP 5.6:
$ php5.6 -n -dzend_extension="$PWD/modules/xdebug.so" \
-r 'echo implode("\n", get_loaded_extensions(true)), "\n";' \
| LC_ALL=C grep -i xdebug
Failed loading /home/hakre/install-php5.3/xdebug-2.2.7/modules/xdebug.so:
/home/hakre/install-php5.3/xdebug-2.2.7/modules/xdebug.so: undefined symbol: php_body_write
$ echo $?
1
Some remarks:
The -n switch reduces side-effects from configuration, it disables standard ini loading completely leaving you with the compiled in default values (you may want to run it as well without, it might show more zend extensions then).
The $PWD [posix] is for the current working directory, it is best to pass an absolute path to the zend_extension directive on the command-line (-dzend_extension=<extension-path>) as with a relative path PHP will look as well in different directories if loading fails where you just want it to fail (or succeed) with exactly that binary extension file in the first place without any more look-ups.
This should give enough pointers to cover cases like upgrading an existing extension as well. It won't take the burden off you, e.g. in migration situations, to compare as well changes in an extensions ini configuration. Just saying.
New to PHP. Working on a PHP project and have xdebug enabled to be able to debug my php applications. The production server does not have xdebug enabled because it is handled by another team. On my local machine, when I run composer it gives me a warning saying
You are running composer with xdebug enabled. This has a major impact on
runtime performance.
I do not want to disable xdebug when I am developing. Just wanted to confirm that running xdebug in dev environment should have no impact on the composer installing libraries/performance of the app on the production server.
I do not want to disable xdebug when I am developing. Just wanted to confirm that running xdebug in dev environment should have no impact on the composer installing libraries/performance of the app on the production server.
There is a huge impact of just loading Xdebug. It slows the Composer run down by 3x or 4x, even when the profiling feature is not enabled.
In other words: xdebug is invaluable for debugging, but increases the memory used and processing time of Composer.
How to disable Xdebug for Composer runs?
My suggestion is to write a little invocation helper for running Composer.
The helper is a bash or batch script calling PHP with a custom php.ini, especially configured for Composer. Lets call it: php.ini-composer.
You could copy your current php.ini and adjust it for the Composer run, by removing xdebug or commenting it out, like so: ;zend_extension = "/path/to/my/xdebug.so".
While you are at it: setting memory_limit=-1 is helpful, too.
The full command looks like so on Windows: php.exe -c php.ini-composer composer.phar %*
Just clone the idea for a bash script.
And you may find the full answer to your question in the Composer FAQ.
https://getcomposer.org/doc/articles/troubleshooting.md#xdebug-impact-on-composer
It was added/updated just a few hours ago.
Some alternatives (instead of using seperate ini file) are also mentioned here.
Modern versions of Composer can work around having XDebug enabled by default for the CLI SAPI. It spawns a new PHP process with the XDebug extension disabled in case it is detected.
You can disable this behaviour by setting the following environment variable:
COMPOSER_ALLOW_XDEBUG=1
Found this in the documentation: https://getcomposer.org/doc/articles/troubleshooting.md#xdebug-impact-on-composer
Like with web scripts, expect CLI scripts to run slower as well.
If you need the added runtime performance, you can disable XDebug on CLI only. Set your PHP installation so that it uses different ini files for CLI and your server, as this answer suggests.
To fix this, prior to PHP 7 people would suggest to comment out the extension from your php.ini file.
However, in PHP 7 they are no longer in there.
Instead, we use the phpdismod command.
sudo phpdismod -s cli xdebug
The -s flag tells it to disable Xdebug for the CLI SAPI (/etc/php/7.0/cli) and not FPM.
And just like that, the warning message should be gone. No need to restart PHP.
In addition to this, there is a plugin that downloads packages in parallel to speed up the installation process.
Create a file named php-composer.ini somewhere with the following content (the minimum php config for composer):
extension_dir = "D:/php/ext/" ;according to your system
extension=php_openssl.dll
memory_limit=-1 ;optional
Now create a file named cmz.bat with the following contents. (edit paths accordingly)
#ECHO OFF
php -c "D:\php-composer.ini" "C:\ProgramData\ComposerSetup\bin\composer.phar" %*
add this file to your system path or your project root.
Now use cmz instead of composer and you will not see that message and hopefully the composer speed would be increased.
note: Some package need specific php extensions. you need to add them to php-compsoer.ini file or appending --ignore-platform-reqs switch to cmz.bat file
On a fresh download of Symfony 3.1 and PHP 7.0, you can run the following (having edited it to include the path to your composer.phar file):
php -n -d extension=json.so -d extension=phar.so -d extension=pdo.so -d extension=ctype.so /path/to/composer update
If you have any extra vendors to your composer.json file, you might find that they have a dependency on an extension, so you need to include that by adding -d extension=name_of_extension.so to the list.
What's happening here is the -n flag goes with PHP defaults - it doesn't load any ini PHP config files, so XDebug is never loaded. Then each of the -d flags allows you to dynamically set config values, so you can include extensions.
I get this error when I try to run test cases that need ionCube:
The file path/to/file.php has been encoded with the ionCube PHP Encoder and requires the free ioncube_loader_lin_5.4.so ionCube PHP Loader to be installed.
Fatal error occurred in test case Class_Name->testCaseName.
TearDown for fatal-error-failed-test and tearDownAfterClass were successfully called after fatal error occurred.
I have PHPUnit 4.5.0.
ionCube is installed correctly as I can see it with phpinfo() and the website is working.
PHPUnit may be using a different php.ini file than your website, so you'll see the ionCube Loader on a webpage generated by <?php phpinfo();.
To confirm, type in php -i to see the CLI version of phpinfo() (or php -i | grep -i ioncube to see if the ionCube Loader is installed, and php -i | grep "Loaded Configuration File" to see where your CLI PHP configuration file lives).
Do note that PHPUnit may be using a completely different php.ini file still - you'll have to look into your own setup for more details.
Once you've located the configuration file, you should be able to copy and paste the zend_extension line from your working php.ini file, provided you have the same PHP setups for both CLI and CGI.
If you're stuck and/or it's still not working, you can also create a ticket at ionCube's Helpdesk.
I'll make this quick.
I installed Oracle 11g (with appropriate database, users, etc), Apache 2.4.6, and PHP 5.5.4 on a Fedora 19 system.
I wanted to connect PHP to Oracle. What I really wanted to do was to download MDB2_Driver_oci8, which I thought would be easy, but before I can do such a thing, PHP needs to have that plug-in enabled, so here's what I did:
Tried to install oci8 via the following: pecl install oci8
When that didn't exactly work the first few times, I figured out I, for some reason, needed "Development tools" - via yum groupinstall "Development Tools"
Then I figured out later that PHP actually doesn't do oci8 - it's PHP Devel. So, I had to install that too, via yum install php-devel.
And then, I finally got to install oci8. It asked for the Oracle Directory, and that was that. But it said the following:
Configuration option 'php_ini' is not set to php.ini location
You should add 'extensions=oci8.so' to php.ini
First, I did a locate oci8.so - found it in /usr/lib64/php/modules/
Second, I added what it told me to, to the php.ini file.
Third, I checked the usual php_info() test page - no mention of OCI8. Uh-oh.
Fourth, running both php -i and php -m listed oci8 as one of the modules. Weird.
In desperation, I went ahead and downloaded the MDB2_Driver_oci8. Maybe that will fix things. Nope.
When I loaded my PHP Webpage, it returned the following:
Error message: extension oci8 is not compiled into PHP
As well as: MDB2 error: not found
Strange. And then I decided to check the error logs:
PHP Startup - unable to load dynamic library '/usr/lib64/php/modules/oci8.so' - libclntsh.so.11.1: cannot open shared object file: No such file or directory in Unknown on line 0
And now I'm stuck. I tried going into the php.ini, and found that the extension_dir was commented out. I put it back in, which only seemed to break stuff.
Things of note:
I followed this (link) guide on how to configure PHP and install oci8.
./configure --with-oci8 doesn't work. Fedora says no such directory.
As both the webpage files and the actual server reside on the same PC, I did not install the Oracle Client files.
The extension_dir is commented out by default in the php.ini.
This is just one of my problems in a long line of problems concerning the replication of an already existing and working, but dying, setup. It seems whenever I want to solve a problem, I have to do X first. And by doing X, I uncover another problem, which I have to solve by doing Y, which has its own problems, etc, etc.
Any help would be much appreciated. Thanks.
I know this question is a bit old - but I'm writing this here incase others come looking for the solution.
PHP Extensions Directory
To get your PHP extensions directory, run this command
php-config --extension-dir
ORACLE configuration
When you run the config command for oracle, you need to provide it with your Oracle Home directory (this assumes you have installed ORACLE XE):
./configure -with-oci8=shared,$ORACLE_HOME/xe
SELinux policy
You need to adapt your SELinux policy to support what you are trying to achieve. Disabling it completely is not recommended.
On your Fedora system, try running:
which audit2allow
If you receive an error that indicates it cannot find audit2allow then you need to install this package:
yum install policycoreutils-python
Once you have this package, you can pipe your audit log files into audit2allow to have it create your policy file:
grep httpd /var/log/audit/audit.log | audit2allow -m httpd > http.te
This will create the file http.te that is human readable for you to review what the policy additions are that it will make to your SELinux configuration. If you are OK with the modifications, then run these commands (note the capital M in the following command vs. the lowercase m previously)
grep httpd /var/log/audit/audit.log | audit2allow -M httpd
semodule -i httpd.pp
This may take a few seconds to run - you can verify the policy has been installed by running:
semodule -l | grep httpd
You will need to restart httpd so that it can try to load the oci8.so plugin
service httpd restart
HTH
After reading a lot on the internet, I found this page, that indicates I should disable SELinux, and reboot.
That did the trick.