Using Composer with shared hosting
I can’t use Composer because I’m using shared hosting and don’t have SSH
I’ve seen this sentiment a few times now, so this seems like a good time to point out that you do not need SSH access to your server in order to use Composer. In fact, I don’t run Composer on a live server (regardless of whether it’s using shared hosting) and it’s not on my list of things to do in the near future.
What you do need is a process where you handle your Composer dependencies on your own computer where you have PHP running.
In my view, you have two choices: commit your Composer dependencies directly to your project or write a build script that runs Composer for you and uploads the resulting files.
In either case, you need to install Composer globally, so follow the instructions relevant to your operating system.
Let’s look at the process for both options, starting with committing your Composer dependencies.
Commit Composer dependencies
The easiest way to handle Composer dependencies is to run Composer locally and commit the vendor directory into your repository.
Write your website, using Composer, as usual and commit composer.json, composer.lock and all the files in vendor.
Note the following:
- Ensure that your .gitignore file does not exclude vendor. This is very common when starting from a skeleton project or using a tool like artisan to create your project.
- Ensure that you only use packages that have a release number. That is never use dev-master in your composer.json as if you do, Composer will install it via git and you won’t be able to add it to your own repository. There are good reasons for avoiding dev-master dependencies anyway.
Your git repository now has all the files needed to run the website directly within it and so you can now simply upload your website to your shared host as you usually do.
Use a build script
If you don’t want to commit the dependencies to your git repository, another solution is to write a script that you run locally that downloads the dependencies and thenuploads the files to your host.
The process looks like this:
- Check’s out your source code to a clean directory
- Runs composer install
- Removes all .git directories and any another files and directories that shouldn’t be on your live site
- Uploads all the remaining files to your shared host. (if your host uses FTP, then use ncftpput for this as it supports recursion)
- Deletes the directory
Note that in this situation, you need to ensure that the vendor directory is excluded in your .gitignore file and that composer.lock is committed to git.
Run the script every time you need to put new code onto your live site.
Summary
As you can see, using Composer to manage the dependencies of your PHP project has nothing to do with your final choice of hosting for your live site. You should always have the ability to run your PHP website on your local computer and so you can deal with Composer there and it’s simply a case of transferring the right files to live.
In general, I’m a big fan of scripting things that are done by hand, so recommend using a build script, even if you choose to commit your dependencies to your own repository.
I have been creating projects with these method you have described and have had no problems. I use symfony, symfony cmf, not too much twig,sqlite and no mysql. Projects I deployed on share hosting are small in nature. After I have finished the projects on my local development, it's just drag and drop, clear my cache and hit the home page. I am planing to blog about it this coming year.
You mentioned "I don't run Composer on a live server". Is it really bad? What are your reasons? I generally run 'composer install' (never update) on productions server and think it is supposed to be like that.
In general, I like the exact same files that were signed off on the staging server to be deployed to the live server.
Hi Rob, nice post. I've done similar research and one of the things I find very important is the use of the config.platform option inside the composer.json file.
When installing or updating the dependencies, composer will choose a version of the package compatible with the PHP version that we are using to run composer. The config.platform option must be used to instruct composer to consider a specific version of PHP (which can be different from the one running the composer command). This is needed to ensure that the packages downloaded by composer are compatible with the version of PHP available in the production environment.
This Method seems logical, but, I'm having issues because I use a windows dev machine and my hosting server is linux. Composer is generating file paths and using functions that seem to only work in windows. Is there a way to tell composer to generate linux format file paths?
Nick,
I don't know. However, I would suggest looking into using vagrant running Linux for your local dev environment so that you more closely match live.
Hi,
I have found one article here http://www.fuelforbrain.com/drupal-8-how-install-drush-shared-hosting
which gives details about how to install Drush on shared hosting for Drupal (CMS). In step 4 of article they have installed composer on shared host. Is it right way to do it?
@ErnestBoabramah
You can used Envoyer or git to deploy your symfony app easily. Also, why shared hosting. Shared servers have poor performance and security. A better option is vps, if you have sysadmin skills. Otherwise use platforms like Cloudways symfony hosting to host your symfony app on managed servers that are scalable and have better performance.
One thing that I have noticed is that some scripts recommend that you use Composer to install the script, but everything in the composer.json file is stuff that is already installed on your hosting account. For example, one composer.json file had a dependency of PHP and some common PHP libraries, all of which come standard with most commercial hosting accounts. In this case, unless you are setting up your own hosting environment from scratch, these dependencies are already installed on your shared hosting account, VPS or dedicated server.
And for people using shared hosting, they would not even have the proper permissions to install PHP libraries and would have to contact support. Someone with root access would then go into WHM or a command line and install the proper libraries.
So, if you are using a hosting environment that is already set up for you, check the composer.json file to see if you really need to run it. Everything there might already be installed on the server.