PostgreSQL 9.1 allows hex formating for binary which is handled better
by pg_query_params().
Getting bytea isn't required on connection, it can be used as pg_field_type()
when binary needs to be checked.
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.
component, filearea and itemid are now optional parameters.
In some contexts those parameteres are not necessary because is not
required to do a file rewrite via file_rewrite_pluginfile_urls
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.
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.
Instead of having the stricter configuration for all files, use
the less strict default config and switch to the stricter config
for building AMD modules.
This means that the eslint commandline/editor inspections will work
better for all files and not generate false positives when using editor
integrations. But since grunt is required to build AMD modules we still
get the stricter checking for those files on build.
Because we don't have the entire YUI rollup, we can't apply some of the
rules safely, so we ignore some rules.
At this point I am not 100% certain this configuration is robust enough,
to deal with the lack fo rollup knowledge although its a good sign that
there are no errors on our entire yui codebase.
I have spent quite a lot of time working through the current list of
eslint options and configuring them for Moodle style and I think this is
a very good basis to start us at (as well as taking some of out jshint
options out with https://www.npmjs.com/package/polyjuice ). Thanks to
Andrew Nicols, Mark Johnson and Frédéric Massart for some refinements.
With this configuration the grunt build will fail if errors are present
in the js (though you can of course tell jshint to ignore some errors,
as I have done in admin/tool/lp/amd/src/competency_rule_points.js and
defining the Y global in lib/amd/src/yui.js ).
The grunt task will not report warnings by default, but a new
--show-lint-warnings flag will help achieve that. Editor
integrations/stanadalone eslint tool will surely be a better way of
getting eslint errors rather than using the grunt task.
dirname() is a slow function compared with __DIR__ and using
'/../'. Moodle has a large number of legacy files that are included
each time a page loads and is not able to use an autoloader as it is
functional code. This allows those required includes to perform as
best as possible in this situation.
