Like so many others, I'm trying and failing at running composer on windows (to install my symfony2 dependencies).
Running with a memory-limit-flag like this doesn't have any effect.
php -d memory_limit=1024M /usr/local/bin/composer.phar
Nor does changing the php.ini file.
It appears though that the php.ini settings are cached in the cygwin program, because I can even change the name of my php.ini in the cygwin etc folder, and I still get the same results.
Is there a way to clear the cygwin cache, or restart it, or read the settings from php.ini into the program anew?
Related
So I ran into something I'm just hoping I can get some understanding on. There is a clean Centos machine with a clean install of PHP. It had the mongoDB driver installed as well. When accessing the web app through the browser, it kept complaining the mongo client didn't exist. All of the installation procedures were followed, php.ini contained extension=mongo.so, and httpd restarted. PHP info() did not contain the Mongo conf. What ended up working was adding a mongo.ini file to the /etc/php.d directory with the extension=mongo.so written to it.
I'm getting a sneaky suspicion php.ini wasn't being loaded correctly, but I don't understand why. The reason I'm thinking this is, for one, it worked after adding mongo.ini. Second, there are mismatched PHP info() outputs from the CLI and browser gui.
and from the GUI
Both of these were snapped seconds apart. No configuration changes or restarts were made. For some reason the CLI output says the loaded configuration file was /etc/php.ini which was expected. The browser GUI however shows (none). What is going on here? Is this why the extension=mongo.so was never loading from the php.ini file?
versions
Apache/2.4.6
PHP/5.4.16
CentOS Linux release 7.3.1611
[someUser#someServer etc]# find / -name php.ini
/etc/php.ini
Is SO even the proper place for this? or should I move to a different forum?
update
After reading Grigory Ilizirov's comments, and doing some research, I think the question is answered if he wants to post it. Looks like the php configs for apache wasn't being loaded. I had just assumed the /etc/php.ini file was all that was needed to be edited. Now I just need to figure out how the heck I'm going to do that.
update 2
Reverted back to a clean install and did everything again. This time around, same results from the CLI and web GUI as before, but now mongo wouldn't load at all despite being added in /etc/php.d/mongo.ini. suspect SELinux is interferring with apache. mongo.ini is no longer showing in the additional .ini file sections. Disabling SELinux and rebooting allows it to load to apache.
FINAL
This is indeed an SELinux issue. Now then, does this belong on SO for future users?
You need to make sure your PHP have installed MongoDB extension.try use PHP -m see if you have MongoDB installed.
Then Download source code from https://github.com/mongodb/mongo-php-driver-legacy.
follow these steps to install the extension:
tar zxvf mongo-x.x.x.tgz -C ../
cd mongo-x.x.x/
phpize
./configure --with-php-config=/usr/local/php/bin/php-config
make clean
make
make install
extension=mongo.so //add this line to php.ini
after install try run PHP -m again, see if extension installed success.
for more info, you should read PHP doc.http://php.net/manual/en/mongo.installation.php#mongo.installation.fedora
It was indeed SELinux interfering with Apache's access to the PHP configuration file. Adding the security context fixed it.
semanage fcontext -at httpd_sys_content_t '/etc/php.ini'
semanage fcontext -at httpd_sys_content_t '/etc/php.d/(/.*)?'
restorecon -Rv /etc/
systemctl restart httpd
Ubuntu 16.04.2
LSPHP7.0
wget -O - http://rpms.litespeedtech.com/debian/enable_lst_debain_repo.sh | bash
apt install -y lsphp70
Then I added /usr/local/lsws/lsphp70/bin to $PATH and made a symlink for /usr/local/lsws/lsphp70/bin/php7.0 to /usr/local/lsws/lsphp70/bin/php. This way I can run php in terminal as cli version.
apt install composer
composer require geoip2/geoip2:~2.0
I got an error said the requested PHP extension curl is missing from your system.
And also it said
To enable extensions, verify that they are enabled in those .ini files:
- /etc/php/7.0/cli/php.ini
You can also run `php --ini` inside terminal to see which files are used by PHP in CLI mode.
But when I run php -i | grep php.ini it shows the ini is not /etc/php/7.0/cli/php.ini but /usr/local/lsws/lsphp70/etc/php/7.0/litespeed/php.ini
Further more, I run php --ini, it shows:
Configuration File (php.ini) Path: /usr/local/lsws/lsphp70//etc/php/7.0/litespeed/
Loaded Configuration File: /usr/local/lsws/lsphp70/etc/php/7.0/litespeed/php.ini
Scan for additional .ini files in: /usr/local/lsws/lsphp70//etc/php/7.0/mods-available/
Additional .ini files parsed: /usr/local/lsws/lsphp70//etc/php/7.0/mods-available/curl.ini,
/usr/local/lsws/lsphp70//etc/php/7.0/mods-available/imap.ini,
/usr/local/lsws/lsphp70//etc/php/7.0/mods-available/json.ini,
/usr/local/lsws/lsphp70//etc/php/7.0/mods-available/mysqli.ini,
/usr/local/lsws/lsphp70//etc/php/7.0/mods-available/opcache.ini,
/usr/local/lsws/lsphp70//etc/php/7.0/mods-available/pdo_mysql.ini
How can php cli get /etc/php/7.0/cli/php.ini as its php config file? Anyone gives a clue? thanks.
Ubuntu normally installs system default php(currently php7.0) to /usr/bin/php
Composer will normally call the PHP defined in $PATH, usually /usr/bin/php.
The Error "the requested PHP extension curl is missing from your system" means Ubuntu system default php7.0 curl is missing. To resolve:
apt-get install php7.0-curl
So far, it should resolve your problem already.
LiteSpeed Web Server normally use LiteSpeed API to communicate with PHP engine, which is faster than other APIs. In LiteSpeed Ubuntu/Debian repo, it provides different versions of lsphp, which will be at different location other than system default location, normally at /usr/local/lsws/lsphpxx/bin/.
Composer will normally use system default php location as explain above. If you want to overwrite PHP path to use lsphp70 php binary, you will need to add this path to the beginning of $PATH.
export PATH="/usr/local/lsws/lsphp70/bin/:$PATH"
This way, when you run:
which php
System should use the php found first in the PATH, which is /usr/local/lsws/lsphp70/bin/php
In this case, when you see similar php-curl missing error message, you should run:
apt-get install lsphp70-curl
to fix the problem.
To make the new PATH permanently, you can edit ~/.profile or .bashrc, or any other similar way, which is beyond the discussion of this topic.
I have mamp installed and am using windows 10. I have attached an image of the configurations, the error, and some of the things I've done to diagnose why. I don't know why I am continuously getting this composer error. I am updating my php.ini file, which had openssl commented out. I removed the semicolon on extension_dir (was already removed), and on extension=php_openssl.dll. I have noticed that when I type in php -m in my command prompt, I am not seeing open ssl, and I'm not sure how to enable that, if that is the possible issue.
If there can be any light shed on this, let me know, I understand this issue is answered hundreds of times over, but I have done what was required from those answers, and got no where.
Image clarifications: The error
Here is where I am checking the configurations with php -m and it's not showing openssl, correct me if I'm mistaken.
My phpinfo(); with also me doing php -ini, it's showing php isn't set, but it is when I run the phpinfo method, i'm assuming because this method is being run through mamp allowing it to set the correct parameters.
You have to make sure that the command-line PHP loads an ini file somehow. The easiest is probably to copy c:\MAMP\conf\php7.0.0\php.ini to wherever your php.exe is located. To find that out you can use where php which should return you the full path to it. Copy the ini file in that directory and it should find it and load the module (although you might have to adjust the extension_dir depending on how it is set).
See http://php.net/manual/en/configuration.file.php if you want more details on how the ini file is located.
you only need to copy php.ini from the conf directory to your php directory and it will work fine.
just copy php.ini from
MAMP/conf/php(version of your php)/php.ini
to
MAMP/bin/php/php(version of your php)
then try in command line `php composer.phar install'
for install composer and enable openssl extension, copy your php.conf in MAMP\conf\php{php-version} for MAMP\bin\php\php{php-version} and edit php.conf changing ;extension=php_openssl.dll for extension=php_openssl.dll.
Then try installing normally.
Running Windows 10 with MAMP PRO. Copy the version php.ini file to the folder that has the php.exe. In my case, I copied MAMP/conf/php7.2.1/php.ini file to MAMP/bin/php7.2.1/ folder.
Restarted MAMP PRO 4.
Ran the command line, replacing some-dir with my new Drupal 8 project.
composer create-project drupal-composer/drupal-project:8.x-dev some-dir --stability dev --no-interaction
Worked beautifully!
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'm trying to install zend debugger in my Ubuntu 9.04 machine, I've done it in win. but not in linux, I hope you could help me, this is what I've done:
1)Copied the file ZendDebugger.so to /etc/php5/apache2 (didn't choose this folder for anything in special).
2)Added this lines to php.ini:
zend_extension="/etc/php5/apache2/ZendDebugger.so" zend_debugger.allow_hosts=127.0.0.1,127.0.1.1,localhost,*
zend_debugger.expose_remotely=always
I've also tried without quotes(zend_extension=/etc/php5/apache2/ZendDebugger.so)
3)Copied file dummy.php to /var/www
And then restarted Apache but I didn't see the information about Zend Debugger in the phpinfo(), the only related thing I found there was report_zend_debug On.
Thanks in advance
I found much more easy to install Xdebug in my Ubuntu machine.
sudo mv /etc/php5/apache2/ZendDebugger.so /usr/lib/php5/20060613/ZendDebugger.so
This is where your memcache.so, apc.so, etc. are located. Unless you modified your php extensions directory that is where new exts should go.
In php.ini:
zend_extension=/usr/lib/php5/20060613/ZendDebugger.so
cd to that directory and chmod a-x ZendDebugger.so to remove executable bits from the .so.
sudo /etc/init.d/apache2 stop
In another terminal window, tail -f /var/log/error.log and clear console so it is easy to see new log entries coming in (cmd-k on macos).
Then:
sudo /etc/init.d/apache2 start
If there are no errors in error.log, check phpinfo() and see if the debugger section shows up.
You might get errors in the configuration of other php extensions that occur further up in php.ini (e.g., xcache or eaccellerator) that will make loading stuff further down in php.ini problematic.
This is a baseline setup and should work if there are no other problems.
You can also try to install Zend Server Community Edition
You'll get Zend Debugger enabled by default, along with some other nice features. There is a link to the deb repository available through the download page.
I followed the same steps that you did with the same result. In the end the problem was that I was trying to load a 32bit binary with apache running in 64bit mode base (as described in this post) I was able to get it running immediately by doing the following.
stopping apache
executing sudo arch -i386 /usr/sbin/httpd
restarting apache.
After replacing the 32bit binary with the 64bit binary everything worked as expected with no special apache handling. There was also some facepalming involved, but it did not affect the overall outcome.