The joubel/core is a third-party library. A namespace has been added to
avoid collision with other plugins using it (such as mod_hvp).
That way, they will be able to have a different version without
side effects.
Take account of parent languages when requesting given library
translation. For example if we are currently using "de_kids" as the
current language, we need to recurse each language pack looking for
a matching H5P translation ("de_kids" -> "de_du" -> "de").
A new parameter has been added to the display method, to define whether
the edit button should be displayed or not.
The H5P activity will display this button (if the user has the required
permissions). However, it won't be displayed when previewing H5P in the
content bank.
The editor form is based on the code that Victor Deniz prepared
while he was working on the integration of the H5P editor into
Moodle. The original version of this file can be found in
MDL-67814.
It seems that the new phpcs3 checker is now controlling those
line comments that previously were ignored.
This commit just looks for all the cases and bulk-add
them when needed. The bash script (mac) used to add all them is:
while read -r line; do
arr=(${line//:/ })
if [[ -n ${arr[0]} ]] && [[ -n ${arr[1]} ]]; then
echo " file ${arr[0]}, line ${arr[1]}"
sed -i "${arr[1]}s/\$/\./" ${arr[0]}
fi
done < <(find . -name version.php | xargs ag --nomultiline '>(version|requires) *=.*//.*[^;\.]$')
- The mbstring extension is required since Moodle 3.9 onwards so
the upgrading steps have been removed because they are not
required any more.
- The pull-request for fixing some minor PHP7.4 problems has been
integrated so this patch is not required.
If a H5P content-type is disabled:
- The content bank won't display existing contents having it as a
main library.
- The content bank won't allow to create new contents using it.
Core and mod_hvp are using the same namespace for some H5P
libraries. This is causing some random errors.
In order to get the expected behaviour in Moodle core, this patch
prepends H5P libraries in order to guarantee they are loaded first.
Plugins using same libraries will need to use a different namespace
if they overlap and a different version of these libraries should
be used.
This applies the "whitelist" => "include" changes to all the core
phpunit_coverage_info occurrences, so core won't emit any deprecation
warning (see previous commit).
At the same time, modified a bunch of comments in coverage files
to be more readable/understandable.
Both assertContains() and assertNotContains() are deprecated in PHPUnit 8
for operations on strings. Also the optional case parameter is. All uses
must be changed to one of:
- assertStringContainsString()
- assertStringContainsStringIgnoringCase()
- assertStringNotContainsString()
- assertStringNotContainsStringIgnoringCase()
More info: https://github.com/sebastianbergmann/phpunit/issues/3422
Regexp to find all uses:
ag 'assert(Not)?Contains\('
All the setup/teardown/pre/post/conditions template methods
now are required to return void. This was warned with phpunit 7
and now is enforced.
At the same time, fix a few wrong function names,
provider data and param types, return statements...
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.
When the Moodle component is passed to the player, xAPI tracking
is enabled so, if the component implements required xAPI API methods
(for instance, mod_h5pactivity does), grades and responses are sent.
Adding this component to the embed code will help to add
the embed code from a mod_h5pactivity to any other place (such as label,
page or book), and being able to track the responses to the original
mod_h5pactivity.
Under parallel development, when something is worth being commented
in upgrade.txt notes, it will be applied to all the development branches
using the "earliest" one to be released. So, if something changes
in 3.10 (and also is applied to master), the upgrade.txt notes will
show 3.10 in both branches.
Of course, if something only goes to one dev branch (say master), then the
master version will be used in the notes (4.0 in this case).
version = 2021052500 release version
requires= 2021052500 same than version
Why 20210525? (25th May 2021) ?
Because master is going to be Moodle 4.0, to be released
on November 2021. And, until then, we are going to have
a couple of "intermediate" releases:
- Moodle 3.10 to be released 9th November 2020. (2020110900)
This version will be using versions from today to 2020110900
(once it's released the YYYYMMDD part stops advancing).
- Moodle 3.11 to be released 10th May 2021. (2021051000)
This version will be using versions from 3.10 release to 2021051000
(once it's released the YYYYMMDD part stops advancing).
That means that all versions from today to 2021051000 are going
to be used by those 2 "intermediate" releases (3.10 and 3.11).
And we cannot use them in master, because it's forbidden to have
any overlapping of versions between branches (or different upgrade
paths will fail).
So, get that 2021051000, let's add it a couple of weeks to cover
the on-sync period (or a 2 weeks delay max!) and, the first version
that master can "own" in exclusive (without any overlap) is, exactly,
25th May 2021, hence our 20210525.
