Module is not installable as part of a profile installation

@mikeegoulding Are you using the Libraries module? That should auto-detect libraries in any /libraries folder, and I think it supports profiles.

Looks like this might be a very old Libraries issue: #2575167: Library not loaded during installation of installation profile.

It'd be great if we could detect that the phase was the profile (Drupal) installing, not just file_browser. With your suggested change I think that the requirements check would never be made when installing file_browser, so to know the library is missing users would have to install it then visit the admin report page. Thanks for digging in so far.

Here's a test file showing the issue.

oops. :-)

And here's a slight tweak on the original fix, which should pass that test.

Oops, forgot to hide the test profile.

+++ b/file_browser.install
@@ -78,7 +87,7 @@ https://github.com/desandro/masonry/releases and place it in /libraries'
+  if (!\Drupal::isConfigSyncing() && (!\Drupal::service('kernel') instanceof InstallerKernel) && !is_writable($public_path)) {

I'm not sure how this check relates to the issue summary - shouldn't we check that the files directory is writeable even if it's a profile install?

We should also skip the file directory check, as that won't yet be set up.

was in the proposed resolution, but I'll move it up in the IS.

@samuel.mortenson See https://git.drupalcode.org/project/drupal/blob/8.8.x/core/includes/install.core.inc#L2057. Unfortunately the installer creates the files directory immediately after checking the profile requirements (which includes checking the requirements of the modules the profile is trying to install). Which I found out from my test because I wasn't even looking for that problem. So we skip the files directory test if we are in the middle of a Drupal install.

Yikes, thanks for the info @mikelutz. In general I don't think this is something File Browser is responsible for, but since there's no clear path forward in another issue I'll likely move forward with this patch. Just need some time to think (and am not working on the module today).

My recommendation would be to simply make this a runtime-only requirement, that's how blazy.module and select2.module do it for example. At least until these issues are resolved.

dropzonejs.module is a counter-example that does check the install profile similar to the patch here I guess.

Just adding in a note here that #2 works with a basic install profile but throws an issue with a distribution - looks like as a profile isn't selected when installing a distribution the call to \Drupal::installProfile() is returning null. Will update if I have a chance to debug this, am proceeding with a basic install profile for now.

I want to disable file browser when non admin user is looking at their profile. Can that be done?

Rerolled #15 to work with the latest dev branch.

No activity here for 5 years. I've just become a maintainer and I'm looking to clean up the issue queue. Can anyone confirm if this issue persists against 2.x as there have been many changes to the module. Thank you!

Let's find out. :-)

Setting this to active as it is currently being worked on and no longer postponed.

I believe this may have been fixed by the latest tagged release and on the dev branch. Can anyone confirm? If not the latest changes to the module's dev branch have caused conflicts with this issues merge request which will need to be resolved. Please look closely at the incoming change as this was a fix for another issue which I believe may have inadvertently contributed towards this one?