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.
Although related to #909296: Figure out how to document what we've learned and discussed in detail
I'd like to specifically see some documentation on how to access css & js files that are in sites/all/libraries from the theme's .info file.
I would have expected I could pull it in with:
stylesheets[all][] = /sites/all/libraries/wet-boew-jquery/js/support/menubar/style.css
rather than:
stylesheets[all][] = ../../libraries/wet-boew-jquery/js/support/menubar/style.css
Thoughts would be appreciated.
Comment | File | Size | Author |
---|---|---|---|
#7 | librariesmoduleinfo.patch | 2.93 KB | RobLoach |
Comments
Comment #1
tstoecklerWhat you explain is currently not possible with Libraries API. That said, it definitely sounds like something we want to support. Not only themes, but also modules, which have external libraries as dependencies could benefit from this.
As we don't know the path to the library upfront (it doesn't always have to be sites/all/libraries), we can't support your code example directly, but I am thinking of something like:
(similar to
dependencies[]
for modules).Comment #2
mgiffordThanks @tstoeckler It would have to be more complicated than that however, as just including the library (like the dependancies) doesn't explain what files within the library would need to be included. I don't know if something like this would work:
libraries[wet-boew-jquery] = js/support/menubar/style.css
Or perhaps something like:
I'd like to have some way for the theme to find the path and a way for the library code do recognize if the same file is loaded more than once by different modules/themes.
Comment #3
tstoecklerHmm.. we don't really support loading only parts of a library, what is the use-case for that?
Comment #4
mgiffordWell, let's say that the is a big library with a lot of code, say:
http://tbs-sct.ircan-rican.gc.ca/projects/gcwwwtemplates
You want to use it in one or more themes, but don't want to embed it in your theme.
You may not want them at all times, but from time to time in a site.
Comment #5
RobLoachThis issue might be related somehow to:
Would be nice to have the ability to define libraries via .info.
Comment #6
mgiffordAgreed, thanks!
Comment #7
RobLoachComment #8
sunHold on, #7 is quite against the principles of Libraries API - there's no correlation between modules and libraries for all the reasons being outlined on the project page - this patch basically adds support for modules to contain libraries?
Can we clarify the actual idea/proposal/question/issue in the summary first, please?
Comment #9
RobLoachNope! This just pretty much lets you implement
hook_libraries_info()
via a module's .info file. Is that what you were talking about originally, mgifford?Comment #10
mgiffordI don't want modules to contain libraries. I see real advantages to separating 3rd party software in a common, understood location rather than having it be scattered around
However, I guess I'd like to extend the definitions of libraries a bit so that one can not just point to a CCK (a book), but in the module pick out a specific CSS or JS file (one of a collection of journals) to load.
This could be in either the module or theme .info file, but we shouldn't be needing to either hard code a relative path to a specific file that is contained in a 3rd party library, or just copy/paste that 3rd party file into the theme or module we're building.
We should be able to set a dependancy library (either a book or a journal) in the .info file and then load either the whole 3rd party resource or a specific file within that resource.
I'm just looking at http://drupalcode.org/project/libraries.git/blob/refs/heads/7.x-2.x:/lib...
That's probably more than I was looking for, but since it's already there it may well be able to do what's required.
Comment #11
tstoecklerClosing this one.
In the 8.x-3.x we are striving for the ability to simply declare the name of a library in the info file, and have Libraries API take care of the rest.
You can already provide libraries in (their own) info files and even put those into a module as well using
hook_libraries_info_file_paths()
. I don't see much value pursuing this, at this point.Please re-open if there is still interest in this, or if there is an aspect I have missed.