We could aid installation profiles and such by doing #1215372: Requirements check fails on Drupal installation in a libraries_requirements() implementation, which basically just gets invoked and calls

drupal_get_filename('module', 'libraries', __FILE__);

Though some trickery would be required to turn __FILE__ into a relative path using unix directory separators. But doable, I think.

#6 libraries-tests.patch915 byteststoeckler
#1 libraries.install.1.patch1.33 KBsun
PASSED: [[SimpleTest]]: [MySQL] 0 pass(es). View
Members fund testing for the Drupal project. Drupal Association Learn more


sun’s picture

Priority: Normal » Major
Status: Active » Needs review
1.33 KB
PASSED: [[SimpleTest]]: [MySQL] 0 pass(es). View

Attached patch fixes the issue.

sun’s picture

tstoeckler’s picture

+++ b/libraries.install
@@ -0,0 +1,32 @@
+    // filesystem during initial installation requirements check, because it
+    // thinks the database would be active already. Help out third-party modules

I don't get the explanatory subclause. Either revise that or just leave it out (preferred, I think).

+++ b/libraries.install
@@ -0,0 +1,32 @@
+    //   $phase == 'install' && function_exists('libraries_get_path')

This should be in < code > tags.

+++ b/libraries.install
@@ -0,0 +1,32 @@
+    foreach ($installs as $install) {
+    }

Will there not only ever be one item in the array? Seems a $installs[0] would suffice?

Will now see if I can reproduce the problem and then fix it with this patch. :)

tstoeckler’s picture

Status: Needs review » Needs work

Tentatively setting to needs work. Tentatively, because I fear it is something on my end. Nevertheless:

- I created a test module with a dependency on libraries.module that does a dsm() in hook_requirements() inside a if ($phase == 'install' && function_exists('libraries_get_path')).
- I tried enabling Libraries module first and then the test module separately. The message appeared.
- I removed both from the system table and then tried enabling them both at the same time. The message didn't appear. So far so good.
- I removed them from the system table again, applied the patch and then enabled them both again at the same time. The message didn't appear. So it seems the patch isn't working.

Also: Instead of the patch, I tried only doing require_once dirname(__FILE__) . '/libraries.module'; in libraries_install() at first, instead of the patch, but that didn't work either. That should in theory suffice, though, to get the wanted behaviour, right?

sun’s picture

Note that this is primarily about the Drupal installer, not a regular installation from the modules page.

Apparently, I forgot to add a defined('MAINTENANCE_MODE') && MAINTENANCE_MODE == 'install' condition.

Indeed, that comment could be clarified. It refers to the original condition in the first patch in #1215372: Requirements check fails on Drupal installation. For the first condition, I originally tried to use drupal_get_filename() instead of drupal_load() (since the latter only works in a fully bootstrapped and installed Drupal environment), but drupal_get_filename() isn't able to find libraries.module either (attempts to look it up in {system}, but during Drupal installation, there is no record for it yet).

Therefore, the other patch over there attempted to use drupal_system_listing(). I no longer know why I used drupal_get_install_files() instead.

Perhaps we should rather target D7 first...

tstoeckler’s picture

915 bytes

I now tried the whole thing during install and that didn't work either.
I added a testing profile that did nothing but install 'libraries_test' module. I attached a patch which creates the 'libraries_test' module I used.

Also, shouldn't we try to fix this issue, for both situations, i.e. during Drupal install and module install from the modules page?