With the integration of Libraries API (ticket #980886: Require Libraries API), the "Path to FullCalendar" setting should no be longer necessary, as Libraries API will check the appropriate libraries directories.
In our case, we're using FullCalendar in a distribution and our libraries are located in /profiles/[distro]/libraries. Libraries API checks this directory successfully for Colorbox and WYSIWYG. Changing the path manually at admin/config/user-interface/fullcalendar is a poor solution in this case because it needs to work out-of-the-box.
This is a similar issue for the Media Gallery module: #1459594: hook_library() erroneously assumes 'sites/all/libraries' for the library path
In addition, is it necessary to move the FullCalendar folder in the library up a directory on install? This is also making it very difficult to package.
Thanks!
Comment | File | Size | Author |
---|---|---|---|
#10 | fullcalendar-1472436-10.patch | 1.42 KB | jgraham |
#7 | fullcalendar-1472436-7.patch | 1.43 KB | jgraham |
Comments
Comment #1
tim.plunkettSites are already using that variable, I can't just remove it.
You can just use a custom variable_set() in your distro, right?
As for the moving of the library directory, the plugin zip contains an entire copy of jquery and jquery ui, as well as possibly insecure demos. I've requested that a unbundled version is provided, but I haven't heard back yet.
Comment #2
tim.plunkettComment #3
jgraham CreditAttribution: jgraham commentedIf you switched to using the libraries API, you could still support a custom path via the variable 'fullcalendar_path'.
perhaps something like:
It would be unfortunate if every distribution on drupal.org had to write code to find fullcalendar's library and set its variable accordingly.
Regarding the package bundling, that's a valid concern and perhaps that aspect should be moved to the infrastructure/packaging queue.
Comment #4
bonobo CreditAttribution: bonobo commentedComment #5
tim.plunkettRe: #3
Yes, that code isn't too terrible. I would take it a step further, and variable_set whatever the results are, maybe.
The packaging is way out of my hands, its a third party library. See https://github.com/arshaw/fullcalendar
Not needs review until there is a patch.
Comment #6
geerlingguy CreditAttribution: geerlingguy commentedI'd like to see Libraries API used normally as well, so simply having the library inside
profiles/profilename/libraries/fullcalendar
would work. +1 on penguininja's original issue request :)(Ref: #1429500: How to place downloaded library in /sites/all/libraries/[directory]?, #1405994: Move FullCalendar to sites/all/libraries).
Comment #7
jgraham CreditAttribution: jgraham commentedAttached patch implements concept similar to comment 3;
Comment #8
jgraham CreditAttribution: jgraham commentedComment #9
tim.plunkettThis looks fine to me, but can it just be
fullcalendar_default_path()
?Comment #10
jgraham CreditAttribution: jgraham commentedrenamed per 9
Comment #11
bonobo CreditAttribution: bonobo commentedThis has been working for us in a variety of sites, under different testing conditions.
Comment #12
tim.plunketthttp://drupalcode.org/project/fullcalendar.git/commit/7b4f310
Thanks!
Comment #13
aitala CreditAttribution: aitala commentedFor the rc1 release, I am seeing the following PHP notice..
Eric
Comment #14
tim.plunkettArgh! I could have sworn I changed that one as well.
Committed: http://drupalcode.org/project/fullcalendar.git/commit/aee5cb9
Thanks for the quick response.