* Use clean_param() for name and description when displaying the tool type.
Basically in the following functions:
- serialise_tool_type()
- lti_get_configured_types()
* Changed name and description's type from PARAM_TEXT to PARAM_RAW
in tool update parameters.
* Changed name and description's type from PARAM_TEXT to PARAM_RAW
in mod_lti_external::tool_type_return_structure()
The changes in this commit should not be problematic, just:
- different whitespace.
- some docs.
- 1 variable to camelCase.
And then, less trivial, but safe enough IMO:
- a change to camelCase some identifiers and their calculation.
useredit_update_picture as moved to user_update_picture
as it's more general. It was also moved to user/lib.php
so it can be used by both webservices and edit without more include files.
Presently it is either unreliable, or not possible to change
the username of a user created with an authentication plugin.
In some cases it is even hard coded to fail. Ideally we would
sync the username, and the issue MDL-21928 exists to address
that. However, in the mean time we should not allow the
username of an external user to be modified.
The original issue here was that each loop of the named values did not
check for prototypal properties. As a result, if there were input fields
with names such as 'sort', 'valueOf', 'constructor', etc. these would
return their prototypal functions instead of a falsy value, and be treated
as though they are array - hence the 'Cannot push to Function' type error.
Following on from this I discovered that the data stores were being created
as arrays, but used as objects. This can also cause issues with some form
input names -- e.g. if they are numeric.
These two issues were resolved together by correctly storing them in
objects, and checking that those objects had real properties
(hasOwnProperty). This itself has to use the prototypal function to cater
for the potential of a field name called 'hasOwnProperty'.
I also found that the instance value stores were being initialised in the
prototype (and therefore shared), which meant that there were numerous
issues if two forms were present on the same page, or one form replaced an
existing one (e.g. forms initialised in JS).
In addition, it also became apparant that several values were being used
outside of scope, or in the wrong scope. This caused further issues when
creating multiple forms on a page.
