People uses to edit the install.xml files manually, here and there. That
uses to come with small mistakes, like wrong white-space indentation,
some attributes out of order...
While none of them are critical, they add a lot of noise when somebody
is correctly editing a file with the XMLDB Editor because it, correctly,
overwrites the whole file and then diffs show a lot of unrelated changes.
So, this report will inform us about any file needing to be regenerated
because it has been manually edited (in a different way than the way
the editor has).
Note that the report is very basic, with minimal ouput, manually
generating the HTML, like the rest of the XMLDB Editor actions do. We
are not using renderers neither templates here.
Also note that it includes a commented line of code that, once
uncommented, enables the report to, also, fix the wrong files. Useful
for developers.
Significant string changes:
* pluginnamesummary,qtype_ddimageortext and
pluginnamesummary,qtype_ddmarker - Note about the question type not
being accessible to visually impaired users
* addresourceoractivity,core - Removing 'resource' as the new activity
chooser doesn't have resource types separated
Significant string changes:
* moodleorghubname,core_admin and
sitemustberegistered,message_airnotifier - 'Moodle.net' changed to
'Moodle'
* registration_help,core_admin and registermoochtips,core_hub - removed
erroneous 'access to Moodle.net our course sharing platform'
* trackingtype_help,mod_forum and formnotavailable,core_grading and
showgrades_help,core and rolewarning_help,core_rating -
'Administration block' changed to 'Actions menu or admin block',
'navigation block' changed to 'navigation drawer or block'
Significant string changes:
* importgroups_help,core_group - Correcting optional fieldnames
(removing picture, hidepicture and adding groupidnumber, groupingname
and enablemessaging)
* penaltyforeachincorrecttry_help,core_question - additional paragraph
about scoring logic
* resultdownloadready,tool_dataprivacy - wording corrected (no need to
go to a download page)
* auth_dbfielduser,auth_db - varchar data type requirement
The patch increases the maximum supported precision (total number of
digits) for numeric (decimal) fields to 38 digits (current limit on
Oracle and MSSQL).
Additionally, we add our own limit for the whole number part of numeric
fields so they are no longer than integer fields (20 digits). This is to
make it easier to eventually convert from one field type to another.
Note that PHP floats commonly support precision of roughly 15 digits
anyway.