generate_email_supportuser was not creating user which can
be used by messaging system. core_user::get_support_user()
should be used to get support_user record.
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.
Renamed the userdate/usergetdate functions in the calendar type to be more
descriptive and made them abstract to ensure developers implement this
functionality in their calendar type.
Also tidied up PHPDocs for these functions.
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.
This commit moves user agent related functionality out of several
core libraries and combines it into a more manageable class.
All core uses are converted and functions deprecated in favor
of the new class.
This commit moves user agent related functionality out of several
core libraries and combines it into a more manageable class.
All core uses are converted and functions deprecated in favor
of the new class.
Includes:
* no more hacky reloads, everything is written only once and kept until cache reset
* lang menu list is now cached in MUC
* both string and lang menu caches are compatible with local caches on cluster nodes
* config-dist.php cleanup
The improvements include:
* HTMLPurifier cache is stored in localcachedir
* allowobjectembed changes are not ignored any more
* the cache keys include revision and all options which makes
this suitable for local caches on cluster nodes
* unchanged test is replaced by "true" value which should
significantly improve performance
* removal of purge_all_caches() hack for directory recreation
* comments and coding style cleanup
