Just methods where adding "static" to the declaration was enough, I
didn't do anything with providers that used $this.
Initially by search and replace. There were many mistakes which I
found mostly by running the PHPStorm inspection which searches for
$this usage in a static method. Later I used the PHPStorm "make static"
action which avoids the more obvious mistakes.
Bug: T332865
Change-Id: I47ed6692945607dfa5c139d42edbd934fa4f3a36
With PHPUnit 9, tests without @covers tags are considered risky and emit
warnings. Not having @covers is bad practice anyway, so use
@coversNothing instead to make the intention clear, and re-enable the
phpcs rule.
Also rewrite an assertion in ResourcesTest that was bothering me.
Bug: T243600
Change-Id: I6dd683f93b6b2faed5f107be2ca7860602277fbc
The name change happened some time ago, and I think its
about time to start using the name name!
(Done with a find and replace)
My personal motivation for doing this is that I have started
trying out vscode as an IDE for mediawiki development, and
right now it doesn't appear to handle php aliases very well
or at all.
Change-Id: I412235d91ae26e4c1c6a62e0dbb7e7cf3c5ed4a6
This changeset implements T89432 and related tickets and is based on exploration
done at the Prague Hackathon. The goal is to identify tests in MediaWiki core
that can be run without having to install & configure MediaWiki and its dependencies,
and provide a way to execute these tests via the standard phpunit entry point,
allowing for faster development and integration with existing tooling like IDEs.
The initial set of tests that met these criteria were identified using the work Amir did in
I88822667693d9e00ac3d4639c87bc24e5083e5e8. These tests were then moved into a new subdirectory
under phpunit/ and organized into a separate test suite. The environment for this suite
is set up via a PHPUnit bootstrap file without a custom entry point.
You can execute these tests by running:
$ vendor/bin/phpunit -d memory_limit=512M -c tests/phpunit/unit-tests.xml
Bug: T89432
Bug: T87781
Bug: T84948
Change-Id: Iad01033a0548afd4d2a6f2c1ef6fcc9debf72c0d
@covers does not make any sense for structure tests, which either
do not cover any PHP lines (they test things like configuration or
messages), or cover lines which cannot be determined at the time
of writing the tests (e.g. they cover all classes implementing a
certain interface). Requiring @coversNothing to be manually added
for all of them is a waste of developer time.
tests/phpunit/suite.xml has forceCoversAnnotation=true so removing
the annotations will not change test coverage, these files will
still be skipped.
Change-Id: I27cb58e92341b9b1a76f109701f5bc843adbaa9b
Password policy checks that fail and have `suggestChangeOnLogin` set to true will
prompt for a password change on login.
Below are some rules that apply to this setting in different scenarios:
- If only one policy fails and has `suggestChangeOnLogin = false`, a password change will
not be requested
- If more than one policy fails and one or more have `suggestChangeOnLogin` set to true`,
a password change will be requested
- If `forceChange` is present in any of the failing policies, `suggestChangeOnLogin` value
will be ignored and password change will be enforced
- if $wgInvalidPasswordReset is set to false `suggestChangeOnLogin` is ignored
IMPORTANT**
Before this patch, suggesting a password change was the default behavior (depending on
$wgInvalidPasswordReset), which means that the necessary changes to $wgPasswordPolicy
need to be in place before this patch is merged and gets to production.
Bug: T211621
Change-Id: I7a4a0a06273fa4e8bd0da3dac54cf5a1b78bb3fd
Follow-up to I28c31fc4ea.
Also improves what policy values are considered disabled, documents
how to extend core checks/flags and adds a structure test for it.
Bug: T118774
Change-Id: I66bf396e8e8a8c310a47ba337abe9070e7e83ff6
