Issue #5: Defensive defaults for servers that may not have write permissions.

[laryn]

Fixes #5.

[AlexHoebart-ICPDR]

This did not yet solve the error, it just changed slightly to "Error resolving vendor directory: public://vendor".
Reason is that realpath in function composer_manager_vendor_dir() does not know about "public://" wrapper.
I added the following code after $vendor_dir is set:

  if (strpos($vendor_dir, 'public://') !== FALSE) {
    $public_dir = config_get('system.core', 'file_public_path');
    $vendor_dir = str_replace('public:/', $public_dir, $vendor_dir);
  }

I'm not sure if this is the best way, but it solved the problem for my setup and the new defaults as it provides the relative path "files/vendor" to the realpath function.

A strange issue is still that on the settings page, the Composer directory appears with the real path (translated from public://) and is only created after settings are saved. (Maybe that would be also better for the vendor directory?)

Just for info: I also tested the D7 version of the module and it produces a similar result when enabled:
Error resolving vendor directory: sites/all/vendor
RuntimeException: Error resolving directory: public://composer in composer_manager_file_dir() (line 294 of xxx/sites/all/modules/composer_manager/composer_manager.module).

[laryn]

@AlexHoebart-ICPDR I wonder if we can change realpath to backdrop_realpath in that function. (I know it says in the comment that we cannot because it's early in the bootstrap, but the function is also already manually including file.inc, which is where backdrop_realpath() is defined.)

[AlexHoebart-ICPDR]

I tried using backdrop_realpath and it did not work, but I did not explore further why as I'm not much familiar with the bootstrap process.

[laryn]

@AlexHoebart-ICPDR I've been letting this percolate in the back of my brain. Does this sound like it would work?

• Leave the default config as is, with "public://vendor"
• Add a hook_install() that loads that value, converts it to a backdrop_realpath(), and saves it back to config.

[laryn]

@AlexHoebart-ICPDR I've updated the PR here and tested locally -- it worked locally, but would love to have confirmation on your server that had the earlier problem.

[AlexHoebart-ICPDR]

@laryn very nice, I tested this on my server and installation goes well without any errors. The composer and vendor directories are created in my files directory.

One tiny issue, not sure if related:
The Rebuild composer.json file button on the Packages configuration page is disabled when I visit that page after install. It only gets enabled after I visit and save the Settings page.

[laryn]

Thanks @AlexHoebart-ICPDR -- I have made another adjustment in the PR which moves the rebuild button to the top (unrelated to the issue but it just seems lost at the bottom if you have a larger number of libraries listed) and also sets the flag to try to ensure the file directory is writable when that button is added to the form. Does that solve the last tiny issue? Any other issues related to this?

[AlexHoebart-ICPDR]

Super, I think this is perfect now! I tested the latest PR from scratch and everything goes smooth. I also then moved the directories in the shell and adjusted settings. All well.
Thank you!

[laryn]

Great, thanks for your help!