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
Follows-up d4045035b0.
This class was added to the MediaWiki\Special namespace, contrary to the
plan in T166010 which reserves that namespace for core special pages.
Instead, use MediaWiki\SpecialPage, following the directory in which it
is located.
Also, fix two bugs which prevented the introduction of a namespaced
class alias.
Bug: T166010
Change-Id: I6e31340aaae32a89beb7e45b79d76a7fea9808d2
Done automatically using the master version of MW codesniffer and
running composer fix.
Bug: T192167
Change-Id: If6b40f515fde32ab5eff074a90e821c30c791827
Now that the ObjectFactory library supports object creation with
services (T222409), the special page factory can use the object
factory to create special pages based off a spec, allowing the
creation of special pages that need services injected.
The object factory now also handles constructing from class name
and from callable.
This also deprecates providing the special page list with an
instance of SpecialPage, which hasn't been necessary since
r15031.
Bug: T222388
Change-Id: Iabb78ce5c98cfb3b586644be35d984871cb750cb
Calling SpecialPageFactory methods statically is now soft-deprecated.
SpecialPageFactory::resetList() is a no-op, and I changed tests
in core to use overrideMwServices() instead.
Methods that fell back to $wgUser now require a User object being passed.
Depends-On: Ie1f80315871085b9fd4763a265b588849d94414d
Change-Id: Id8a92d57743f790b7d8c377c033cef38d1bb24de
This changes behavior in some tests by making them set $wgLanguageCode
as well as $wgContLang, but that seems like a good thing.
Bug: T200246
Change-Id: I936888f46ff9fefe2707efba837e2ce3a7ca5e3f
If the special page object was already created for the request, there's
no need to create the object again. Save the created result (object, null)
in a global static array and return the value if the realName was already
created.
Bug: T123995
Change-Id: I70bf0e93e45f4b0597deaef717f5eb87c66f0a71
* Since Ic917c7d8/I7420b9ec, SpecialPageFactory doesn't properly cache
SpecialPageFactory::$list.
* SpecialPageFactory::resetList() has never really worked right, it
loses all the core special pages.
* SpecialPageFactory::getAliasListObject() could be called recursively
from a SpecialPage_initList hook. There's no particular reason to fail
it, just allow the original call to override the result of the
recursive one and hope it works.
Change-Id: I7adb346eab00d5849d087ddff75230a35be3ee8f
- Added newline at end of file
- Removed double spaces/newlines
- Added space after if/function and parentheses/brackets
- Removed space before comma/cast
- Fixed indent of some lines
Change-Id: I29867ffdffdfb7d2b56997e9393497c7dc12f7d3
Right now, SpecialPageFactory::getAliasListObject() just chooses the
last-seen alias and allows any alias to completely override the page's
"canonical" name (from SpecialPageFactory::$list or $wgSpecialPages).
Although the latter doesn't come up often since (almost?) all special pages
have their canonical name as one of their English-language aliases.
More sensible behavior is to always prefer the "canonical" name over any
conflicting aliases, and to prefer an alias that's the first alias for a
special page over one that is a fallback.
Also, when a special page's first alias winds up not actually referring
to that special page, we MUST NOT go redirecting other names for that
special page to that wrong alias.
Bug: 70686
Change-Id: I4b17ec0fdc87b4b0d7ae9d9eea7ffacb54dd6891
This enables factory functions to be registered for special
pages, as an alterative to giving a class name. This follows the
same rationale as Ieb85493a7765, which introduced factory functions
for API modules.
Change-Id: Ia2107dc5af7869187ba5dc02a1bef46d6801e138
