The idea is that all formatters that need the user language or
other request specific context should be instantiated by
FormatterFactory.
Change-Id: I8334cc89dcf0f293298b82e004116be50a90f0d1
Looks like this class and its corresponding services have been
used since inception. Let's get rid of it.
Change-Id: If427fb705bb86f019d24b6073f44af811dc1f13f
Currently, we have two services: ReadOnlyMode and
ConfiguredReadOnlyMode. The former takes the latter and can easily
support every functionality of CRO. I added methods to support that
functionality (the current class is quite small so it's not adding a lot
more to a monster class) and basically fully deprecate the service
itself to improve developer experience.
It is only called in two extensions in production with straightforward
fix so I directly went with hard-deprecation.
Bug: T343917
Depends-On: Icec0ad3f30c471b428efe80dfb9129f55a351194
Change-Id: I421fd5c8fee7af41c059419c2bbc85b8dccc04ed
Initally used a new sniff with autofix (T333745),
but some provide are defined non-static in TestBase class
and need more work to make them static in a compatible way
Bug: T332865
Change-Id: I889d33424f0c01fb26f2d86f8d4fc3de3e568843
$wgHooks should be treated like a regular setting, which cannot be
manipulated after bootstrapping is complete. This will allow us to
greatly simplify the logic in HookContainer.
Replacing $wgHooks with a fake array after bootstrapping allows us to
detect any remaining live access to $wgHooks without breaking
functionality.
The plan is to have the fake array emit deprecation warnings in the 1.40
release, and make it throw exceptions in later releases.
See Iddcb760cf8961316d6527e81b9aa968657d8354c for the deprecation
warnings.
Bug: T331602
Change-Id: I0ebba9a29f81b0d86ad8fd84d478fb244f9e9c15
Subclasses of Maintenance that can function without database access can
now override canExecuteWithoutLocalSettings to return true.
This is useful for scripts that need to be able to run before or without
installing MediaWiki.
When no config file is present, the storage backend will be disabled.
Any attempt to access the database will result in an error.
NOTE: This makes MediaWikiServices::disableBackendServices() more
comprehensive, to avoid premature failures during service
construction. This change makes it necessary to adjust how the
installer manages service overrides.
The CLI installer is covered by CI, I tested the web installer
manually.
Change-Id: Ie84010c80f32cbdfd34aff9dde1bfde1ed531793
createMock() does the same, but is much easier to read.
A small difference is that some of the replacements made in this
patch didn't use disableOriginalConstructor() before. In case this
was relevant we should see the respective test fail. If not we can
save some CPU cycles and skip these constructors.
Change-Id: Ib98fb06e0fe753b7a53cb087a47e1159515a8ad5
HookContainer::salvage() expects to be called immediately after the
object is constructed, and I enforced this expectation by asserting that
$this->handlersByName is empty.
However, MediaWikiServices::resetGlobalInstance() calls
HookContainer::run() in between construction and salvage(). The effect
is that the assertion is hit if any hooks were executed using the old
HookContainer.
So, call onMediaWikiServices() using the old pre-reset HookContainer,
instead of using a partially-constructed HookContainer for this purpose.
Pass the new MediaWikiServices instance as the argument, since that is
the thing that the hook is configuring.
Bug: T263925
Change-Id: I2b462d82c82314b11563a5ba1f02c6fb6d29e608
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
Done with `composer fix` and suppressing the rest (i.e. sniffs for
global variables, which for core should be suppressed anyway).
Additionally, add `-p` to `phpcbf`, as otherwise it just seems stuck.
Change-Id: Ide8d6cdd083655891b6d654e78440fbda81ab2bc
Remove unneeded handling of an optional parameter; private method, none
of the callers provide the parameter, so just drop it
Change-Id: I8e346f7f0ae66bc7d40445ac64f1b1b5dff2d76c
Done automatically using the master version of MW codesniffer and
running composer fix.
Bug: T192167
Change-Id: If6b40f515fde32ab5eff074a90e821c30c791827
assertSame() is guaranteed to not do any type conversion. This can be
critical when acciden tially comparing, for example, 0 to 0.0.
Change-Id: Iffcc9bda69573623ba14af655dcd697d0fcce525
The \MediaWikiServicesTest::provideGetService() PHPUnit data provider
method uses the ReflectionType::__toString() method to obtain the
return type of service instantiator callables as a string.
In PHP 7.4, calling this method generates an E_DEPRECATED notice.
The solution is to use ReflectionType::getName() instead, available
since PHP 7.1.[1]
This patch updates the method to use ReflectionType::getName()
if it is available, and fall back to ReflectionType::__toString()
otherwise.
---
[1] https://github.com/php/php-src/blob/php-7.4.0RC1/UPGRADING#L395
Bug: T233012
Change-Id: I69b97f75795e6c4e005bf1a23fb798f7e52da2fd
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
This code doesn’t use any MediaWiki-specific code, so rename
MediaWiki\Services to Wikimedia\Services and move it below libs/. (Of
course, this does not apply to the MediaWikiServices subclass.)
Class aliases are added to retain backwards compatibity for now.
Bug: T211608
Change-Id: Ic14ea28ef21c359695b309d4293dbaaf5deedc09
Adding everything at the end makes the list arbitrarily ordered, and
also invites lots of merge conflicts as new things are added.
Change-Id: I58bcca4fa79140f5d5f2f6ef447e67035cc37aae
Instead of having basically every caller do:
$pf = new PasswordFactory();
$pf->init( RequestContext::getMain()->getConfig() );
Just create a single PasswordFactory via MediaWikiServices and pass that
around. Things that want to use their own config can still pass settings
via the new constructor.
This will eventually let us remove the init() function, removing the
only hard dependency upon MediaWiki, to make it easier to librarize
(T89742).
Change-Id: I0fc7520dc023b11a7fa66083eff7b88ebfe49c7b
Static members of MagicWord have been removed.
Static methods are soft-deprecated and forward to the factory. They
will be hard-deprecated when all callers are removed from core.
MagicWord::clearCache() has been removed. Instead, call
resetServiceForTesting( 'MagicWordFactory' ) on your MediaWikiServices
object.
Change-Id: Ie061fe90f9b9eca0cbf7e8199d9ca325c464867a
Bug: T200247
This, for now, has the focus for holding metadata of each
configuration option inside of MediaWiki (both extensions and core).
It's very close to the Config interface and friends, and uses these
implementations to retrieve the actual value of the
configuration option.
The goal with this change is to implement a basic architecture to
allow to display the values of the curent configuration of the MediaWiki
installation on-wiki (e.g. on a special page). It also provides a
central point, where the currently known options can be fetched
from.
The long-term goal, of course, would be to get a web interface to really
configure the MediaWiki installation. But, this is more like a dream,
then a plan (from the point of view of this commit).
Next steps would be:
* Enable ExtensionRegistry to "register" the configuration options of
extensions, so they're available in the repo (done).
* Find a good way to get mediawiki/core configurations into this repo
* Work out an overall architecture to display the different possible
values. (I think about something like different formatters for types).
Change-Id: I9419508eaa85ffc55520db7f33b3e9530fc99f00
provideGetters is now automatically populated using the
provideGetService method so we don't need to actually add
the service there
Change-Id: I07e8f54e5c4aa7ff22d02312bf51ac8d1cc4b5c2
This allows CommentStore to be added to MediaWikiServices
without the need of an aditional Factory.
This change includes a compatability layer to allow the behaviour
from 1.30 to continue to be used while deprecated.
CommentStore::newKey has been deprecated.
Keys are now passed into the public methods of CommentStore
where needed.
The following CommentStore methods have had their signatures changed
to introduced a $key parameter, but when used in conjunction with
CommentStore::newKey behaviour will remain unchanged:
* CommentStore::getFields
* CommentStore::getJoin
* CommentStore::getComment
* CommentStore::getCommentLegacy
* CommentStore::insert
* CommentStore::insertWithTemplate
Change-Id: I3abb62a5cfb0dcd456da9f4eb35583476ae41cfb
