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!

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

tim.plunkett’s picture

Sites 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.

tim.plunkett’s picture

Category: bug » feature
Status: Active » Postponed (maintainer needs more info)
jgraham’s picture

If you switched to using the libraries API, you could still support a custom path via the variable 'fullcalendar_path'.

perhaps something like:

if (!$fullcalendar_path = variable_get('fullcalendar_path', '')) {
  $fullcalendar_path = module_exists('libraries') ? libraries_get_path('fullcalendar') : 'sites/all/libraries/fullcalendar';
}

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.

bonobo’s picture

Status: Postponed (maintainer needs more info) » Needs review
tim.plunkett’s picture

Title: Remove "Path to FullCalendar" Setting » Allow "Path to FullCalendar" Setting to use Libraries API
Version: 7.x-2.0-beta3 » 7.x-2.x-dev
Status: Needs review » Active

Re: #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.

geerlingguy’s picture

I'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).

jgraham’s picture

Attached patch implements concept similar to comment 3;

jgraham’s picture

Status: Active » Needs review
tim.plunkett’s picture

Status: Needs review » Needs work
+++ b/fullcalendar.moduleundefined
@@ -8,7 +8,9 @@
+function fullcalendar_default_libpath() {

This looks fine to me, but can it just be fullcalendar_default_path()?

jgraham’s picture

Status: Needs work » Needs review
FileSize
1.42 KB

renamed per 9

bonobo’s picture

This has been working for us in a variety of sites, under different testing conditions.

tim.plunkett’s picture

aitala’s picture

Version: 7.x-2.x-dev » 7.x-2.0-rc1
Category: feature » bug
Status: Fixed » Active

For the rc1 release, I am seeing the following PHP notice..

Notice: Use of undefined constant FULLCALENDAR_PATH - assumed 'FULLCALENDAR_PATH' in fullcalendar_admin_settings() (line 12 of .../sites/all/modules/contrib/fullcalendar/includes/fullcalendar.admin.inc).

Eric

tim.plunkett’s picture

Status: Active » Fixed

Argh! I could have sworn I changed that one as well.

Committed: http://drupalcode.org/project/fullcalendar.git/commit/aee5cb9

Thanks for the quick response.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.