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\('
While this is not strictly required, because removal will
happen in PHPUnit 9.0, we are already getting rid of all
uses in core.
From release notes:https://phpunit.de/announcements/phpunit-8.html
The annotations `@expectedException`, `@expectedExceptionCode`,
`@expectedExceptionMessage`, and `@expectedExceptionMessageRegExp`
are now deprecated.
Using these annotations will trigger a deprecation warning
in PHPUnit 8 and in PHPUnit 9 these annotations will be removed.
Also, all uses of expectExceptionMessageRegExp() has been moved
to expectExceptionMessageMatches(). See https://github.com/sebastianbergmann/phpunit/issues/3957
TODO: Various weirdness found while doing the changes with these tests:
- vendor/bin/phpunit lib/tests/exporter_test.php (created MDL-69700)
- vendor/bin/phpunit competency/tests/external_test.php (same issue than prev one)
- vendor/bin/phpunit question/engine/tests/questionengine_test.php (created MDL-69624)
- vendor/bin/phpunit lib/tests/event_test.php (created MDL-69688)
While this is not strictly required, because removal will
happen in PHPUnit 9.0, we are already getting rid of all
uses in core.
From release notes:https://phpunit.de/announcements/phpunit-8.html
assertArraySubset() is deprecated and will be removed in PHPUnit 9.
While this is not strictly required, because removal will
happen in PHPUnit 9.0, we are already getting rid of all
uses in core.
From release notes:https://phpunit.de/announcements/phpunit-8.html
assertInternalType() is deprecated and will be removed in
PHPUnit 9. Refactor your test to use assertIsArray(), assertIsBool(),
assertIsFloat(), assertIsInt(), assertIsNumeric(), assertIsObject(),
assertIsResource(), assertIsString(), assertIsScalar(),
assertIsCallable(), or assertIsIterable() instead.
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...
Pass current user object to post builder as argument, so that the permission to view timed post
will check with current user, who is viewing the posts instead of user who made that post.
There were inconsistencies with the text shown on the submit button,
depending on the where the button was shown.
* Inline reply forum displayed general "Submit".
* Experimental nested discussion view reply form displayed "Post"
(post/core string) which acts as a noun in other contexts and cannot
be used as such in many non-English languages.
* Advanced reply form displayed "Post to forum".
The patch fixes this and starts to show "Post to forum" in all three
places consistently.
While working on this, two more issues were noticed and fixed:
* Inline reply textarea's title was hard-coded English "post" text.
Changed to "Message" to provide advisory information related to the
element.
* Buttons contained title attribute with the same value as the explicit
button text. This goes against accessibility guidelines.
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.
This is to further improve the performance of searching of posts related
to the given user. Once both userid and privatereplyto are indexed, the
query planner can use the merged index to search for posts records.
The idea here is to replace the existing LEFT JOINs and
OR / IS NOT NULL conditions with INNER JOINs and ANDs. So we gather the
discussions data from all three areas in individual queries, make their
UNION. The GROUP BY was present before and maybe it is not even needed
any more (due to how UNION works) but it should not hurt to keep it.
This leads to significantly improved performance.
The method get_grading_manager() is called in the file so make sure the
library is loaded. Without it, the forum's privacy provider unit test
ended with error.
Not directly related to the issue, but noticed while working on it.
The exists/contains steps of behat are case-sensitive, in the other
side, depending of the OS and locales, time functions are not 100%
consistent. See https://bugs.php.net/bug.php?id=76378 for example.
So only solutions are:
1) Create a specific new step performing the checks case insensitively.
2) Avoid making AM / PM part of the checks.
Here we have opted by the 2nd approach, it's not critical part to check.
Applying filters on an activity module description when using it as a
new calendar event's description is bad m'kay? We need to store the raw
text and apply the filters only when we actually display the text. That
way, filters (such as multi-language content) may actually fully work
and we do not initialise the theme and output machinery.
Additionally, we need to explicitly set the format of the description
text to HTML (because we have converted it to it already). Otherwise it
defaults to the current user's preferred editor format.
This is still a pragmatic hot-fix solution. The proper solution would be
to pass the raw text, format and embedded files.
