Composer problems for Drupal on shared hosting

Submitted by Webmaster on Wednesday, May 17, 2017 - 23:28

Drupal 8 does perform adequately for small sites on the better quality shared hosting offerings. Some problems remain, one of them being the poor support for Composer on shared hosting. Currently it is considered best practice to install Drupal with Composer. To avoid things getting messy, once you have started with Composer you stick with it, or abandon it completely. The present site was initially built on Drupal VM, then dropped into a shared hosting account: a good one with a small company who have a history of decent Drupal support, but who do not support composer. An old version of Composer was installed, which I had no permission to update, so I installed Composer locally in my home directory at ~/bin/, added alias composer=~/bin/composer.phar to my .bashrc to ensure that the 'composer' command called my fresh local copy and not the out-of-date globally installed copy.

Then, with my freshly installed Composer, I tried to install File Entity module with 'composer require drupal/file_entity'. That failed, with message Warning: proc_open(): fork failed - Cannot allocate memory in phar:///…/composer.phar/vendor/symfony/console/Application.php on line 973. Opening a ticket with the hosting company did not resolve the matter.

Composer is memory hungry, as well as slow. On shared hosting there is every chance that attempting to install a Drupal module using 'composer require' will cause a memory error with the above warning. Several people have opened tickets on this error, and in every case it seems that the server really was running out memory. This was causing my problem. The above version of the message is what I saw using PHP 7.0. When that happens on PHP 5.6 I see a message like "Fatal error: Out of memory (allocated 850395136) (tried to allocate 134217728 bytes) in phar:///home/johnbirc/composer.phar/src/Composer/DependencyResolver/Solver.php on line 220". It comes to the same thing: the server is running out of RAM.

Your hosting company may let you set your php memory_limit variable to 4GB. This does not mean they will give you access to 4GB of RAM, ever. That creates a confusing situation where you imagine you have provided enough RAM to run the script, and you have not. In my experience, shared hosting companies rarely advertise the maximum memory an account has access to, but the better providers will tell you if you ask. The problems outlined in this post cropped up where the hard limit was 1GB, so even though cPanel allowed the php memory_limit to be set to 4G, only 1GB was available, and 'composer require' would not run on a composer.json taken from Drupal VM with 1GB. It has been suggested (see the link the last paragraph) that the availability of a GUI for composer may remove the barrier to entry which relying on Composer presents for site builders without command line skills. While Composer remains sufficiently demanding of RAM that 'composer require' will simply not run on shared hosting which limits users to 1GB, which is not ungenerous, adding a GUI risks only matters worse.

There is said to be a memory optimization in the pipeline and you can take advantage of it by running 'composer self-update --snapshot'. For me that was not enough to solve the problem.

The solution is to edit composer.json manually. For example if you want to install the Google Analytics module, in the "require" block you can add the line '"drupal/google_analytics": "^2.1",'. The run 'composer update'. That seems to require far less memory, and worked for me.

Does Composer harmonize with shared hosting?

Having said all that, it is worth taking a step back and asking how much Composer brings to the party, for the kind of site which is going to live on shared hosting. My reason for using Composer is more to develop good habits, than because it adds any real value in my workflow for a small site run by one person. For some contrib modules (even for a few in Drupal 7) we are almost obliged to use Composer. The same goes for installing drush. It has not made my life any easier.

The hosting service in question here is Squidix. They took over an account I had with Oak Hosting, when James Oakely sold that business. He assured me he had selected them carefully, and I have been happy with them, having tried a few shared hosts over the years. I am going to quote from a ticket by Larry Wright of Squidix where he questions the suitability of shared hosting:

After a quick search, seems a lot of people are having memory issues with Composer. The software is very memory demanding, and best suited for either a VPS or dedicated server.

Composer does what YUM actually does far better, but on a per-package basis.

Here's the thing,

1. YUM handles the system default PHP.
2. CloudLinux handles PHP on a per-account basis.
3. MultiPHP handles PHP on a per-domain basis at the native level.

Adding #4,

4. Composer handles on a per-package basis

would not work very well in our setup because you have PHP being handled on multiple levels better than what a script-level application could do.

The thing is, 80% of all modern shared hosts run identical PHP deployments. We don't restrict your usage of what components you may try on your account, but some scripts are best suited for private systems such as a VPS or dedicated server.

Larry Wright asked me to add that this is not a criticism of Composer in itself, only a comment that it is not well suited to most shared hosting. Other objections to the forced use of Composer are set out in a blog post by Marc Drummond.

The adoption of Composer is part of the adjustment of Drupal to the enterprise world. To be fair, the core devs are at least talking about ensuring that we can run Drupal either without Composer or with a Composer GUI (which does not address all the objections) here, as are Drupal Commerce.