Closed (outdated)
Project:
Event
Version:
4.7.x-1.x-dev
Component:
User interface
Priority:
Normal
Category:
Feature request
Assigned:
Unassigned
Reporter:
Created:
11 Oct 2006 at 21:00 UTC
Updated:
13 Apr 2018 at 20:57 UTC
Jump to comment: Most recent, Most recent file
Comments
Comment #1
asanvicente commentedAny luck with this? I've been trying to figure it out with no luck.
Comment #2
spamjim commentedHere is what I started working on but got distracted so it is not finished. I placed and called this function in event.theme. It should probably go somewhere else but I have not had time to return to it and think it through fully.
This presents a droplist of the next 12 months. On change, it jumps to the new month page view.
Any suggestions for improvement are appreciated.
Comment #3
asanvicente commentedI'll give this a try. Thanks.
Comment #4
geodaniel commentedIt would be nice to be able to keep in place any filters that have already been set as well
Comment #5
geodaniel commentedI've spent a bit of time on this today and attach a patch that gives admins the option to include a jump-to-date control on calendar pages. The control has a dropdown select menu for days, months and years (only years that have events in are included) and a button to jump to that date. Any filters that are already applied should be remembered.
I didn't want to do the autosubmit because it would mean doing it for each dropdown and would force someone to refresh the page three times when trying to enter a date.
Comment #6
geodaniel commentedHere's a patch for Drupal 5 too. I can't get any of the filters at the top of the calendar to actually work in the Drupal 5 version though, which could be a separate issue (the drupal_goto commands do not appear to be being called).
Comment #7
geodaniel commentedIt looks like this is related to a change in the way the forms are structured (no longer $_POST['edit']['event_type_select'], for example, but $_POST['event_type_select']). Changing these values helps it work a little better, though seemingly intermittently. I've read somewhere that $_POST use should be dropped in favour of $form_values but that variable doesn't seem to yield any values.
Comment #8
mennonot commented+1 on this patch. Thanks for your work on this, geodaniel.
I used it to patch Event 5.x and found it very useful. Two minor corrections:
First, as geodaniel suggested in his January 22 comment, the post section should be changed to the following to remove the [edit] element:
Secondly, when defining the default selection for the month select box, the patch needs to strip the leading zero off of the $curmonth variable so that it matches up with the correct month in the array. Here's how I corrected the code with ltrim():
Comment #10
japerryEvent for Drupal 8 is unrelated to older versions. If an issue similar to this one exists, please open a new issue with the 8.x branch.