Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
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.
Comment | File | Size | Author |
---|---|---|---|
#6 | libraries-tests.patch | 915 bytes | tstoeckler |
#1 | libraries.install.1.patch | 1.33 KB | sun |
Comments
Comment #1
sunAttached patch fixes the issue.
Comment #2
sunComment #3
tstoecklerI don't get the explanatory subclause. Either revise that or just leave it out (preferred, I think).
This should be in < code > tags.
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. :)
Comment #4
tstoecklerTentatively 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?Comment #5
sunNote 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...
Comment #6
tstoecklerI 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?