The usergetdate function is not only used to display dates, it is also passed
to the function make_timestamp. This means users using another calendar type
other than Gregorian will generate incorrect timestamps which may be saved in
the DB or used to populate the date_selector and date_time_selector elements.
For example, when creating an assignment using another calendar type other
than Gregorian, the mod_form.php file calls $this->apply_admin_defaults()
which uses the function usergetmidnight to set the "Allow submissions from"
date to today's date and the "Due date" field to 7 days in the future. The
usergetmidnight function calls usergetdate which is then passed to
make_timestamp. Since the usergetdate function was using the calendar
type's timestamp_to_date_array function the date being passed to
make_timestamp was not in Gregorian. So, when using the hijri calendar the
year 1434 was being passed which was generating a large negative number as
the timestamp which was then used to populate the date fields.
1) Moved the calendar types location to a sub-folder in the calendar directory.
2) Removed/moved language strings.
3) Removed calendar types that should be downloaded as plugins.
4) Removed a Non-English language pack for the Gregorian calendar type that
should be downloaded separately.
5) Removed custom files responsible for checking for updates and uninstalling
calendar types, which should be done by core.
6) Removed JS from the calendar_month block as there is no non-JS alternative
provided and the JS written does not make use of the YUI library to ensure
multiple browser support.
7) Removed code from the base class responsible for creating timestamps that
are saved in the DB.
8) Added PHPDocs.
Note: In the original patch we are editing core functions responsible for saving
time in the database in the calendar base class. This is very dangerous, we do
not want to touch these functions as it could cause a complete fubar of the
database. There are places we are forcing the use of the gregorian calendar as
we are passing dates generated by the PHP date function, where as sometimes
we pass dates from usergetdate (which was being overwritten to return the
date specific to the calendar). We can not expect third party modules to
change the calendar type depending on the format they pass to these functions.
Fixes display issues with the filepicker dialogs that were
converted to M.core.dialogue.
Note: These dialogue use table based layouts and the table width is not
counted in the form that it sits in. I have changed the dialogues to have
a wider width but for really small screens this causes horizontal scrolling.
The only solution for that is to rewrite all the filepicker/filemanager dialogs
to use css for layout.
Items addressed
* Get rid of custom attribute srcNode
* Change extraClasses to a config only parameter.
* Change attribute fullscreen to a method.
* Restore the original window overflow value.
* Use setStyles instead of setStyle for performance.
* Tinymce end the zindex wars
* Prevent fullscreen dialogs in an iframe (tinymce managefiles plugin).
* tinymce: Cross browser fix for zindex on popups
* Use CSS for overflow changes (easier to keep track of the previous state).
* Fix Coding style for css changes
calendar panel.render() sets zIndex to 0, when calendar is used next to filepicker, it overlaps
zIndex should be set by css and not JS, and previously used removeAttr on panel breaks JS on ie8.
So solution is to render panel and then remove z-index from dom
The new version of the dateselector is causing JS to stop
working completely in a lot of forms, so I've disabled
temporarily the ofending call to allow other stuff to be
integrated and tested.
