Add a directory to the PATH

This already exists. Package Manager has a configuration object where you can set the explicit path to Composer: https://git.drupalcode.org/project/drupal/-/blob/11.x/core/modules/packa...

So you could just do this: drush cset package_manager.settings executables.composer /path/to/composer

Setting this value is probably not necessary in DDEV because I think Composer is available to the web server, but outside of DDEV I'm not sure there's much that Drupal CMS can do about this since it is completely server-specific.

Leaving this open for now in case anyone has some idea about what we could do here, but I'm kinda tempted to call this a "won't fix".

Thanks phenaproxima. That command didn't work but I found there was some help text in the package_manager module and after installing the help module I could see how to add the config to my settings.

So you're right, there is a config available and it works on shared hosting. Thanks.

Great! Closing this out, since everything works as designed here.

#2 only solves half of the problem. "drush cset package_manager.settings executables.composer /path/to/composer" works but on the hosting server (pair.com) I use the wrong PHP client version is used. There needs to be a way to also point to the proper php cli version. For PHP.cgi I can point to the proper version for Drupal but accessing composer though package_manager connects to the hosting server's default of PHP 7.4.33 and so far, I have not been able to find a way to force the connection to a valid version of PHP needed for the needed version of composer.

When it comes to the PHP interpreter, there's not a ton we can do about that, honestly, at least not in Drupal CMS. This probably would need to be fixed upstream in Package Manager (which is a core module).

Moving to core's issue queue and retitling for that.

Here is a workaround for FastCGI on a shared hosting server with ssh access.

The challenge is that composer only looks for 'php' and there isn't a direct way to identify an alternatively named php and php.ini location.

The following script can be placed in your local bin folder. Follow the instructions in the script and edit it for your environment:

#!/bin/bash
#
# Run composer with the proper version of PHP and php.ini
#
# Place this script in your local bin directory and name it composer. Be sure to
# set executable rights to the file (chmod u+w composer.)
# Get composer.phar from getcomposer.org and copy it to your local bin directory.
#
# Since composer looks directly for the name 'php' you must also create a symlink in your
# local bin folder: ln -s /usr/local/bin/php83 php (or wherever your version of php is located.)
#
# Create PATH necessary to run composer and anything else that many be needed. Be sure to include
# the full path to your local bin directory as the first option.
export PATH=[Full path to local bin directory]/bin:./vendor/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin

# Create the variable that defines the location of php.ini
export PHPRC=[Full path to directory where php.ini is located] 

# Start composer with everything from the command line.
[Full path to your local bin directory]/composer.phar $*

Add the following lines to your Drupal settings.ini file:

$config['package_manager.settings']['executables']['composer'] = '[Full path to your local bin directory]/composer';
$config['package_manager.settings']['additional_trusted_composer_plugins'] = [
  'wikimedia/composer-merge-plugin',
];
$config['package_manager.settings']['include_unknown_files_in_project_root'] = TRUE;

'additional_trusted_composer_plugins' is need for some of the CMS recipies.
'include_unknown_files_in_project_root' is needed if you need to modify your environment using assets stored outside of Drupal CMS's root. In my case I need to modify .htaccess for FastCGI.

The whole idea of ​​Drupal CMS was to make the installation process simple and accessible even to advanced users (non-coding experts).
This is definitely a bug that needs to be fixed, otherwise Drupal CMS will become POINTLESS.

I am also struggling with this issue. Drupal CMS was supposed to work out of the box :(

#2 does not work for me. However, I'm not 100% sure my Composer path is correctly written (my installation in on a shared hosting):

drush cset package_manager.settings executables.composer /home/accountname/.composer

This issue definitely belongs in Drupal core, since that's where Package Manager comes from.

@mediameriquat are you able to check the version of composer installed on your hosting? I think there's another issue somewhere where the message when composer is too outdated is not very explanatory.

@catch My Composer version was outdated indeed. Looks like cPanel installs 2.3.10 by default.

After updating Composer to 2.8.8. and setting the path to /home/[username]/bin/composer/composer.phar, I get a less verbose error message :

Composer was not found. The error message was: Syntax error

Still the wrong path, I guess...

Did you make composer.phar executable (chmod +x /path/to/composer.phar)?

@phenaproxima My composer.phar is executable, yes. Thanks for reminding me of checking those pesky permissions.

@mediameroquat check #9. My host has and outdated Composer as default and the default PHP points to an outdated version. I have had Composer and PHP working for a few months now.

I contacted my web host to know the server-wide Composer path. On a cPanel shared hosting, I ran the #2 drush command as follows and bingo!

drush cset package_manager.settings executables.composer /opt/cpanel/composer/bin/composer

However, automatic updates are not yet possible, because I get another error message: rsync is not available → . This is a totally different issue.

+++

As far as my experience goes, I don't see how Drupal CMS can ever compete with WordPress and/or hosted solutions such as Wix. WordPress is overrated and chaotic, but it can be installed in 5 minutes and automatic updates will work on any shared hosting.

rsync is another one where you can configure the path to it, if it's on the web server and you have permission to execute it. If you can SSH in, which rsync should give you the path, then you can do:

drush cset package_manager.settings executables.rsync /full/path/to/rsync