NOTE: This article is old, but the information is still relevant. If you are installing Composer on a host, especially a shared host, then you may want to rethink your development workflow. For typical Drupal development, you should be using Composer locally and then in a CI/CD process rather than on the host.
I just moved a site from GoDaddy to InMotion Hosting. As a part of the move, I did a cPanel backup, then had their support team do a restore on the new server. This saves some work, in that all cPanel settings (email accounts, FTP settings, etc.) are transferred. However, it can also bungle some things if you aren't careful or aware of them.
I'm not sure this is a result of the cPanel backup and restore, but the version of composer on InMotion was 1.1.1, which at the time of this writing is pretty outdated (currently at 1.6.2.) I wasn't able to do an inplace upgrade, as it was installed in a global location where I didn't have write access. To get around it, I did a manual install:
curl -sS https://getcomposer.org/installer | phpsudo mv composer.phar /usr/local/bin/composer- Edit the .bashrc file
(nano ~/.bashrc) - At the bottom of the file, add:
alias composer="/usr/bin/php-cli ~/bin/composer/composer.phar" - Run the following commands to reload the path settings and verify composer is up to date:
source ~/.bashrccomposer --version
What this does is install composer in the local user's bin directory, and add that to the list of aliases to override the global location.