There is at least one LDAP server (Sun Directory Server) that doesn't
support Paged Results extension, even if it supports LDAP version 3. So
checking just for LDAP version is not enough.
If possible, we check the supportedControl attribute of the LDAP rootDSE
and see if the paged results control is available. This needs an LDAP
connection, which might not be possible to establish before we configure
some essential LDAP settings (server, bind user, password, etc.). Thus
we try to establish the connection and check the supportedControl
attribute. But if we fail, we perform only basic checks that are less
accurate and err on the side of cautiousness.
This was is pre-loading some modules which are not used in boost:
* Block docking
* Popup Help
The other pre-loaded requirements were used for YUI dialogues and
modals. With time we are moving away from these, so rather than
'pre-loading' we can let the yui loader do its job.
1) Some previous deprecations are removed to reduce the amount of
code sent to the client
2) Other very-old functions are also sent to final deprecation
This is more agressive than our standard deprecation process, but with
the nature of this old js it seems the best way forward to reduce the
amount of obsolete js sent to clients.
Fixes bug where the resource module loads metadata for all files while
building course modinfo, even though it only needs the first file.
(This causes problems if you have ~10k files.)
In getValidationScript function variable $element can be an array or object.
Function attempt get non-existing attributes.
To avoid this we should check before accessing.
noreplyaddress should be a valid address, else
it will not be saved. For behat we don't send
email, so set it to noreply@example.com, to
avoid failing validation on localhost
It was discovered by unit tests that the return value is not a real
boolean as was intuitively expected and documented. To avoid potential
issues with the truthyness in the future, we explicitly cast the return
value to boolean now.
The patch adds validation for the noreplyaddress setting variable, for
the explicit $replyto parameter and for the sender's email. In case of
misconfigured noreplyaddress setting, it falls back to the default
noreply address value. In case of invalid email in the user's record,
the email is not sent.
The patch also adds unit test for the value returned by the function
generate_email_processing_address() so that it can be considered as a
valid email, too.
This is supposed to significantly minimise the risk of exploiting the
vulnerability in PHPMailer's Sender field.
