Update Extensions page error if Composer not found

Changes are made on on 11.x (our main development branch) first, and are then back ported as needed according to the Core change policies → .

The "Update Extensions" page is actually not in core; it's part of the contributed Automatic Updates module. (Package Manager has no UI at all.) Moving to the appropriate issue queue.

Since this is a user facing fatal error, bumping to critical.

We might need a second issue to try to investigate further why the executable can't be found too.

Same error in Drupal CMS

Same issue here.

I installed Drupal CMS on a shared hosting server and visiting 'Browse' shows the error,

Unable to download modules via the UI: The composer executable cannot be found. Make sure it's installed and in the $PATH

I tried to place a copy of composer.phar on my host server but that didn't work. This is what I did.

I navigated to the root of my host account where I have vendor folder then I ran the following commands:

curl -sS https://getcomposer.org/installer | php

chmod +x composer.phar

Then I added this in settings.php,

$settings['composer_executable'] = '/home/username/composer.phar';

This doesn't work.

I am sorry my issue is not really what this issue is all about - only related.

I have the same issue here.

I installed Drupal CMS on a shared hosting as well and visiting 'Browse' shows the error,

Unable to download modules via the UI: The composer executable cannot be found. Make sure it's installed and in the $PATH

I too installed DruaplCMS on a shared host with the same error. Now,

I have been using Drupal since version 6, in fact, because of the SUPER user friendliness of the project, I was able to make a powerful vehicle tracking system for the company I worked for then, for pennies in just a few weeks, when their IT department wanted 1 year and $900k to do the same thing. Needless to say, I looked like a giant stud in my managers eyes. Drupal 7 was a fantastic version, but the pain of migrating from major version to major version is still very much real.

I have found that running dev, testing and prod version in my personal shared hosted service (I run the entire server on cPanel) has the most efficient process for me to develop, test and push to production. But a couple of years ago, I just got so fed up with composer issues that I just gave up and moved on to BackdropCMS, to the point I migrated three sites from D7 to Backdrop.

But, recently I have found the need to for one module that is not in Backdrop, and this module could be a game changer in my current project. And this project could be very lucrative if I am able to get it done. The module is google_map_services and I even asked if the dev would be interested in porting the module to BackdropCMS but I never heard back from him/her.

So, with DrupalCMS, I said to myself, "keep an open mind and maybe it's not to late to migrate to DrupalCMS and continue on"! So I read the installation notes, which was not too bad, but for a noob, may not be ideal.

Well, for cPanel, I was able to fix it with this:

In order to fix this on cPanel, you must run the following command using your ssh access:

**<cpanel-user-name> =** this is your user name you use to login to cpanel.

**<cms.example.com> =** your domain root directory.

/home/<cpanel-user-name>/<cms.example.com>/vendor/drush/drush/drush cset package_manager.settings executables.composer /opt/cpanel/composer/bin/composer

Example command: /home/user543/cms.example.com/vendor/drush/drush/drush cset package_manager.settings executables.composer /opt/cpanel/composer/bin/composer

I also posted this on the StackExchange link above.

Hello dear Drupal Community.

first of all I would like to thank Catch for taking the time to reference the issue I created yesterday.
I already thought so and therefore just took 25 € out of my wallet to test Drupal CMS on Plek. I can tell you with certainty that the error disappears as soon as you (if you can, because you have root access) delete the file composer.phar in the directories

./usr/lib/plesk-9.0/
./opt/psa/admin/plib/modules/composer/resources/composer/
./opt/psa/var/modules/composer/
has been updated to the current version 2.8.8. For many of you, this can probably only be done by the service provider.

Plesk wird nämlich auch heutzutage noch mit Composer version 2.2.5 2022-01-21 17:25:52 ausgeliefert. This version of composer is too old to work with Drupals Automatic Update Module and that is the root cause of the issue. Updateing composer would fix that. But this is something the control panel vendors or yor servcie providers have to do.

On the software side, you can only intercept this with a nice error message. You can find a suggestion for such an error message in the referenced issue.