These are also other stuffs going on:
composer update or composer install takes forever and the command line responds as killed
Specially this might happen on ordinary symfony application.
This is mostly, very very likely, related to memory issue.
Solution 1: perform your composer update or install on the host machine if possible.
This might not be possible in some scenarios if there are dependencies that rely on installed packages.
But, if that is not the problem, have on the host and the files would be sync’d anyway.
Solution 2: increase the memory on the provision file you have. I am using puphpet so, for that all you would have to do would be
then search for memory which by default be 512 and increase it at least to 1024 or better 2048 and that should solve the problem
To see the how much memory you have on your vagrant machine, ssh into your machine and
the free command would tell you how much memory you have and how is used.
Unless you have been living under rocks, you have heard about composer already. It is a dependency manager and more than that actually. If your PHP app is using a lot of dependencies, then it is time to consult composer.
Here I will put some notes on how to install it and make it available globally so that you can use it from any directory.
First thing first, go and grab the phar file from composer download page
It would be a single phar file and u can use that as it is:
Of course you would need the composer.json file for the above to work where you would list the dependencies.
But, this would require you to call the phar from where you downloaded and that might not be handy
sudo mv composer.phar /usr/local/bin/composer
Now, you can call composer from any directory and rock from there
get more @ get composer
That is how you install composer on linux/mac computer and make it globally accessible with in
trying to install composer on your server and got something like
Some settings on your machine make Composer unable to work properly.
Make sure that you fix the issues listed below and run this script again:
And specifically for suhosin.executor.include.whitelist = phar?
Then the fix is to modify php.ini on the fly while you are passing the installer
sudo curl -sS https://getcomposer.org/installer | php -d suhosin.executor.include.whitelist=phar
That should take care of modifying the php.ini on the fly without you updating the config and re-bouncing the server.
I got the MongoId not found error on the the application I recently moved to remote server.
The app is working fine locally and the problem appears to happen on the remote one only.
The problem seems obvious, and I checked the mongo version I have locally vs the version I have on the remote – they are different
I have newer version of mongo installed on the remote server. And the doctrine orm handling my mongo objects was also older.
I updated my doctrie orm on composer as
This took care of the problem – at least for now 😉
The major issue you would face is memory. Yeah, the instance comes with small memory allocation and anything memory intensive task might not work there. Your composer install command might not do anything as well.
The major one would be Composer install just hangs and even aborts the process
When you are issuing
It will eat a bit of memory and doing it on the instance might not work as expected.
Here are the methods I used to overcome it.
1. Incremental install
On you composer.json file, you can try to list only one or two packages at a time and issue composer update vendor/package and if your individual packages are small enough you might get away with it. In my case this didn’t work
2. Ship your vendor from your local machine to the instance
yeah, just have all your composer install where you will be comforted by memory in Gigabytes and just zip and ship it to your instance.
On your local machine
tar -cf vendor.tar.gz /path/to/vendor/folder
Once you have the tar or zip of any of your favorite compressed file
scp -i /path/to/your/pem/file vendor.tar.gz ec2-user@ec2-domain-goes-here:/path/on/instance
This is assuming this will transfer your vendor file to instance.
Then log into your instance and just uncompress the file and put it on the root directory of your application.
This would be just the half of the work.
Then you will need to generate the bootstrap cache file
composer run-script post-update-cmd
yeah.. this will take care of creating the cache file of the bootstrap along with other stuffs that you put on your composer.json post-update-cmd part.
Sometimes you might want to give the write access to the app/cache and app/logs folders as well
Are you upgrading symfony to 2.3. Bum! This will be the problem you would face after upgrading the composer.json file and trying to do
the solution is simple. Just copy the existing parameters.yml file from app/config/ folder to new file called parameters.yml.dist and rerun the command