Early Bird Registration for DrupalCon Portland 2024 is open! Register by 23:59 PST on 31 March 2024, to get $100 off your ticket.
We are 2 versions behind, so here's a patch that updates the fullcalendar library files (js and css).
For reference: http://arshaw.com/fullcalendar/download/
Perhaps instead of including the fullcalendar library files in this module, we should make it a manual dependency, similar to wysiwyg and other modules that require 3rd-party libraries. Thoughts?
Comment | File | Size | Author |
---|---|---|---|
#28 | fullcalendar-980886-28.patch | 9.88 KB | tim.plunkett |
#26 | error fullcalendar.png | 17.77 KB | aspilicious |
#26 | error fullcalendar2.png | 10.16 KB | aspilicious |
#25 | fullcalendar_libraries_D7.patch | 8.66 KB | aspilicious |
#19 | fullcalendarPort.patch | 11.75 KB | aspilicious |
Comments
Comment #1
tim.plunkettProbably a good idea, but I'm going to postpone this for now. 1) Because it conflicts with #906112: handle drag and drop: creating events, rescheduling events, and 2) because I want to check on the current best practice for including 3rd party libraries.
Comment #2
geerlingguy CreditAttribution: geerlingguy commentedI vote for using Libraries API, and instructing users to download fullcalendar.js and put it in sites/all/libraries.
Comment #3
jwhat CreditAttribution: jwhat commentedYes, I agree.
Comment #4
tim.plunkettWe can't have dual licensed JS in the module itself, using Libraries API is a good idea.
Comment #5
tim.plunkettComment #6
DamienMcKennaPlease see how jQuery_UI handled the same issue: #489140: Libraries API
Comment #7
DamienMcKennaQuick summary of #489140 for those who don't want to read the full thing:
In short, you don't need an extra module just to standardize on using "sites/all/libraries" as the standard 3rd party file location.
Comment #8
jwhat CreditAttribution: jwhat commentedThanks to DamienMcKenna for the recommended solution. I implemented it exactly as he suggested: first check sites/all/libraries/fullcalendar, then check via Libraries API (if the module exists, of course), then displaying an error msg if the library is missing.
The fullcalendar.js file needs to be deleted now but I'm not sure how to note that in the patch.
Comment #9
tim.plunkettThis breaks #910510: Add support for event class / assigning colors to events. Which I should have seen coming.
I'm half tempted to file a patch (pull request?) against FullCalendar itself, suggesting they split out the default styling of events to another stylesheet. Because otherwise, it is overly difficult to override.
Thoughts?
Comment #10
geerlingguy CreditAttribution: geerlingguy commentedI support that idea; It would be great if we could have a separate stylesheet with only the bare minimum of tweaks to make sure FC works in Drupal.
Comment #11
jwhat CreditAttribution: jwhat commentedCouldn't we just put that custom CSS into our own fullcalendar.css file and override it like
html .fc-event-default
etc? If you'd like I can roll that includes this.Comment #12
jwhat CreditAttribution: jwhat commentedI meant, I could roll a patch...
Comment #13
jwhat CreditAttribution: jwhat commentedHere's a patch that contains the few customizations that were previously added to the 3rd-party fullcalendar.css... now added to our custom fullcalendar.css.
Comment #14
tim.plunkettCurrently I can use theme_fullcalendar_classname() to remove .fc-event-default, and add my own class, and the color can change.
Using the official fullcalendar.css, this is not the case. In CSS I would need to follow their example of overriding colors.
Compare this
to this
Now consider that I'm using theme_fullcalendar_classname() to assign a class for each taxonomy term on my site. The amount of extra CSS gets out of hand.
Comment #15
tim.plunkettThis removes the .js and .css file, moves our specific code into fullcalendar.custom.css, and adds drush integration to facilitate downloading the plugin.
Comment #16
tim.plunkettThe library/version checks and drush integration borrows heavily from colorbox, major props to them.
Comment #17
geerlingguy CreditAttribution: geerlingguy commentedJust tested on my install, and everything works fine - I had to move the entire contents of the 'fullcalendar' directory into /sites/all/libraries/fullcalendar, of course. Once I did that, the styling and js file for fullcalendar (1.4.9 or later) worked great.
Great work!
Comment #18
tim.plunketthttp://drupal.org/cvs?commit=471720
Awesome!
Comment #19
aspilicious CreditAttribution: aspilicious commentedThis is a starting patch...
I also edited some comments/made a comment framework cause doxygen state of this module is prety bad :)
Btw you should replace all the occurences of colorbox by fullcalendar (docs) in the 6.X branch :)
I didn't test it, it's just a strate port without the jquery stuff.
Comment #20
aspilicious CreditAttribution: aspilicious commentedComment #21
tim.plunkettI think I only missed two references to Colorbox, I couldn't do a straight replace since we actually reference Colorbox.
I'll take a look at this soon I hope.
What do you think about doing a doxygen patch for D6? Split that off into another issue for both branches?
Comment #22
aspilicious CreditAttribution: aspilicious commentedYeah, best to split things.
This patch:
-----------
I removed all the array stuff because we only have one dependency in D7.
But I now realize we maybe will have multiple dependencies in the future.
So maybe I should put those arrays back.
Comment #23
tim.plunkettThat last comment reads as though you intended to attach a patch.
Also, I would put the arrays back, it can't hurt to leave open for further dependencies.
Comment #24
aspilicious CreditAttribution: aspilicious commentedI don't have time to patch a lot these days...
Srry for that, so if someone else wants to dit it. Go for it.
Comment #25
aspilicious CreditAttribution: aspilicious commentedOk ported. I'm going to test this. Post a link when I'm done installing :)
Comment #26
aspilicious CreditAttribution: aspilicious commentedI don't think I ported this well.
First error message is just because I didn't had the library, is it normal to get such a message?
When looking at the view I get the second error.
Comment #27
aspilicious CreditAttribution: aspilicious commentedBoth error messages are gone now.
Something with dates getting erased when saving (or something like that).
Apparantly something goes banan than cause the module sees the empty field and returns false and goes nuts.
So... almost done testing...
I don't get any good output yet.
Only this:
Test Event
Fri, 07/01/2011 - 08:45 to Fri, 07/01/2011 - 20:11
So it looks like js isn't loaded. Chrome development tools say it is actually loaded. BUT the js from the library hard code months and days. Could this conflict with my dutch installation?
Comment #28
tim.plunkettThe new
hook_library()
is awesome!Revamped to use that instead of
hook_init()
(which apparently doesn't play well with aggregation).Comment #29
aspilicious CreditAttribution: aspilicious commentedGood to go :). Works perfect.
Comment #30
geerlingguy CreditAttribution: geerlingguy commentedThanks for doing the reviews. Getting a good 7.x branch going will be a tremendous help!
Comment #31
tim.plunketthttp://drupal.org/cvs?commit=485156
Comment #32
aspilicious CreditAttribution: aspilicious commentedCleanup of the issue queue!
Comment #33
aspilicious CreditAttribution: aspilicious commented