The embed section has been removed in order to simplify this screen.
It was added to make easier include content coming from h5p.org but,
as soon users won't be able to use it, it makes no sense.
Users will still be able to use the "HTML" button to paste the
embed code.
h5p.org has to be removed as default value for the allowedsources in
the "Display H5P" filter because H5P is going to close it down completely
so that only the author can see the test content.
The third-party library H5P has some references to instead of Moodle's.
That implies that the information is not saved to backends and other issues,
so only the Moodle one should be used by core (core should be free from and always use .).
When searching for the user by a case-insensitive field (email address
is the only one supported now), the performance may be very poor as the
DB cannot use the index due to the LOWER() operation and the full
sequential scan of all the user records is performed. On some DBs such
as MySQL, this can be significantly improved by pre-filtering the users
with accent-insensitive search.
So we first perform accent-insensitive search for potential candidates
in a subselect, which can use the index. Only then we perform the
additional accent-sensitive search on this limited set or records.
When searching for other users with the same email address, we perform
the case-insensitive and accent-sensitive search. That may be expensive
as some DBs such as MySQL cannot use the index in that case. Instead,
sequential scan of all the user records is performed and the comparison
uses the LOWER function to filter the matching records. This leads to
significant performance heavy queries which in turn represent a surface
for DoS attacks.
For that reason, we first perform accent-insensitive search for
potential candidates in a subselect, which can use the index. Only then
we perform the additional accent-sensitive search on this limited set or
records.
When searching for the user matching the given email address, we perform
the case-insensitive and accent-sensitive search. That may be expensive
as some DBs such as MySQL cannot use the index in that case. Instead,
sequential scan of all the user records is performed and the comparison
uses the LOWER function to filter the matching records. This leads to
significant performance heavy queries which in turn represent a surface
for DoS attacks.
For that reason, we first perform accent-insensitive search for
potential candidates, which can use the index. Only then we perform the
additional accent-sensitive search on this limited set or records.
