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.
Related
I'm trying to install my composer packages, but it gives me this:
This package requires php >=7.0.0 but your PHP version (5.5.9)
But php -v gives me this: PHP 7.0.22-0ubuntu0.16.04.1 (cli) ( NTS )
I am running an Ubuntu 16.04.3 LTS machine, I found some soultions for Mac and Windows, but nobody seems to have the issue on Linux?
try this:
composer install --ignore-platform-reqs
or this in composer.json
"config": {
"preferred-install": "dist",
"platform": {
"php": "7.0.0"
}
}
in the second solution basically you're faking a platform, and run composer.phar update after this
If you're using Debian based systems, you can ask it to globally use a specific version with the following command (depending on how and where your php versions are installed to):
sudo update-alternatives --set php /usr/bin/php7.2
update-alternatives creates, removes, maintains and displays
informations about the symbolic links comprising the Debian
alternatives system.
Try this it worked for me :
alias php='/usr/local/php7/bin/php'
php composer.phar install
composerreferences the PHP executable here as follow:
#!/usr/bin/env php
When I do which php I get /c/Program Files/php-7.1/php under GIT-Bash (Windows 10).
Under Linux (at home I have Debian), php may be a symbolic link to an actual PHP binary.
So do the following:
Double-check the said php with ls -l `which php`
Make sure that you only have one PHP version installed, this may cause mixing incompatible versions which may be the root cause of your problem
That should help you, finding the root cause.
Just sharing here because I had this same issue and found this thread first while searching.
For me I had a Windows server with PHP 5.6.? on it as well as PHP 7.2.? on it. I had configured IIS to use 7.2 but 5.6 was still in the environment variables under path. Open System Properties>Advanced tab> "Environment Variables...". Edit "path", and remove the reference to "C:/program files (x86)/PHP/v5.6" from path and save.
Restart your terminal and you should be set. Hope that helps someone.
I recently came across the same problem. php --version returned 7.4.30, but Composer said it was using PHP 8.0.18.
It turns out Composer is using its own PHP version. The composer script contains a hardcoded path to PHP 8. (To me, this is a composer bug, as Composer should respect the value of the config.platform.php property of the composer.json file.)
An option may be to alias composer:
alias composer='/usr/local/bin/php /usr/bin/composer.phar
Another option may be to rewrite composer:
cat /usr/bin/composer \
| sed 's~/usr/bin/php8~/usr/local/bin/php~g' \
> /usr/bin/composer.tmp
mv /usr/bin/composer.tmp /usr/bin/composer
This is how I found out. First, I wanted to find the location of composer. By using whereis composer, one can find the path of the composer command. For me, it returned
composer: /usr/bin/composer
I then wanted to see the contents of /usr/bin/composer, so I could find out what the composer command was doing under the hood. By using cat /usr/bin/composer, the contents of the composer script are printed. For me, it returned
#!/bin/sh
/usr/bin/php8 /usr/bin/composer.phar "$#"
There it is. The composer command uses hardcoded /usr/bin/php8 to execute the composer.phar file.
Well, this worked for me
$ alias composer="php /usr/bin/composer.phar"
$ composer install
Use the exact php binary in the alias, for example
$ alias composer="php8.1 /usr/bin/composer.phar"
None of above didnt worked for centos 7.
After this command composer php version fixed
The correct answer below
SSH Command:
scl enable ea-php74 'composer diagnose'
Does anyone know how to install and enable PHP IMAP Extension on AWS Elastic Beanstalk using configuration files (.ebextensions)?
I'm using 64bit Amazon Linux 2017.03 v2.4.0 running PHP 7.0.16
I've tried several ways as follow:
1st Way
I've tried using files in configuration file but it doesn't work, the configuration filename is phpini.config in .ebextensions directory with below setup:
files:
"/etc/php.d/phpimap.ini":
mode: "000755"
owner: root
group: root
content: |
extension=imap.so
The additional .ini files parsed into phpinfo() by displaying /etc/php-7.0.d/phpimap.ini but the IMAP won't installed.
2nd Way
Using container_command to install php-imap but i'm getting error.
container_commands:
install_php_imap:
command: yum install php55-imap
Error as image below:
3rd Way
Using combined commands & files, it is only success installing IMAP and the dependencies (php common) but it doesn't activate the IMAP
a. Create installdependencies.config in my .ebextensions by adding bellow script:
commands:
install_phpcommon:
test: '[ ! -f /etc/php.d/curl.ini ] && echo "php common not installed"'
command:
yum -y install https://archipelagointernational.s3.amazonaws.com/libs/php70w-common-7.0.16-1.w6.x86_64.rpm
b. Create phpini.config in my .ebextensions by adding bellow script:
commands:
install_phpimap:
test: '[ ! -f /etc/php.d/imap.ini ] && echo "php imap not installed"'
command:
yum -y install https://archipelagointernational.s3.amazonaws.com/libs/php70w-imap-7.0.16-1.w6.x86_64.rpm
files:
"/etc/php.d/imap.ini":
mode: "000755"
owner: root
group: root
content: |
extension=imap.so
4th Way I'm testing by adding upload_max_filesize, post_max_size and extension=imap.so to zzzphp.ini and only two values are included that are upload_max_filesize and post_max_size. The extension=imap.so not included into zzzphp.ini file.
Below are the script phpini.config in .ebextensions:
commands:
install_phpimap:
test: '[ ! -f /etc/php.d/imap.ini ] && echo "php imap not installed"'
command:
yum -y install https://archipelagointernational.s3.amazonaws.com/libs/php70w-imap-7.0.16-1.w6.x86_64.rpm
files:
"/etc/php.d/zzzphp.ini":
mode: "644"
content: |
upload_max_filesize = 50M
post_max_size = 58M
extension=imap.so
Any suggestions?
Thanks in advance.
Finally it's work
Create two files inside .ebextensions as follow:
installdependencies.config, install php common if it is required
commands:
01_install_phpcommon:
command:
sudo yum -y install php70-common
phpini.config, install php imap and enable imap
commands:
02_install_phpimap:
command:
sudo yum -y install php70-imap
files:
"/etc/php.d/zzzphp.ini":
mode: "644"
content: |
extension=imap.so
For me, below code in phpini.config solved the issue. Please notice the folder names as per php version. My php version is 7.2 hence below code works:
commands:
install_phpimap:
test: '[ ! -f /etc/php-7.2.d/imap.ini ] && echo "php imap not installed"'
command:
sudo yum -y install php72-imap
files:
"/etc/php-7.2.d/imap.ini":
mode: "000755"
owner: root
group: root
content: |
extension=imap.so
You’re including the php-imap extension in php’s configuration file, but that’s not sufficient to install it.
You’re going to have to pass something to your EBS provisioning method of choice telling it to install php-imap (or whatever it’s called in that environment) at the system level.
I followed all of the suggestions here but my commands kept on failing because my composer required imap support and the container commands are run after...
Here's what worked for me:
packages:
yum:
php72-imap.x86_64: []
This works for me, using ebextensions too (I'm running a container with PHP 7.2, it should work for your environment, replace accordly):
packages:
yum:
php72-imap: []
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.
After some days ago I installed Phalcon PHP, I am more and more exited about it. Now I want to try the Phalcon Devtools out. I've just installed it like in the installation manual via Composer (for Linux) shown. But when I try to execute the phalcon command, I get an error:
$ phalcon commands
ERROR: Phalcon extension isn't installed, follow these instructions to install it: http://docs.phalconphp.com/en/latest/reference/install.html
What can be the problem?
(Environment: Debian GNU/Linux 7.4 (wheezy), PHP 5.5.11-1).
Additional information:
I installed Phalcon PHP like in the docu shown:
$ apt-get install php5-dev libpcre3-dev gcc make php5-mysql
$ git clone --depth=1 git://github.com/phalcon/cphalcon.git
$ cd cphalcon/build
$ ./install
Since it seemed to not work, I tried it with
$ cd cphalon/build/64bits
$ export CFLAGS="-O2 --fvisibility=hidden"
$ ./configure --enable-phalcon
$ make && make install
After that the module was compiled and the phalcon.so created in the PHP modules direcroty /usr/lib/php5/20121212. Then I created the INI file /etc/php5/mods-available/phalcon.ini (with content extension=phalcon.so) manually and enabled it with a symlink: ln -s /etc/php5/mods-available/phalcon.ini /etc/php5/fpm/conf.d/20-phalcon.ini. And after a restart it worked. I created a "Hello World!" application and the module was also displayed in the phpinfo() output:
But the output of php --modules does not contain "phalcon". And the output of get_loaded_extensions() does not contain it as well. Why?
The answer to both questions (1. Why do I get an error? and 2. Why php --modules doesn't show the module, though phpinfo() (in browser) does?) is the same: I enabled the module for FPM, but didn't do this for the CLI.
$ ln -s /etc/php5/mods-available/phalcon.ini /etc/php5/cli/conf.d/20-phalcon.ini
Now it works!
I had the same problem on Windows 10 with WAMP installed.
I shows on the phpinfo() but on the command prompt is gives the error.
When you enter c:\>php -m to show the available php modules its not there...
First look where your php.ini file is with the command:
c:\>php --ini
In my case: C:\wamp\bin\php\php5.6.19\php.ini
After editing this file and adding extension=php_phalcon.dll it works and when you enter then the phalcon command it gives you the available version and commands.
C:\>phalcon
C:\>phalcon-tools
Phalcon DevTools (3.0.1)
Available commands:
commands (alias of: list, enumerate)
controller (alias of: create-controller)
module (alias of: create-module)
model (alias of: create-model)
all-models (alias of: create-all-models)
project (alias of: create-project)
scaffold (alias of: create-scaffold)
migration (alias of: create-migration)
webtools (alias of: create-webtools)
How it helps someone.
I cannot comment, but let me tell you here, #Jubayer Arefin.
You need to put your phalcon-devtools path inside %PATH% variable. It's explained in phalcon-devtools docs in install section on their site.
$ phalcon commands
ERROR: Phalcon extension isn't installed, follow these instructions to install it: http://docs.phalconphp.com/en/latest/reference/install.html
I fixed the same problem in Windows:
The problem was in my System Path variable: another old PHP path in it, and the CMD was taking the first (the old one without phalcon extension) by default.
Delete this old path, put the correct one -- and it will work!
I am trying to configure my AWS Elastic Beanstalk to work with mongo, all I need to do is install the mongo driver for PHP and update the php.ini file
To do this, usually I would ssh into the EC2 and run:
sudo pecl install mongo
But this would require using a custom AMI which isnt the best way to go.
It is better to use config files to install the software required onto the standard AMI.
So to do this, I have done the following:
created directory .ebextensions
created file mongo.config
in it I have put the following:
packages:
pecl: install mongo
However upon deployment, I get the following error:
"option_settings" in one of the configuration files failed validation. More details to follow.
and
'null' values are not allowed in templates
So I am wondering how this config file needs to be laid out in order to install the mongo extension?
I have read the info here: http://docs.aws.amazon.com/elasticbeanstalk/latest/dg/customize-containers-ec2.html
but I am not quite understanding how to do this specific task
Help would be appreciated , thanks! :)
pecl is not a valid package manager on Amazon Linux and therefore cannot be used under the packages key of an .ebextensions config.
To install a PECL package it is enough to add a single command under the commands key. To avoid that Beanstalk tries to install the extension twice on follow-up deployments add a PHP console command to the test key that checks if the extension is already installed:
commands:
install_mongo_driver:
command: pecl install mongo
test: "php -r \"exit(extension_loaded('mongo') ? 1 : 0);\""
If the test result is true, i.e. exit(0), then the command gets executed - otherwise not. Please note that a exit code of 0 means "No errors" in a shell context.
See also the description at http://docs.aws.amazon.com/elasticbeanstalk/latest/dg/customize-containers-ec2.html#customize-containers-format-commands.
I have figured it out and thought I would share what I found. Thanks to Hudku (http://blog.hudku.com/2013/02/innocuous-looking-evil-devil.html#elastic-beanstalk.config) for the excellent article:
1) Create myapp.config
2) enter the following into it
packages:
yum:
dos2unix: []
container_commands:
01-command:
command: rm -rf /myapp/ebextensions
02-command:
command: mkdir -p /myapp/ebextensions
03-command:
command: cp -R .ebextensions/* /myapp/ebextensions/
04-command:
command: dos2unix -k /myapp/ebextensions/mongo.sh
05-command:
command: chmod 700 /myapp/ebextensions/mongo.sh
06-command:
command: bash /myapp/ebextensions/mongo.sh
Then create mongo.sh file and put in it something like:
#!/bin/bash
if [ ! -f /mongostatus.txt ];
then
pecl install mongo
echo "mongo extension installed" > /mongostatus.txt
apachectl restart
fi
This will install mongo php extension and restart apache so the install takes affect.
I just accomplished the same thing thanks to the answer above, and figured out it can be done with less lines and less files for those interested...
# ~/project/.ebextensions/project.config
# Logger messages can be viewed in /var/log/messages
files:
"/tmp/test.sh":
content: |
# This file will be created and can then
# be executed by a command call below.
logger TEST FILE CALLED
commands:
01-command:
command: logger CALLING TEST FILE; sh /tmp/test.sh;