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.
- Fields added to format_legacy as default course format options;
- Upgrade script copies fields values from table course to course_format_options;
- Fields removed from table course;
- Fields removed from edit course form;
- Since front-page course has a 'numsections' setting, format_site defines it as it's option;
- Removed accessing those fields in core code unless we know that format supports them and in this
case instead of $course = $DB->get_record('course'); we use:
$course = course_get_format($courseorid)->get_course(); This way all format-specific options
are added to the $course object
- Course format may define additional fields (format options) to store for course and each section
- Edit course form allows to edit format-specific options and refreshes their list on format change
- Course format may provide it's own form for editing a section
- Default form for editing section allows to edit all format-specific fields
- Class section_info refactored, it defines magic methods such as __get() to access basic section
information and format-specific options (retrieved only on the first request)
- format_base::update_course_format_options() allows to watch pre-update state of the course,
format_legacy automatically copies the options with the same names between formats
1. This used to use a complex legacy system which was buggy.
2. It now relies on a new mod/...:addinstance capability for each module.
3. All the legacy code has been stripped out.
4. Old restriction data is upgraded by creating the necessary permission
overrides. Similarly, when old backups are restored, the old settings
are converted to be overrides.
5. The required addinstance capabilities will be added as a separate
commit.
6. There is a developer debug warning about modules that are missing the
addinstance capability, unless they are MOD_ARCHETYPE_SYSTEM mods.
This is useful for modules which are created by the system and are not supposed to be created by users. There are various reasons for doing this in third-party modules.
