The optional parameters of assertEquals() and assertNotEquals()
are deprecated in PHPUnit 8 (to be removed in PHPUnit 9):
- delta => use assertEqualsWithDelta()
- canonicalize => use assertEqualsCanonicalizing()
- ignoreCase => use assertEqualsIgnoringCase
- maxDepth => removed without replacement.
More info @ https://github.com/sebastianbergmann/phpunit/issues/3341
Initial search done with:
ag 'assert(Not)?Equals\(.*,.*,' --php
Then, running tests and fixing remaining cases.
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)
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...
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 commented out because auto-hidden toasts currently call `hide()`
and trigger the `bs.toast.hide` event immediately, and _then_ apply the
autohide delay.
Since we automatically add M.util.pending_js calls when we _start_ to
hide, and resolve them when the hide _finishes_, this means that we do:
- addToast called
- trigger `bs.toast.show` event
- add to pending_js
- [pending_js queue not empty - behat waits]
- message is shown in UI
- `hide()` called
- trigger `bs.toast.hide` event
- add to pending_js
- [pending_js queue not empty - behat waits]
- start autohide delay
- [pending_js queue not empty - behat waits]
- [pending_js queue not empty - behat waits]
- [pending_js queue not empty - behat waits]
- [pending_js queue not empty - behat waits]
- end autohide delay
- remove message (no longer present in DOM)
- trigger `bs.toast.hidden` event
- resolve pending_js
- [pending_js queue empty - behat stops waiting]
- Behat runs next step: And I should see "1 enrolled users"
-- Step fails beacuse the message has been shown, and has then been removed
The conversation should have been:
- addToast called
- trigger `bs.toast.show` event
- add to pending_js
- [pending_js queue not empty - behat waits]
- message is shown in UI
- start autohide delay
- trigger `bs.toast.shown` event
- resolve pending_js
- [pending_js queue empty - behat stops waiting]
- Behat runs next step: And I should see "1 enrolled users"
-- Step passes
- autohide delay ends and calls `hide()`
- trigger bs.toast.hide event
- add to pending_js
- [behat waits]
- end autohide delay
- remove message (no longer present in DOM)
- trigger `bs.toast.hidden` event
- resolve pending_js
- [pending_js queue empty - behat stops waiting]
- Behat run continues
See MDL-67386 for futher information.
This change enables the gherkinlint rule to require a new line at the
end of the file. This change is in keeping with existing Moodle coding
style guidelines.
This class was only used by the database enrolment plugin settings and
was replaced by admin_settings_coursecat_select. Also, this class is in
a plugin which we do not expect to be extended and therefore it can be
simply removed without going through the deprecation process.
We should use admin_settings_coursecat_select instead of
enrol_database_admin_setting_category as the second class is only
being used by the database enrolment plugin settings and can be
removed after this change.
With that provider we'll be explicitly checking that any
pagesize and subcontexts search is returning results consistently
so the internal paging/servercontrols work as expected.
Starting with php74 the following functions are deprecated:
- ldap_control_paged_result()
- ldap_control_paged_result_response()
Starting with php73, ldap servercontrols were included. One of those
servercontrols, LDAP_CONTROL_PAGEDRESULTS, is the one in charge of
controlling paged results.
So, we are going to add some conditional code here:
1) if php < 7.3, use old paged result functions.
2) if php >= 7.3, switch to LDAP_CONTROL_PAGEDRESULTS servercontrol.
With a TODO about removing 1) in Moodle 4.1, once php73 becomes required.
There are various places where it's not guaranteed that the
variable being used is array, and instead, can be null, bool, int...
We need to check that because php74 warns about it.
Where possible we have used the coalesce operator as
replacement for isset() ternary operations.
This just deletes all the upgrade steps previous to 3.5.0. Some
small adjustments, like tweaking globals can also be applied
when needed.
Also includes an upgrade step to prevent upgrading from any
version < 2018051700 (v3.5.0) as anti-cheating measure.
Previous commits have removed/deprecated all the upgradelib functions
not used anymore in codebase. Deletion has been documented in corresponding
upgrade.txt files:
- upgrade_fix_block_instance_configuration()
- upgrade_theme_is_from_family(), upgrade_find_theme_location()
and linkcoursesectionsupgradescriptwasrun setting
- upgrade_block_positions
- upgrade_fix_config_auth_plugin_names()
and upgrade_fix_config_auth_plugin_defaults()
- format_xxx_upgrade_remove_numsections(), format_xxx_upgrade_hide_extra_sections()
and format_xxx_upgrade_add_empty_sections()
- filter_mathjaxloader_upgrade_cdn_cloudflare()
and filter_mathjaxloader_upgrade_mathjaxconfig_equal()
- get_assignments_with_rescaled_null_grades()
These have been kept because continue being used by restore:
- \core\task\refresh_mod_calendar_events_task
On the course's Participants page, when manually enrolling users
the AJAX call might get excesively slow, due to the treatment
of the perpage parameter as a string, which gets concatenated with the
number 1 (perpage: parseInt(perpage) + 1) instead of performing a
numerical addition.
If there are for example 1500+ users on the site, the method
core_enrol_get_potential_users will be executed with a value of 15001
for the perpage parameter, rendering painfully slow.
