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.
This is a must. We can't just keep adding module_exists for everything.
And before we do anything, we need to run it by merlinofchaos, so that we don't introduce a poorly designed new paradigm.
Comment | File | Size | Author |
---|---|---|---|
#29 | jqueryUI-fail.png | 70.93 KB | aspilicious |
#18 | moreOptions.patch | 3.62 KB | aspilicious |
#13 | fullcalendar-1326772-13.patch | 24.45 KB | tim.plunkett |
#12 | fullcalendar-1326772-12.patch | 24.16 KB | tim.plunkett |
#11 | fullcalendar-1326772-11.patch | 15.4 KB | tim.plunkett |
Comments
Comment #1
tim.plunketthttp://drupalcode.org/project/views_slideshow.git/blob/refs/heads/7.x-3....
http://drupalcode.org/project/views_slideshow.git/blob/refs/heads/7.x-3....
This is exactly what we need. Awesome!
Comment #2
aspilicious CreditAttribution: aspilicious commentedOk here is a starting patch, totally untested.
We also need an extra hook to parse the results if needed.
Comment #3
aspilicious CreditAttribution: aspilicious commentedfor some reason I don't get tabs slipped in... hmm srry for that
Comment #4
tim.plunkettNo $ here.
Is this even valid? I see it in views_slideshow, but wow that looks weird.
:)
Also, I think splitting out the Colorbox form settings to /contrib/colorbox.fullcalendar_contrib.inc is a good test. We can decide later if we actually want to do that (since it would mean making its own fieldset).
Comment #5
aspilicious CreditAttribution: aspilicious commentedWell thats the way to pass the form and formstate to the hooks. We reference the current form and formstate and throw into call_user_func_array
Won't this cause conflicts if you alrdy had colorbox settings They will be lost. But anyway it's a good showcase
Comment #6
aspilicious CreditAttribution: aspilicious commentedOk, colorbox views settings, even the samewindow dependency, are working just need to remove the javascript from fullcalendar and load it in fullcalendar_colorbox.
I think this needs to be a seperate module even if it destroys the settings.
And why do you NEED a .module file before drupal sees your module ;)
Comment #7
aspilicious CreditAttribution: aspilicious commentedStupid strange tabs... Now gone?
Comment #8
aspilicious CreditAttribution: aspilicious commentedSadly, the javascript examples in our api docs are incorrect, they just don't work :p. Options is not a function it's an array. And registerOptions doesn't exist at all.
So I had to figure it out myself but now I have one problem left, settings need to be passed to contrib js or it's kinda useless :p
Attached an almost finished patch, only the javascript part doesn't work because of the not existing settings.
Comment #9
tim.plunkettYeah adding it to Drupal.fullCalendar.options directly is always available, but registerOptions does exist!
http://drupalcode.org/project/fullcalendar.git/commitdiff/dd93fd9cccc2b0...
Comment #10
aspilicious CreditAttribution: aspilicious commentedAAAH, I was not on the latest version...
So how can we pass the settings?
Comment #11
tim.plunkettHere is a different approach, reusing the ctools_plugin stuff from fullcalendar_colors.
We'll have one module (currently named fullcalendar_contrib, but I'm thinking about fullcalendar_options) as a place to implement custom functionality, and an example for other custom modules.
I think MODULENAME.fullcalendar.inc is enough, especially since the hook is provided by fullcalendar.module itself.
Comment #12
tim.plunkettThis requires a cache clear, and for you to go to admin/config/user-interface/fullcalendar/options and hit save. I'll figure out automating that later. There will be a new fieldset called Extra Options now.
Comment #13
tim.plunkettI forgot to switch colorbox to use the per-view setting.
Comment #14
tim.plunkettPushed a bunch more changes, I'm going to be adding some more support for other options in subsequent commits.
git clone --branch options-1326772 http://git.drupal.org/project/fullcalendar.git
Comment #15
tim.plunkettOkay, so there is still an issue with the fullcalendar_options where ints become strings and bools become ints. But that's a Views bug, so we'll have to fix that separately.
Comment #16
tim.plunkett#1344320: Allow option_definition to define the value's type
Comment #17
aspilicious CreditAttribution: aspilicious commentedMORE OPTIONS!
Here are some I made today.
The revert stuff doesn't work for some reason and the day and week views are kinda broken on my dev site. I get the feeling it's a fullcalendar plugin bug (looking at the js console)
Comment #18
aspilicious CreditAttribution: aspilicious commentedComment #19
aspilicious CreditAttribution: aspilicious commentedLatetst branch doesn't work. Events aren't editable at all so I think your own made function is failing.
We also should set min and max time back to a width of 7.
Comment #20
tim.plunkettHm, works great for me. Not sure what you mean.
Also, we agreed we were sticking with integers only for now? The type cast code workaround doesn't let different types than the default value type.
Comment #21
tim.plunkettOkay, this requires #1278580: $form['#submit'] not executed when the 'Apply' button is clicked inside a display options modal, since options_submit isn't receiving the form properly.
I moved all of the crazy logic out of fullcalendar.views.js (#1344836: Remove JS special processing). It's now really small and easy to read.
In addition, the processing in fullcalendar_get_settings() is now mostly handled by fullcalendar_fullcalendar_options_submit().
I added a weight to hook_fullcalendar_option_info(), but that only controls the order stuff is added to the form, I need a good way to have that also control the order that JS is processed.
Comment #22
aspilicious CreditAttribution: aspilicious commentedThis still doesn't work...
In my view I:
- Disable weekends
- Diasbable all day
- Enable editing
==> results
- weekends still there
- all day still there
- can't drag and drop events
- day and week view still broken
Comment #23
aspilicious CreditAttribution: aspilicious commentedNew view is working it's the "old" one that brakes
Comment #24
tim.plunkettOkay, so upgrade path problems I can deal with :)
But c'mon Bram, how cool is the new code?!
Comment #26
tim.plunkettRight, this comes back to the fact that views has no way of being updated from hook_update_N. I guess we need more init() code. Ugh.
Comment #27
aspilicious CreditAttribution: aspilicious commented:D I didn't had the time for serious revies so I didn't look at the code yet. But I think it's very cool ;)
Comment #28
tim.plunkettPosted a new branch, http://drupalcode.org/project/fullcalendar.git/tree/refs/heads/options-f...
Comment #29
aspilicious CreditAttribution: aspilicious commentedUpgrading a alpha 7 site fails kinda hard :(.
I got the juery UI theme gone problem again.
When trying to resave the view I got the next error message
Comment #30
tim.plunkettOkay, I fixed that error and I think I fixed the upgrade path. It worked for me all the way from 7.x-2.0-alpha7 to options-for-merge.
Comment #31
tim.plunkettUnfortunately, that one commit came right after the Views 7.x-3.x-rc3, so this still requires Views dev.
#1278580: $form['#submit'] not executed when the 'Apply' button is clicked inside a display options modal
Comment #32
tim.plunketthttp://drupalcode.org/project/fullcalendar.git/commit/032e8aa
AWESOME!
Thanks so much for testing, aspilicious.