I think it would be hand to either list as one entry or multiple the install libraries and version just as info. I see most library modules did/do that before/after libraries integration and seems to make sense.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

RobLoach’s picture

Status: Active » Closed (duplicate)
sun’s picture

Status: Closed (duplicate) » Active

mmm, integrating with hook_requirements() is a different "UI" in my book. Exposing the libraries and versions of (certain?) libraries on the Status report page, possibly including version dependency mismatch handling, is a bit different to an installation/configuration/overview UI.

RobLoach’s picture

Cool!

tstoeckler’s picture

The patch I had over at #819610: Provide a UI for Libraries (and just re-rolled) implements sort of a Status report page. So I don't know if that rather belongs over here, or whatnot.

boombatower’s picture

If anything libraries could simply add a single (or one for each failure) requirements for libraries that fail, just so it says go check status page which can then be a link to the libraries UI. Rather then duplicating the UI on the status page?

tstoeckler’s picture

Hmm... what about WYSIWYG API? It registers like 5 (or whatever) libraries, but not all of them need to be installed.
I guess this calls for some sort of dependency handling...

Is there an issue for
libraries[] = foo
for module .info files?

joachim’s picture

Issue summary: View changes
Status: Active » Needs review
FileSize
1.35 KB

This would be really nice to have. Currently, modules that implement libraries have to repeat the same work in hook_requirements() and this would save them that work.

> Hmm... what about WYSIWYG API? It registers like 5 (or whatever) libraries, but not all of them need to be installed.

I guess that means that a missing library shouldn't produce a REQUIREMENTS_ERROR, but only a REQUIREMENT_WARNING. Or even REQUIREMENT_INFO?

Here's a simple patch.

As suggested in #5, this could be enhanced with UI links when #819610: Provide a UI for Libraries gets in.

sun’s picture

I don't think we should list non-installed libraries.

Although that slightly defeats the purpose of "requirements". Perhaps we need a new 'required' Boolean key in library definitions?

Lastly, in case of Wysiwyg module, a library is only required if you have a wysiwyg profile that actively attempts to use the editor library. Which means that Wysiwyg module requires a custom behavior and should implement this on its own; whereas requirements API helper functions might be useful.

joachim’s picture

> I don't think we should list non-installed libraries.

But most library modules that currently implement hook_requirements() use this to alert site builders to the fact that the library is not correctly installed. Are you saying we should only report "not detected" and "not supported" errors, but not "not found"? That if a site builder has created the folder 's/a/l/foobar', we can assume that they intend for the foobar library to be installed -- and if it's not correctly installed then we should report a problem?

> Although that slightly defeats the purpose of "requirements". Perhaps we need a new 'required' Boolean key in library definitions?

I was pondering that too. It would be feasible as an API addition to 2.x. Not necessary for this issue though -- could be a follow-on. But the Wysiwyg case does make this more complicated.

So I think the above suggest that are two ways we can take this:

A. Completely take care of hook_requirements(), but don't make too many assumptions. Report if a library is correctly found; report an error if it looks like a library *should* be there, but isn't -- i.e. if the folder exists and libraries_detect() finds a problem. This means that modules like wysiwyg can declare a library without it should up as a requirements error, or even a notice.

We could also add a 'required' property to hook_libraries_info(), and in that case, report a hook_requirements error if libraries_detect says "not found".

B. Don't implement hook_requirements() at all, but provide a helper for the use of library modules' own hook_requirements(). This would mean modules have to do something like this:

function mymodule_requirements($phase) {
  module_load_install('libraries');
  // Invokes this module's hook_libraries_info() and checks each library.
  libraries_requirements_helper('mymodule');
}

I'm not sure what benefit option B would offer a libraries module over option A.

sun’s picture

Exposing a requirements error for libraries that exist but are dysfunctional definitely makes sense, agreed. The problematic part are libraries that may be required but are not provisioned/installed at all, whereas we don't know whether they are required or not.

joachim’s picture

> We could also add a 'required' property to hook_libraries_info(), and in that case, report a hook_requirements error if libraries_detect says "not found".

Ok so let's file a follow-up to do this. Libraries modules whose only raison d'etre is to provide the library should set this to TRUE. For Wysiwyg, this would either be FALSE, or possibly derived in the hook_libraries_info() implementation based on admin settings?

Chris Matthews’s picture

The 4 year old patch in #7 to libraries.install applied cleanly to the latest libraries 7.x-2.x-dev and if still applicable needs review.