Remove references to settings.library_path configuration option

This is still an issue in 2.1.x.

README states that an alternate library location can be set in settings.php. Changing category to Bug because of the documentation.

Note: Since that package doesn't require composer/installers, we have no way to modify the destination install path for the library (e.g. place it in web/libraries/{$name}). If this is fixed, it would allow us to require the library via composer, and point settings.php to the vendor/moxiecode/plupload path.

The Chosen module had a similar situation detailed in #3102250. Comment #47 offered a workaround that works for this project.

I was able to require mnsami/composer-custom-directory-installer and simply add an installer-paths directive:

             "web/libraries/{$name}": [
+                "moxiecode/plupload",
                 "type:drupal-library"
             ],

With this workaround, does the maintainer and/or the community want to:

• Offer this solution in documentation
• Remove the documentation about the unused settings.library_path configuration.
• Remove the comment in settings.library_path configuration yaml file.

Or, is it still preferred that this capability be available?

We should probably note too that the the examples folder should be removed from production environments.

Remove "examples" folder from libraries folder as it could constitute a security risk to your site. See https://drupal.org/node/1895328 and https://drupal.org/node/1189632 for more info.

As per Composer, this should probably be done in a build step.

I'd rather remove the references to customize library_path.

Did a quick review of other modules in similar situation and nobody cares about library path nowadays, at least at the module level. Maybe this is handled site-wide in some setting related to "type": "drupal-library",.

Regarding the library installation options, we should definitely clarify more modern options that direct download. The mnsami/composer-custom-directory-installer option you suggest seems really similar to the "The composer way #1" in DropzoneJS module. Any idea on which to take?

I wouldn’t agree that it is all that similar; just another option.

You could document those 2 options as well.

I am persuaded by Dropzone’s #2, since it doesn’t require additional packages and just uses Composer’s repository feature.

dropzone #2 has the advantage that patches in root composer are applied. So adding our examples patch would be a no-brainer. Not sure about it, but think that merged composer files do not get patches applied.

Will I get any dev-help on these fixes/improvements?

Created documentation on how to install via composer:

https://www.drupal.org/docs/extending-drupal/contributed-modules/contrib...

Then just forget about setting custom path. /libraries is quite standard.