Needs work
Project:
Libraries API
Version:
6.x-1.x-dev
Component:
Code
Priority:
Major
Category:
Task
Assigned:
Unassigned
Issue tags:
Reporter:
Created:
11 Jul 2011 at 17:09 UTC
Updated:
8 Aug 2011 at 10:04 UTC
Jump to comment: Most recent file
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?