pleasantly viewable in any browser (I 'm testing FF and IE).
Some things still don't satisfy me and some parts haven't been done yet.
But at least it doesn't look broken in IE anymore.
**********************************************************************
* THIS IS NOT COMPLETED YET AND IN FACT IT'S QUITE BROKEN RIGHT NOW! *
**********************************************************************
My head is spinning and that's enough layout madness for one day.
Fix for bug 2252:
You can now choose to have the calendar "remember" your filter settings
between logins.
Some extra code in calendar/lib.php for DST. It doesn't currently affect
how Moodle works.
The old code assumed that the courseid would always be set but that is only the case for course events, not for user or group events. (See http://moodle.org/mod/forum/discuss.php?d=4466#20827 for a discussion about the meaning of the courseid field in the event table)
I also made the $courseid argument to get_coursemodule_from_instance() optional. It is not needed and in some cases it will not be know, as for example for non-course events created by activity modules.
* Configurable defaults for the calendar upcoming events lookahead and
maximum upcoming events displayed (bug #1623)
* Configurable setting for which days of the week are treated as weekend
(bug #1919)
* Configurable setting for which day starts the week (the admin can now set
this as the default for new users and guests without messing with language
packs) (no butracker issue)
Includes preliminary support for DST!
Includes "admin sees all events or only own?" setting (bug 1972)
WARNING: Modified moodlelib.php to explicitly specify NOT-DST when
calling mktime() and gmmktime(). This is essential since we don't want
PHP to second-guess us for the DST matters, but... it may affect existing
code?
to wrong code when DST comes into play
Fixed calendar_get_upcoming to perform DST corrections according to the
server's TZ (now the users as calendar doesn't support that, but it's a start)
Removed some dead code
"cute" code (courseid > 1, both checking for non-zero and non-courseid value)
can lead to mistakes later. And it's my own code, even...
Also removed one obsolete function.
Calendar events in day view now show their start and end times. The only thing
I 'm not satisfied with is that they also show the full start and end dates,
even if it's not really needed (e.g. for a 15:00 -> 17:00 event). Still, it's
loads better than only showing the start time.
Events that span more than one month now have their duration shown correctly in
each day of all subsequent months. For some reason I didn't quite figure out,
this happened till now only on events that spanned at least THREE months. Whatever...
Also, removed a small unused part of a global statement in view.php.
is correct only for GMT+0 timezones. Fixed it in upcoming events displays to
separate days as they are in the user's timezone, will continue to pursue this.
Things are now easier for visitors and guests. We should do some regression
testing though: if you are a visitor or a guest and then you login (either
after browsing the site or immediately by typing a Moodle URL in the location
bar, without having a Moodle session at all), do user events always get shown
correctly? Does anything abnormal happen to the courses filter?
Now when moving to a calendar screen (technically, view.php) from a course
block, the course drop down list defaults to that course. The implementation
is OK, but I may change it (there is a faster way).
