In change I625a48a6ecd3fad5c2ed76b23343a0fef91e1b83 I am planning to
make Wikimedia\Message\MessageValue use it, and we try to pretend that
it is a library separate from MediaWiki, so it makes sense to move
MessageSpecifier to the same namespace under Wikimedia\.
Bug: T353458
Change-Id: I9ff4ff7beb098b60c92f564591937c7d789c6684
getPermissionStatus() does the same thing but better.
A lot of things use the legacy error arrays though, we're nowhere near
removing it.
Change-Id: Iff60dbb0593329a584d003b2407bbf24d5b22aea
In almost all cases we're already returning a Message object from
Action::getPageTitle(). Tighten this up by deprecating the string
return value and requiring the returned value be a Message; this also
encourages proper localization.
We pass the returned message to OutputPage::setPageTitleMsg(), which
uses FORMAT_ESCAPED. This is a change from before this patch, where
messages are formatted using FORMAT_TEXT. If you need to include
HTML in the page title, use Message::rawParams().
Bug: T343994
Bug: T343849
Depends-On: I2fe88d95737e673a381d039909e854e4410c8ce3
Change-Id: Ia7da1b7063a77bf94f4c71e9d77c9408c3f4aa46
The new method encapsulates the fact that we currently have to
instantiate action objects to determine which permission the action
requires. This encapsulation reduces coupling in PermissionManager
and allows us to easily change to a better way to create ActionInfo
later.
Eventually, ActionInfo should be constructed based on the action's
object spec. This requires us to include the relevant information in all
specs, in core and extensions.
Change-Id: I707a165c41403ebd4a3edfc66c1595e1bd3a4087
In almost all cases we're already returning a Message object from
Action::getPageTitle(), despite the phpdoc on the parent class claiming
that the return value is a string.
Bug: T343994
Bug: T343849
Change-Id: I968e37f588bbdf0cddf4ad27087d55e95e8c1c17
The motivation is to make the code less confusing. I hope this is the
case.
?? is an older PHP 7.0 feature.
??= was added in PHP 7.4, which we can finally use.
Change-Id: Id807affa52bd1151a74c064623b41d950a389560
Use the instance of the abstract classe
instead of injection via ObjectFactory
Similiar to handling in abstract SpecialPage class
Change-Id: I638fc732db94413bf6b917b38daa221fb47931e3
Most accesses to this value (other than technically incorrect use
via WebRequest::getVal), such as in various extensions,
call Action::getActionName($ctx) rather than MediaWiki::getAction
or the new RequestContext::getActionName.
Related changes recently:
* Introduced in 3fdfef96e4 (I1e259b54dca4).
* Primary caller optimised in d7beb0e4ec (I72ffc9f36613bf9).
* Warning for misuse added in Ib9fc34ca64b7c0e89.
This fixes a bug in DerivativeContext, which got exposed by the
ActionTest test cases, which happen to use DerivativeContext and
inheriting from the global RequestContext. That's not ideal for
the test to do, but did luckily help find this bug.
The issue is that when changing the title or wikipage, the action
cache be cleared and re-computed the next time it is accessed.
The RequestContext class (which is also a mutable context) does
the same and that is already covered by tests.
Bug: T314008
Depends-On: I8434442a61449c16981b19935f2dbdf18e4b4e50
Change-Id: I7d40e7ca4878d43fd7d7614d9c8cf8d29a8c7c4b
It currently becomes a string implicitly much later on based on the
default format. All other implementations return a string and for
messages that typically is formatted as text(). This should be done
explicitly as it is the responsibility of RevertAction to know this
message and how it is meant to be formatted to get the string that
the "getPageTitle" contract calls for.
This bug has been here since 2012 with change I2c6fad30e2c4eaebf122,
where the code changed from wfMsg (string, unlike wfMessage) to
`$this->msg` without calling a format.
Bug: T252946
Change-Id: Ibfa335952eb752515a31be6feb6749534bb2a7c4
Flow defines a lot of custom actions which are only implemented for its
own content type. This use case is not what we had in mind when
getActionOverrides() was introduced, but allowing it in ActionFactory
removes the need for Flow to write dummy ignored config to $wgActions.
Bug: T303237
Change-Id: I67c1ae95344b0004eb93023fae7e93de4e47888b
The functions returning null or the class property is set explict null
Found by phan strict checks
Change-Id: I4a271093fb6526564d8083a08249c64cb21f2453
As a security hardening measure to limit exposure on private wikis from
actions on $wgWhitelistRead pages, require an explicit 'read' right on
actions by default. Currently only ViewAction disables this check since
it does its own permissions checking.
This is somewhat duplicative of the permissions check in
MediaWiki::performRequest() but we'll call it defense in depth. It also
matches similar logic in the Action and REST APIs.
Bug: T34716
Bug: T297416
Change-Id: Ib2a6c08dc50c69c3ed6e5708ab72441a90fcd3e1
Inspired by T290004, attempting to solve that ticket will be done
in the next patch on this one.
Bug: T290004
Change-Id: I431e3eba1bcfb446a4ab60aa3d2189762ea9f65f
From within a specific action, the relevant context should
always point to that action, and so we can just use $this->getName()
Bug: T253078
Change-Id: I7d669fc199958cb86086985f954cd509a8957306
Once all actions are having dependencies injected,
those that need a hook container can just have it injected
instead of relying on the global state, which is what
Action::getHookContainer() and ::getHookRunner()
use.
Bug: T253078
Change-Id: I09c70703d4634f855620a56273a9ad924cf061a7
$wgActions used to map string action names to true,
false, a string, a callable, or an object. Now it can also
be an array (that isn't a callable) corresponding to an
ObjectFactory spec for DI.
This patch converts the revisiondelete and rollback actions to
use DI, with the rest to be converted later. The new structure
of $wgActions is fully backwards-compatible.
We don't yet deprecate Action::factory(), ::getActionName(),
and ::exists(), those will be deprecated in a follow-up.
Additionally, we no longer impose a rule that only some
actions can be overridden on a per-article basis via
Article::getActionOverrides().
Bug: T253078
Change-Id: I0fc3c53d671eced1758458f9a0148180b40c6c9b
When calling PermissionManager::isBlockedFrom, don't query the
primary database when only showing UI elements.
Bug: T283268
Change-Id: I9a79badf8a7cfb6afc7b4d12e4f1fbb5c24b6a86
Action::factory() now requires a string and an article object,
dropping the deprecated support for null as the action name
and a non-article Page object.
Change-Id: I1e73a4638edb6f3aa14822b655d977da177d01bd
For compliance with the new version of the table interface policy
(T255803).
This patch was created by an automated search & replace operation
on the includes/ directory.
Bug: T257789
Change-Id: Ie32c1b11b3d16ddfc0c83a757327d449ff80b2e4
For compliance with the new version of the table interface policy
(T255803).
This patch was created by an automated search & replace operation
on the includes/ directory.
Bug: T257789
Change-Id: I5ffbb91882ecce2019ab644839eab5e8fb8a1c5f
For compliance with the new version of the table interface policy
(T255803).
This patch was created by an automated search & replace operation
on the includes/ directory.
Bug: T257789
Change-Id: If560596f5e1e0a3da91afc36e656e7c27f040968
A terminating line break has not been required in wfDebug() since 2014,
however no migration was done. Some of these line breaks found their way
into LoggerInterface::debug() calls, where they mess up the formatting
of the debug log.
So, remove terminating line breaks from wfDebug() and
LoggerInterface::debug() calls.
Also:
* Fix the stripping of leading line breaks from the log header emitted
by Setup.php. This feature, accidentally broken in 2014, allows
requests to be distinguished in the log file.
* Avoid using the global variable $self.
* Move the logging of the client IP back to Setup.php. It was moved to
WebRequest in the hopes that it would not always be needed, however
$wgRequest->getIP() is now called unconditionally a few lines up in
Setup.php. This means that it is put in its proper place after the
"start request" message.
* Wrap the log header code in a closure so that variables like $name do
not leak into global scope.
* In Linker.php, remove a few instances of an unnecessary second
parameter to wfDebug().
Change-Id: I96651d3044a95b9d210b51cb8368edc76bebbb9e
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
This partialy reverts commit 07f57bd271.
Reason for revert: Article::newFromWikiPage causes an infinite loop
if 'ArticleFromTitle' hook handler ends up calling Action::getActionName.
The revert preserves new getArticle and getWikiPage methods since there
are a few extension changes merged dependent on these. Alternatively this partial revert, we could do a full revert with all the dependencies https://gerrit.wikimedia.org/r/c/mediawiki/core/+/585343
Bug: T249162
Change-Id: Ifa642a631caa2d265ee097711dc8727f84435ef0
