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
Migrate all callers of Hooks::run() to use the new
HookContainer/HookRunner system.
General principles:
* Use DI if it is already used. We're not changing the way state is
managed in this patch.
* HookContainer is always injected, not HookRunner. HookContainer
is a service, it's a more generic interface, it is the only
thing that provides isRegistered() which is needed in some cases,
and a HookRunner can be efficiently constructed from it
(confirmed by benchmark). Because HookContainer is needed
for object construction, it is also needed by all factories.
* "Ask your friendly local base class". Big hierarchies like
SpecialPage and ApiBase have getHookContainer() and getHookRunner()
methods in the base class, and classes that extend that base class
are not expected to know or care where the base class gets its
HookContainer from.
* ProtectedHookAccessorTrait provides protected getHookContainer() and
getHookRunner() methods, getting them from the global service
container. The point of this is to ease migration to DI by ensuring
that call sites ask their local friendly base class rather than
getting a HookRunner from the service container directly.
* Private $this->hookRunner. In some smaller classes where accessor
methods did not seem warranted, there is a private HookRunner property
which is accessed directly. Very rarely (two cases), there is a
protected property, for consistency with code that conventionally
assumes protected=private, but in cases where the class might actually
be overridden, a protected accessor is preferred over a protected
property.
* The last resort: Hooks::runner(). Mostly for static, file-scope and
global code. In a few cases it was used for objects with broken
construction schemes, out of horror or laziness.
Constructors with new required arguments:
* AuthManager
* BadFileLookup
* BlockManager
* ClassicInterwikiLookup
* ContentHandlerFactory
* ContentSecurityPolicy
* DefaultOptionsManager
* DerivedPageDataUpdater
* FullSearchResultWidget
* HtmlCacheUpdater
* LanguageFactory
* LanguageNameUtils
* LinkRenderer
* LinkRendererFactory
* LocalisationCache
* MagicWordFactory
* MessageCache
* NamespaceInfo
* PageEditStash
* PageHandlerFactory
* PageUpdater
* ParserFactory
* PermissionManager
* RevisionStore
* RevisionStoreFactory
* SearchEngineConfig
* SearchEngineFactory
* SearchFormWidget
* SearchNearMatcher
* SessionBackend
* SpecialPageFactory
* UserNameUtils
* UserOptionsManager
* WatchedItemQueryService
* WatchedItemStore
Constructors with new optional arguments:
* DefaultPreferencesFactory
* Language
* LinkHolderArray
* MovePage
* Parser
* ParserCache
* PasswordReset
* Router
setHookContainer() now required after construction:
* AuthenticationProvider
* ResourceLoaderModule
* SearchEngine
Change-Id: Id442b0dbe43aba84bd5cf801d86dedc768b082c7
Going directly to 8 is too much pain.
Depends-On: Iafcea151389663d79e70ad6ab3741ce8b2e25cac
Bug: T192167
Change-Id: I77ea560f4a5344bd1c356ecc3e7857968ad829b8
Instead of requiring every extension that wants to add unit tests to
copy the exact same boilerplate over and over, let's just automatically
discover them. We now have an extension registry, so we know exactly
which extensions are loaded (this won't work for extensions not being
loaded through extension.json).
For each extension, we check to see if the directory "tests/phpunit/"
exists, and if it does, add those unit tests. If there is a
`UnitTestsList` subscriber already set, PHPUnit will automatically
de-duplicate test cases so we won't be running anything twice.
Change-Id: I6ec654ef2d8ee3630b121b1277b4ee21ba0b6cd4
Since the match can be case-insensitive (apparently), this meant
ExtensionsTestSuite.php ("extensions") wasn't being validated either.
Bug: T127238
Change-Id: I679de924ebeb45150004783ce404fac92af026a7
The UnitTestsList hook can now be used to add entire directories of
tests, à la phpunit.xml's <directory> tag. The test suite is built by
recursively scanning the directory for any files ending in "Test.php".
TODO:
* Update online hook documentation.
* Generate and autoload a classmap for scanned directories.
Bug: 70630
Change-Id: I3089372f9d7c645e16ff0984a959f982a3bc639f
