When running composer diagnose, I get the following error :
The xdebug extension is loaded, this can slow down Composer a little.
Disabling it when using Composer is recommended.
How can I disable xdebug only when I'm running Composer?
Update: For Xdebug 3+:
As of Xdebug 3, it is possible to disable the Xdebug completely by setting the option xdebug.mode to off, or by setting the environment variable XDEBUG_MODE=off.
It is very easy to disable Xdebug just for composer, by aliasing composer.
alias composer='XDEBUG_MODE=off \composer'
OR
alias composer='php -dxdebug.mode=off $(where composer | fgrep -v composer: | head -1)'
You can add the alias to your $HOME/.bashrc to make it permanent.
Update: For Xdebug 1.3 - 3.0.0 :
The issue has been fixed in Composer 1.3. Update composer to the latest version by executing composer self-update, instead of trying the following workaround.
For Xdebug < 1.3
Here is my modification of #ezzatron's code. I have updated the script to detect ini files from phpinfo output.
#!/bin/sh
php_no_xdebug () {
temporaryPath="$(mktemp -t php.XXXX).ini"
# Using awk to ensure that files ending without newlines do not lead to configuration error
php -i | grep "\.ini" | grep -o -e '\(/[a-z0-9._-]\+\)\+\.ini' | grep -v xdebug | xargs awk 'FNR==1{print ""}1' | grep -v xdebug > "$temporaryPath"
php -n -c "$temporaryPath" "$#"
rm -f "$temporaryPath"
}
php_no_xdebug /usr/local/bin/composer.phar $#
# On MacOS with composer installed using brew, comment previous line
# Install jq by executing `brew install jq` and uncomment following line.
# php_no_xdebug /usr/local/Cellar/composer/`brew info --json=v1 composer | jq -r '.[0].installed[0].version'`/libexec/composer.phar $#
This command will disable the PHP5 Xdebug module for CLI (and thus composer) :
sudo php5dismod -s cli xdebug
It removes the xdebug.ini symlink from /etc/php5/cli/conf.d/
This was suggested on http://blog.lorenzbausch.de/2015/02/10/php-disable-xdebug-for-cli/
Note that for Ubuntu 16.04 you probably need to run it like this:
sudo phpdismod -s cli xdebug
I don’t think there is an option to configure PHP so it can load different configurations according to the targeted script. At least, not without duplicating .ini files...
However, you can add thoses options when running composer with php:
php -n -d extension=needed_ext.so composer.phar
-n will tell PHP to ignore any php.ini. This will prevent xdebug from loading for this very command.
-d options permits you to add any option you want (for exemple, activate needed_ext.so). You can use multiple -d options. Of course, this is optional, you might not need it.
Then you can create an alias, to make it sugary again.
A typical solution (because composer needs json):
php -n -d extension=json.so composer.phar
greg0ire > my solution, based on that:
#!/bin/bash
options=$(ls -1 /usr/lib64/php/modules| \
grep --invert-match xdebug| \
# remove problematic extensions
egrep --invert-match 'mysql|wddx|pgsql'| \
sed --expression 's/\(.*\)/ --define extension=\1/'| \
# join everything together back in one big line
tr --delete '\n'
)
# build the final command line
php --no-php-ini $options ~/bin/composer $*
alias composer=/path/to/bash/script.sh
It looks ugly (I tried and failed to do that with xargs), but works… I had to disable some extensions though, otherwise I get the following warnings:
PHP Warning: PHP Startup: Unable to load dynamic library '/usr/lib64/php/modules/mysqli.so' - /usr/lib64/php/modules/mysqli.so: undefined symbol: mysqlnd_connect in Unknown on line 0
PHP Warning: PHP Startup: Unable to load dynamic library '/usr/lib64/php/modules/pdo_mysql.so' - /usr/lib64/php/modules/pdo_mysql.so: undefined symbol: pdo_parse_params in Unknown on line 0
PHP Warning: PHP Startup: Unable to load dynamic library '/usr/lib64/php/modules/pdo_pgsql.so' - /usr/lib64/php/modules/pdo_pgsql.so: undefined symbol: pdo_parse_params in Unknown on line 0
PHP Warning: PHP Startup: Unable to load dynamic library '/usr/lib64/php/modules/wddx.so' - /usr/lib64/php/modules/wddx.so: undefined symbol: php_XML_SetUserData in Unknown on line 0
You can disable Xdebug setting an environment variable:
XDEBUG_MODE=off composer install
It's available using XDebug 3.
By creating an alias you'll suppress that composer xdebug error message.
Just add this line to your ~/.bash_aliases within your system and it should work flawlessly.
alias composer="php -n /usr/local/bin/composer"
Reload the shell to make the new alias composer available.
source ~/.bash_profile
USAGE:
$ composer --version
NOTE:
You don't necessarily need to use any other parameter.
Depending on your system you might have a .bashrc instead of .bash_profile.
UPDATE:
As #AlexanderKachkaev mention in the comments it's worth nothing to add the memory_limit as follows to avoid crashing im some situations:
alias composer="php -d memory_limit=-1 -n /usr/local/bin/composer"
I came up with an answer that works pretty well for OSX, and could probably be adapted for any PHP version that loads its extensions using individual .ini files in the "additional ini dir":
#!/bin/sh
function php-no-xdebug {
local temporaryPath="$(mktemp -t php-no-debug)"
find /opt/local/etc/$1/php.ini /opt/local/var/db/$1/*.ini ! -name xdebug.ini | xargs cat > "$temporaryPath"
php -n -c "$temporaryPath" "${#:2}"
rm -f "$temporaryPath"
}
alias composer="php-no-xdebug php56 ~/bin/composer"
I usually create a shell script per project, since every project has another PHP version. It's in a /bin/ directory next to composer.phar and composer.json and I run it as ./bin/composer in my project directory.
It looks like this (for php56)
#!/bin/sh
DIR="$( cd "$( dirname "${BASH_SOURCE[0]}" )" && pwd )"
COMPOSER_DISABLE_XDEBUG_WARN=1 /opt/local/bin/php56 \
-d xdebug.remote_enable=0 -d xdebug.profiler_enable=0 \
-d xdebug.default_enable=0 $DIR/../composer.phar "$#"
The -d options effectively disable xdebug. The COMPOSER_DISABLE_XDEBUG_WARN=1 part disables the warning composer issues.
Disabling the xdebug extension is preferred (see composer troubleshooting), but I personally like the simpler script.
Some timings on my machine:
2
Run with xdebug and ini-enabled: 1m33
Run with xdebug but ini-disabled: 0m19
Run without xdebug: 0m10
If you use PHPStorm, the latest release (2016.2) comes with a feature to enable XDebug for CLI scripts on-demand, which means you can simply turn off XDebug globally on your development machine. The IDE will enable it on the fly when it is needed by code inside your projects.
https://blog.jetbrains.com/phpstorm/2016/06/xdebug-on-demand-for-cli-php-scripts-in-phpstorm-2016-2-eap/
PhpStorm 2016.2 introduces Xdebug On Demand mode where you can disable Xdebug for your global PHP install, and PhpStorm will only enable it when it needs to — when you’re debugging your scripts, or when you need code coverage reports.
You need to edit your PHP Interpreters preferences to include the path to XDebug, as described in the linked article.
To me this seems like the perfect solution, as I only usually want XDebug while I'm in the IDE.
However XDebug does have other potential uses when you are "offline" e.g. extended stack dumps in error logs, which you would lose by turning it off globally. Of course you shouldn't have XDebug enabled on production, so this would be limited to use cases like beta-testing or automated-testing CLI scripts in development.
Rather than muddle with temporarily enabling or disabling the PHP module, when you might have concurrent processes using PHP (for example as part of a CI pipeline), you can tell PHP to point at a different module loading directory.
While this is similar to some of the solutions mentioned above, this solves a few edge cases, which is very useful when being used by Jenkins or other CI runner which runs tests on the same machine concurrently.
The easiest way to do this is to use the environment variable PHP_INI_SCAN_DIR
Using this in a script or build task is easy:
export PHP_INI_SCAN_DIR=/etc/php.d.noxdebug
php composer install
Of course you would want to prepare /etc/php.d.noxdebug first, doing something like:
mkdir /etc/php.d.noxdebug
cp /etc/php.d/* /etc/php.d.noxdebug
rm /etc/php.d.noxdebug/xdebug.ini
This means you have an environment similar to the old php environment, with only one module missing. Meaning you don't need to worry about needing to load the phar/json modules as you would with the php -n solution.
Direct manipulation of PHP config
Here's my contribution based on a Homebrew-installed PHP installation on Mac OS X.
It's a shell-script wrapper, designed to be saved as an executable file at /usr/local/bin/composer, with the Composer binary at /usr/local/bin/composer.phar:
#!/bin/sh
sed -i '' -e 's:zend_extension="/usr/local/opt/php55-xdebug/xdebug.so":;zend_extension="/usr/local/opt/php55-xdebug/xdebug.so":' /usr/local/etc/php/5.5/conf.d/ext-xdebug.ini
/usr/local/bin/php /usr/local/bin/composer.phar "$#"
sed -i '' -e 's:;zend_extension="/usr/local/opt/php55-xdebug/xdebug.so":zend_extension="/usr/local/opt/php55-xdebug/xdebug.so":' /usr/local/etc/php/5.5/conf.d/ext-xdebug.ini
Theory of Operation
The wrapper script:
uses sed to temporarily modify the configuration file, disabling Xdebug (line 2)
executes Composer, passing through args to the command (line 3)
uses sed to restore the configuration file, re-enabling Xdebug (line 4)
The script is coupled to an OS X/Homebrew installation of PHP 5.5. The paths should be adjusted to work with other PHP versions and other operating systems' and package managers' directory layouts. Note also that some versions of sed do not need the empty-string argument following the -i option.
Caveat Utilitor
The script is straightforward, in that it works directly on the main PHP configuration files, however this is also a drawback: Xdebug will also be disabled for any scripts that happen to be executed concurrently with this script.
In my development environment, this is an acceptable trade-off, given that Composer is executed manually and only occasionally; however you may not want to use this technique if executing Composer as part of an automated deployment process.
I came up with a solution for the Windows-based Composer installer - it should work for any Composer installation, it just basically makes a copy of the loaded INI file and comments out the xdebug zend extension, then loads that configuration file when it runs composer.
I've opened an issue to see if they'd like to integrate this change:
https://github.com/composer/windows-setup/issues/58
You can find my instructions and code there.
As noted in Joyce's answer, this issue no longer exists in the latest version of Composer.
The Composer documentation has been updated to note this. It details how you can enable xdebug with Composer (if required).
You can update your version of Composer by utilising self-update.
On my Mac I had to do: sudo php /opt/local/bin/composer self-update
Further details about this in the context of a Homebrew PHP install can be found in this issue.
Creating an alias for composer to disable xdebug and prevent memory errors:
Add this line to your ~/.bash_profile
alias composer='php -d xdebug.profiler_enable=0 -d memory_limit=-1 /usr/local/bin/composer'
Restart the terminal to make the new alias available.
In most cases you do not need xdebug on CLI mode. If this is acceptable for you than you can configure cli and cgi differently.
So if you make php-cli.ini and conf-cli.d near exiting php.ini file than you can configure cli and cgi differently (for cgi it would be php.ini and conf.d). Just do not put xdebug.ini into conf-cli.d.
If you install composer using brew on OS X
You can use this alias:
alias composer="php -n $(cat $(which composer) | grep composer.phar | awk '{print $7}')"
My quick solution for a macports installation, with multiple versions of PHP was to write this simple shell wrapper for Composer:
/user/local/bin/composer-nodebug.sh
#!/bin/bash
sudo mv /opt/local/var/db/php53/xdebug.ini /opt/local/var/db/php53/xdebug.NOT
sudo mv /opt/local/var/db/php54/xdebug.ini /opt/local/var/db/php54/xdebug.NOT
sudo mv /opt/local/var/db/php55/xdebug.ini /opt/local/var/db/php55/xdebug.NOT
composer $1 $2 $3 $4 $5 $6 $7
sudo mv /opt/local/var/db/php53/xdebug.NOT /opt/local/var/db/php53/xdebug.ini
sudo mv /opt/local/var/db/php54/xdebug.NOT /opt/local/var/db/php54/xdebug.ini
sudo mv /opt/local/var/db/php55/xdebug.NOT /opt/local/var/db/php55/xdebug.ini
Then run any composer commands like so:
sudo composer-nodebug.sh update
Drawbacks:
requires sudo (unless you chmod the INI files)
if you kill it mid-way the INI files are modified
will require future PHP versions added.
while it's running other PHP processes are affected
Not elegant, but simple.
(Windows)
Based on documentation I use environment variable PHPRC, so I can choose which INI file shloud be loaded, thus I can choose whether I want to enable or disable Xdebug before executing a command (like composer install).
I have two INI files, one with Xdebug enabled (php-xdebug.ini) and one with Xdebug disabled (php.ini - it's also default one).
I use some batches (placed in location which is included in PATH environment variable, so it can be executed from anywhere):
To enable Xdebug I call xon.bat:
#ECHO OFF
set PHPRC=C:/path-to-php/php-xdebug.ini
To disable Xdebug I call xoff.bat:
#ECHO OFF
set PHPRC=
By calling php --ini I can check which INI file was loaded.
Alternatively you can use environment variable PHP_INI_SCAN_DIR in which you set a path to directory from where additional INI files will be loaded. Advantage is that you can load multiple INI files.
Here is my quick solution to get rid off the Xdebug warning on PHP5-cli version. I have removed the support of Xdebug for PHP5-cli on Ubuntu 14.04.
cd /etc/php5/cli/conf.d/
sudo rm 20-xdebug.ini
Now no more Xdebug warning on PHP5-cli.
Related
Problem:
I am trying to use wp cli to do stuff. As an example update wordpress:
wp core update
Fatal error: Uncaught Error: Call to undefined function mysql_connect() in
path\to\wp-includes\wp-db.php:1564
Stack trace:
#0 path\to\wp-includes\wp-db.php(592): wpdb->db_connect()
#1 path\to\wp-includes\load.php(404):
wpdb->__construct(details)
#2 path\to\public\wp-settings.php(106): require_wp_db()
#3 phar://path/to/wp-cli.phar/php/WP_CLI/Runner.php(1182): require('C:\\path\\to\\...')
#4 phar://path/to/wp-cli.phar/php/WP_CLI/Runner.php(1107): WP_CLI\Runner->load_wordpress()
#5 phar://path/to/wp-cli.phar/php/WP_CLI/Bootstrap/LaunchRunner.php(23): WP_CLI\Runner->start()
#6 phar://path/to/wp-cli.phar/php/bootstrap.php(75): WP_CLI\Bootstrap\LaunchRunner->process(Object(WP_CLI\Bootstrap\BootstrapState))
#7 phar://path/to/wp-cli.phar/php/wp-cli.php(23): WP_CLI\bootstrap()
#8 phar://C:/ in path/to\wp-includes\wp-db.php on line 1564
As far as I can see the error is in mysql_connect().
I have read through the following answers:
Undefined function mysql_connect() - This seemed to suggest downloading some packages. I am reticent to do this cos I don't understand what they do (and currently I'm running php using MAMP so I am not sure if this will cause me more problems) but this did suggest to me that the issue was with php.ini which informs an attempted solution below.
Fatal error: Call to undefined function mysql_connect() - I don't think there is an error in my login details (the site itself works) so this doesn't seem to be the problem
Attempted solution - php.ini
When I check which php.ini wp cli is using via the
wp--info
command. It prints the following:
OS: Windows NT 10.0 build 17134 (Windows 10) i586
Shell: C:\Program Files\Git\usr\bin\bash.exe
PHP binary: C:\MAMP\bin\php\php7.2.1\php.exe
PHP version: 7.2.1
php.ini used:
WP-CLI root dir: phar://wp-cli.phar
WP-CLI vendor dir: phar://wp-cli.phar/vendor
WP_CLI phar path: C:\path\to\public
WP-CLI packages dir:
WP-CLI global config:
WP-CLI project config:
WP-CLI version: 1.5.1
So it seems no php.ini has been used here. So I think I need to fix that. In order to do that I've found $WP_CLI_PHP_ARGS which I'm trying to put in. Now I'm no coding superstar, but it seems I need to build a bash script to act as a wrapper because they don't work in the .phar version so I have combined two wrappers I found on the web to create this:
#!/usr/bin/env sh
dir=$(d=${0%[/\\]*}; cd "$d"; pwd)
# See if we are running in Cygwin by checking for cygpath program
if command -v 'cygpath' >/dev/null 2>&1; then
# Cygwin paths start with /cygdrive/ which will break windows PHP,
# so we need to translate the dir path to windows format. However
# we could be using cygwin PHP which does not require this, so we
# test if the path to PHP starts with /cygdrive/ rather than /usr/bin
if [[ $(which php) == /cygdrive/* ]]; then
dir=$(cygpath -m $dir);
fi
fi
dir=$(echo $dir | sed 's/ /\ /g')
"${WP_CLI_PHP}" $WP_CLI_PHP_ARGS "${dir}/wp-cli.phar" "$#"
When I run this it variously complains. I imagine I have made some kind of basic error. (I've also put "export WP_CLI_PHP_ARGS=/C/MAMP/bin/php/php7.2.1/php.ini-production" in my .bash_profile).
mysql_connect() is deprecated, as of PHP 5.5, and removed in PHP 7. PHP 5.5 is not a supported version of PHP, so the author should update their code.
Use mysqli_connect() instead.
Right, okay.
So the issue was flagged by wp-db and it looked as if mysql wasn't working but it was mysqli. Eventually I got the php.ini file working but I thought I'd post all the various solutions that might help others. Number 4 is what worked for me.
1) Turn off mysql_connect so as to force wordpress to use mysqli_connect. Go to wp-config.php and add the line
define('WP_USE_EXT_MYSQL', false);
2) Check your php.ini file is "--with-mysqli=shared" present in the configure command box?
3) Update your mysqli. I didn't do this one, but following this, the advice seems to be to run this in your shell.
sudo apt-get install mysql-server mysql-common php7.0 php7.0-mysql
I'm running git-bash in on windows so that threw up a whole load of nonsense for me. If you're on linux this could work.
4)As above I notice php.ini wasn't give in the wp --info. I found the right file using (just create a file with that, and visit it from your server). This turned out to be in a different place than I was expecting. Then I fiddled with the bash wrapper above and eventually got this, which made the error disappear:
#!/usr/bin/env sh
dir=$(d=${0%[/\\]*}; cd "$d"; pwd)
# See if we are running in Cygwin by checking for cygpath program
if command -v 'cygpath' >/dev/null 2>&1; then
# Cygwin paths start with /cygdrive/ which will break windows PHP,
# so we need to translate the dir path to windows format. However
# we could be using cygwin PHP which does not require this, so we
# test if the path to PHP starts with /cygdrive/ rather than /usr/bin
if [[ $(which php) == /cygdrive/* ]]; then
dir=$(cygpath -m $dir);
fi
fi
dir=$(echo $dir | sed 's/ /\ /g')
php -c $WP_CLI_PHP_ARGS "${dir}/wp-cli.phar" "$#"
If I've done something stupid let me know, thanks for your time. Feel free to ask for clarifications.
Looks like your wordpress installation is trying to use mysql_connect in wp-db.php. Wordpress defaults to using mysql_connect if it cannot find mysqli installed OR is overridden.
mysqli comes installed with php 7 (and you're using php 7).
So, check wp-config.php and confirm that WP_USE_EXT_MYSQL is defined to false
I'm using Windows 10, PHP 8.0.7.
Installed wp-cli via phar file.
And got this error on every command:
Call to undefined function mysql_connect()...
So I've uncommented this string in my php.ini file:
extension=mysqli
And all worked fine for me. Hope it will be helpful for someone.
I've been unable to add the MailParse PHP extension (https://pecl.php.net/package/mailparse) to an instance of Elastic Beanstalk running PHP 7. My goal is to get it added into the boot sequence so that it's always installed when an instance is created.
My problem is that Amazon's version of Linux for EB doesn't offer PECL, so I am unsure how to get it loaded.
I've tried to adapt various approaches for installing other php extenions/modules, but haven't had any success.
https://packagist.org/packages/php-mime-mail-parser/php-mime-mail-parser - I tried including this via my composer.json file, but it failed because "ext-mailparse" wasn't installed.
http://wiki.cerbweb.com/Installing_PHP_Mailparse_Ubuntu - I tried running these commands to install the extension, but the first command to install the dependencies failed.
https://serverpilot.io/community/articles/how-to-install-the-php-mailparse-extension.html - "sudo: apt-get: command not found"
I have a feeling there is an easier way to get this done but I'm stuck. Can anyone help?
Create two files:
.ebextensions/01mailparse.config
commands:
01install_mailparse:
command: "pecl7 install --force mailparse"
Note the use of the --force flag. I added this since sometimes AWS EB automatically re-deploys the app in a way that PECL fails if it find the extension being already installed.
.ebextensions/02prioritize.config
commands:
01change_mailparse_load_priority:
command: "sed '/extension=\"mailparse.so\"/d' /etc/php.ini > /etc/php.ini && echo 'extension=\"mailparse.so\"' > /etc/php-7.0.d/zz_mailparse.ini"
This removes the mailparse extension registration from the php.ini file (PECL was adding the line at the top, weird) and registers it to be loaded at the end of the list (zz prefix).
Note that I used two files. For some reason, using two commands on the same file was making the deploy file. I'd appreciate if someone could clarify this.
To add to #Mauro's answer the following allows you to install mailparse and remove the extension from /etc/php.ini in a single file.
.ebextensions/01_mailparse.config (PHP 7.x)
commands:
01_mailparse_install:
command: |
pecl7 install --force mailparse
sed -i '/extension="mailparse.so"/d' /etc/php.ini
files:
"/etc/php.d/mailparse.ini":
mode: "000644"
owner: root
group: root
content: |
extension="mailparse.so"
.ebextensions/01_mailparse.config (PHP 5.6)
commands:
01_mailparse_install:
command: |
pecl install --force mailparse-2.1.6
sed -i '/extension="mailparse.so"/d' /etc/php.ini
files:
"/etc/php.d/mailparse.ini":
mode: "000644"
owner: root
group: root
content: |
extension="mailparse.so"
The | allows multi line values. I modified the sed command and added the files block to allow it to work on multiple PHP versions without much change.
I can't run composer install because my php's version on my OS is not enough updated (5.5.36). So i tried to install composer globally with my MAMP's php(5.6.10)
1) I create alias for my MAMP's php
nano ~/.bash_profile
alias phpmamp='/Applications/MAMP/bin/php/php5.6.10/bin/php'
2) Run this line to install composer
curl -sS https://getcomposer.org/installer | phpmamp
3) Run this line to move composer
sudo mv composer.phar /usr/local/bin/composer
Composer is installed (run composer on terminal works)
This is a the tutorial.
But when i want to run composer install, composer uses my OS php.
Any idea ?
Those lines worked for me. I override the OS PHP path to my MAMP PHP path.
PHP_VERSION=`ls /Applications/MAMP/bin/php/ | sort -n | tail -1`
$ export PATH=/Applications/MAMP/bin/php/${PHP_VERSION}/bin:$PATH
$ source ~/.bash_profile
You can check the version by running :
$ which php
The complete solution
Thanks to #Andrew Patton
This is an old question, but it came up in web search for a similar issue I was having, and the latest version of MAMP Pro (mine is 6.6.2) has a GUI solution:
In Languages > PHP, under 'Default version', you should see a checkbox for "Also activate shortcut for Composer".
What this did for me is add an alias of composer=/Applications/MAMP/bin/php/composer (in my zshell ~/.profile file on macOS Monterey). Maybe yours works similarly.
Of course, when switching PHP versions, it wouldn't also switch composer versions (which is necessary when switching between PHP 5 and 7.2.5+), so I have to use the OS install for one version and MAMP's for another. A little tricky, but if you don't have this problem, then the alias will be fine.
I'm using PHPStorm on Windows 10, WAMP server for php.exe and I've installed composer using ComposerSetup.exe for windows. I'm trying to add command line tool support for the composer in Phpstorm, but it fails and gives this error.
Problem
Failed to parse output as XML: Error on line 2: Content is not allowed in prolog.
Command
php.exe C:\ProgramData\ComposerSetup\bin\composer list --xml
Output
dir=$(d=$(dirname "$0"); cd "$d" && pwd)
# see if we are running in cygwin by checking for cygpath program
if command -v 'cygpath' >/dev/null 2>&1; then
# cygwin paths start with /cygdrive/ which will break windows PHP,
# so we need to translate the dir path to windows format. However
# we could be using cygwin PHP which does not require this, so we
# test if the path to PHP starts with /cygdrive/ rather than /usr/bin.
if [[ $(which php) == /cygdrive/* ]]; then
dir=$(cygpath -m $dir);
fi
fi
dir=$(echo $dir | sed 's/ /\ /g')
php "${dir}/composer.phar" $*
PHPStorm should know about the locally installed PHP, and all it needs is the composer.phar file that contains the PHP source code of Composer.
What you have given PHPStorm looks like a Windows batch file that detects some aspects of being called in Windows shells (like CMD vs. Cygwin), and THEN calls PHP with the path of composer.phar. This is no PHP source code that you could directly give to PHP, like PHPStorm does.
Only configure the path of the phar file in PHPStorm, not that batch file.
Alternatively, you can simply add Composer via the PHPStorm GUI - it should ask you to provide Composer if it isn't known, and a download possibility should be offered.
There is an extensive help text available at their website just by googling "phpstorm install composer": https://www.jetbrains.com/phpstorm/help/using-composer-dependency-manager.html
I am trying to run the 'phpize' command on MacOSx Mountain Lion, but this is what I get:
Cannot find config.m4.
Make sure that you run '/opt/local/bin/phpize' in the top level source directory of the module
How do I resolve this error ?
The phpize command is meant to be run at the top level of an extension source dir (this source dir should contain a file name config.m4).
See http://php.net/manual/en/install.pecl.phpize.php for more information.
In plain English, it means you're running the command from the wrong directory. You need to be in the directory that contains the source for the extension you're trying to install.
For example, if you're trying to install mcrypt, like I was when I came across this stack overflow page, you need to be in php-5.6.24/ext/mcrypt and then run the command.
My problem was that I was trying to execute the command just to see if I had it installed.
Trying to execute the command alone gives you that error, only use it inside the directory (most likely you downloaded) that contains the extension that you're trying to install.
Here some instructions to install Xdebug for php7.2 for example.
Take special care in step 3 and 4, first you change dir to the unpacked downloaded extension and then you run phpize.
http://qiita.com/MasatoYoshioka#github/items/e542f39a6f1a3bc1f71e
In terminal
ls config.m4
ls config*
config.w32 config0.m4
cp config0.m4 config.m4
cd /usr/local/src/php-5.3.29/ext/zlib
phpize
./configure
make clean && make && make install
nano php.ini
add extension=zlib.so
got inside the xdebug folder than try to run the phpize
Sometimes, using the pecl installer is not an option. This could be because you're behind a firewall, or it could be because the extension you want to install is not available as a PECL compatible package, such as unreleased extensions from git. If you need to build such an extension, you can use the lower-level build tools to perform the build manually.
The phpize command is used to prepare the build environment for a PHP extension. In the following sample, the sources for an extension are in a directory named extname:
$ cd extname
$ phpize
$ ./configure
$ make
# make install
first run ./configure it will create config.m4 file, rest the steps are same