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
The wfDeprecated is called directly from __get/__set/__isset which needs
only a 2, not 3. That means the message is one caller of.
Change-Id: Ia29fb0a07841f69a4d8b95431f0915df9793c340
The cost of creating closures adds up, so avoid it if we can be using
method names instead.
Bug: T297236
Change-Id: Ifb78d5f310fe45db58fd450c9db3c7af295ae399
DeprecationHelper currently breaks dynamic properties
on phpunit mocks. This happens because phpunit starts
mocking the magic methods if they're explicitly defined.
By default, magic methods and up doing nothing, but
if proxying to original methods is enabled, magic methods
are called like regular methods, regarless of whether
property exists or not. With this patch we can workaround
this issue, and create mocks for classes with deprecations.
Needed-By: I4297aea3489bb66c98c664da2332584c27793bfa
Change-Id: Id60a7751ece05669eced6eddd3216da7149411c7
Setting and getting dynamic class properties (e.g. $parser->my_fancy_prop)
is a horrific practice that we should get rid of, but it is still
used. DeprecationHelper right now can not be used on classes
where this practice is used by extensions. Introduce methods
to allow or deprecate this practice.
Change-Id: Ib378bef792dd31be155f186f1a4965a05004a37c
The main goal is to simplify the construction of the LanguageConverter and
avoid using constructors for derived classes.
In order to hard-deprecate removed property, DeprecationHelper::deprecatePublicPropertyFallback
was introduced.
Bug: T253834
Change-Id: Ib167982e4e872cfdf0fbcb78b7ca597f5ac8d60a
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
1. into class Parser
2. into class LinkHoderArray
3. into class DefaultPreferencesFactory
Add more tests for DefaultPreferencesFactory:
1. testVariantsSupport verifies that converter with variants is used correctly.
2. Test testUserGroupMemberships verifies that membership is used correctly
Bug: T243320, T243321, T243317
Change-Id: I1e5c37e18332d0d32391c74c06e3d84862e48df8
To avoid cases like: facddc4 and Ifaf6ab0d36bc02bd170, make sure the
value of the mediawiki version must be a string (e.g. '1.33') or a
boolean (e.g. `false`).
For some reason, typos can slip through for this value to be a float.
Let's safe guard for future cases like this.
Change-Id: I52bdf94c957bda67548a937d51649e925195f926
The method for getting the declaring class name was not used when
printing the class name, and was incorrect anyway. Use reflection
when on the error path to ensure the correct class name is used.
Change-Id: Ic9cd4319535d5ab877a0563e0433371e1025d985
Tests should not interfere with each other; disabled deprecation
warnings should be disabled for a single test case only.
Bug: T191960
Change-Id: Ic9b892bc83ba6d71c1077df0d93c95dde36988bb
