When I try to install MongoDB with composer, it complains that I don't have the mongodb extension configured in my ini files. It's looking at the regular php ini files but mine are under /fpm as I'm using nginx. How can I tell composer to use the FPM version of PHP?
I found two solutions:
(after I figured out that composer uses the php-cli configuration)
Link the php-fpm configuration into the php-cli configuration, as detailed in:
http://paulwhippconsulting.com/blog/getting-php-cli-to-match-php5-fpm-so-it-behaves-consistently-under-nginx/
This seems more elegant, but doesn't seem to be official so it may break.
Copy all your configuration directives (.ini files) to both the php-cli and the php-fpm configuration directories.
The downside of this ofcourse is that if not done carefully, your production and development environment end up having different configuration settings.
Related
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 am trying to enable XSL on Ubuntu 12.04 but its failing. I did this locally on my Ubuntu 13.04 and it was successful. Basically the following worked on my local computer.
apt-get install php5_xsl
edit php.ini file and add extension=php5_xsl.so
restart apache
I repeated the same procedures on my production server running Ubuntu 12.04 and PHP version 5.5.12 but the extension is not getting loaded from the phpinfo. I have also changed the extension=php5_xsl.so to extension=xsl.so because this is what in the extension directory.
I read that I might need to recompile PHP but I am not sure of this steps.
Try this:
sudo apt-get install php5-xsl
sudo php5enmod xsl
sudo service apache2 restart
Why:
http://www.lornajane.net/posts/2012/managing-php-5-4-extensions-on-ubuntu
What's happened here is that all debian-flavoured unixes have adopted
this standard for their PHP 5.4 packages, so if you're using debian,
ubuntu, or any of their relatives with PHP 5.4, you'll see a directory
structure like this. When you add a module to PHP, you'll add a file
to the mods-available directory enabling the module and adding any
config specific to it. If you want to enable the module, just do:
php5enmod http
This simply creates a symlink from the usual conf.d directory to point
to where the real files are in mods-available, prefixed with a number
that indicates the priority of the module. By default, the priority is
20.
Using this approach means we can toggle things on and off without
commenting out big chunks of config files and leaving them lying
around - if this seems familiar then that's no surprise; debian-like
linuxes manage their apache configuration in just the same way. Any
packages that you install using aptitude will use these exact same
commands to set up the configuration and then symlink it correctly. To
unlink, use the delightfully predictably-named php5dismod :)
So I've tried almost all the tutorials I've found here and on other sources but the problem is always the same. The extension is not installed when I call the phpinfo method.
I've added the file mongo.so to the extensions folder and I've called it on the php.ini as extension=mongo.so.
I'm using MAMP 2.2 on Mavericks and the php version is 5.5.3.
Appreciate any kind of help.
The output of phpinfo() will tell you which php.ini file (if any) is in use.
You have to modify that php.ini file and add extension=mongo.so and then restart your webserver.
One thing you need to keep in mind when you are installing the MongoDB driver for MAMP is the pecl command you are using is actually the MAMP command, not some alternative PHP install you may have on your system.
To do this, locate the PHP binary distributed with MAMP, and the use the full path to the pecl command of the MAMP installation.
I am using Laravel 3 for a project, and I've made a little cronjob script, and when I moved to the new server it keeps saying:
Warning: ob_start(): function 'mb_output_handler' not found or invalid function name
and
Notice: ob_start(): failed to create buffer
Any idea how to fix this?
The new server is Ubuntu? Are your development server and the "new server" the same OS? Same PHP versions?
It's possible the two servers are completely different!
Can you show your cronjob? (Does it attempt to use a specific php binary via a #!/usr/bin/env php call ?
One possibility for Ubuntu:
PHP run in CLI can be different from being run in Apache, and especially is likely different if you're using php5-fpm with Nginx.
They each can have their own php.ini and different extensions loaded.
As you said, you're using Ubuntu Server. If you're using php 5.5, you may note a few things in /etc/php5:
/etc/php5/mods-available # All mods available / installed
/etc/php5/cli/php.ini # php.ini for CLI-called php5
/etc/php5/cli/conf.d # Directory of symlinks to extensions in mods-available!
/etc/php5/apache2/php.ini # php.ini for Apache-run php5
/etc/php5/apache2/conf.d # Symlinks to mods-available extensions
So, php in CLI vs Apache2 vs PHP-FPM can all have different extensions loaded and separated php.ini's installed.
Perhaps the cli-based one (likely what the cronjob is using) may be a different version of PHP (!) or loading a different .ini file and/or set of extensions.
I am using ZeroMQ socket library in my web application. I have configured php.ini so Apache can use ZMQ but I dont know how phpunit can use it.
Dont phpunit use the same php.ini which apache uses?
In phpunit I get following error.
PHP Fatal error: Class 'ZMQContext' not found in /home/idlecool/checker/testcases/checkerTest.php on line 53
Which php.ini file is used for Apache and command-line generally depends on your Linux distribution ; if using Debian or Ubuntu, you'll generally have :
/etc/php5/apache2/php.ini for Apache
and /etc/php5/cli/php.ini for command-line -- and PHPUnit runs as a command-line application.
But note that quite often (it's true on Ubuntu, by default), all .ini files from the /etc/php5/conf.d/ directory will be loaded in both Apache and CLI modes.
Which means that, if you want an extension to be loaded in both modes, you should create a .ini file in that directory, loading and configuring it.
For example, you could have a /etc/php5/conf.d/zmq.ini file, containing something like :
extension=zmq.so
(of course, you'll have to put the name of the right .so file)