Existing mod_hvp pluging has a renderer to let Moodle instances
alter styles, Javascript, semantics (fields in the editor) and
content: https://github.com/h5p/moodle-mod_hvp/blob/stable/renderer.php
The approach for core_h5p is exactly the same, to let people
to reuse their existing code.
Rename the string identifier to filetypesnotallowed, copy all the
existing translations in AMOS and deprecate the original string to be
eventually removed.
AMOS BEGIN
CPY [filetypesnotwhitelisted,core_form],[filetypesnotallowed,core_form]
AMOS END
The code has been using terms that were found exclusive and potentially
derogatory. Fixing the terms and making the variables and methods
consistent with the related admin settings.
The name of the placeholder has been found exclusive and potentially
derogatory. Also the name of variable that was used to populate the
placeholder value. That was not the intention.
If the allcountrycodes filter contains only invalid values, ignore the
whole filter setting and make get_list_of_countries() return the full
list of all known countries, rather than empty list.
The link class attribute is a leftover from 7258bf0b, which was mostly
removed in 3b2f691f. It no longer serves a purpose and interferes with
the element focus outline.
There were inconsistencies with the text shown on the submit button,
depending on the where the button was shown.
* Inline reply forum displayed general "Submit".
* Experimental nested discussion view reply form displayed "Post"
(post/core string) which acts as a noun in other contexts and cannot
be used as such in many non-English languages.
* Advanced reply form displayed "Post to forum".
The patch fixes this and starts to show "Post to forum" in all three
places consistently.
While working on this, two more issues were noticed and fixed:
* Inline reply textarea's title was hard-coded English "post" text.
Changed to "Message" to provide advisory information related to the
element.
* Buttons contained title attribute with the same value as the explicit
button text. This goes against accessibility guidelines.
When editing a user and checking the 'Delete picture' checkbox to delete
the old picture and uploading a new one at a time, the new one didn't appear
in the user profile. This happened due to the 'if/else' statement
in the 'core_user::update_picture()' method which allowed either to delete
the old picture or to upload a new one.
The fix removes the 'else' part of the 'if/else' statement to force
checking for a new uploaded picture no matter if a user checked
the 'Delete picture' checkbox or not.
Calls to core_get_course_contents can cause PHP warnings in the server
log if there are any URL instances in the course with sketchy URLs.
This is because url_export_contents incorrectly returns null instead
of an empty array if there is an error.
