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
There are a few messages that use a custom format for select
lists. This moves the parsing of these messages into a single
method.
Bug: T245565
Change-Id: I0a24d3458979d7cca2dc3cb38c1b0f700a88490a
Per code search string "\$this\-\>showLogExtract\( \$ou", method
is only called within the ProtectionForm class so can be safely
made private but there are methods with the same name in a class
like LogEventsList but do different things.
Inspired by @Thiemo's comment on I167ae6300b37d4e9292.
Change-Id: Ic4983ccffecc6285f848d6e926017c4c6df4855f
https://codesearch.wmflabs.org/core/?q=showLogExtract%5C(&i=nope&files=&repos=
according to codesearch shows that this method takes as first argument an output
page object and also, objects are passed by reference by default so removed &.
Change-Id: I167ae6300b37d4e9292bd8ad14351f1ca35184d2
This removes most of the pre-CommentStore text columns, and the
$wgCommentTableSchemaMigrationStage setting that used to determine
whether the columns were used.
rev_comment remains in the code, as on Wikimedia wikis the revision
table is too large to alter at this time. A future change will combine
that with the removal of rev_user_text, rev_content_model, and
rev_content_format (and the addition of rev_comment_id and rev_actor).
CommentStore's constructor continues to take a $stage parameter, and
continues to have the logic for handling it, for the benefit of
extensions that might need their own migration process.
Bug: T166733
Change-Id: I1479c73774e01ead1490adf6128f820c09bce9d4
Every one of these seemed to previously use the wrong value for
`$interface` -- the interface messages in ProtectionForm and
SpecialVersion were being parsed as content language (which is the
default for `OutputPage::parseInline`), and the one place where we
have actual data in the content language (the user signature, which
gets parsed in the content language with the rest of the (talk) page
content, see Parser.php::pstPass2) was being parsed as an interface
message!
Forcing the caller to be very explicit about AsContent() or AsInterface()
will help mitigate this in the future, one hopes.
Bug: T198214
Change-Id: Ib9d5d8d733a47c967bdf7db3e23fa39f11687063
This change ensures that the output is tidy, and is necessary to support
future parsers which will not be able to produce untidy output.
Bug: T198214
Change-Id: I743f4185a03403f8d9b9db010ff1ee4e9342e062
<p>-wrappers are fragile in case the wrapped content contains `<div>`,
`<p>` (or wikitext double newlines). Use <div> wrappers consistently
in MediaWiki.
Bug: T205624
Change-Id: Ieee77f4220c7895ac5dccb2b638baef0dc22c84f
For unfortunate historical reasons, browsers' native maxlength counts
the number of UTF-16 code units rather than Unicode codepoints [1],
which means that codepoints outside the Basic Multilingual Plane
(e.g. many emojis) count as 2 characters each. That could be good
enough, but we want our software to be excellent rather than merely
good enough.
1. Introduce a few new functions, added to the existing modules:
* mediawiki.String:
* codePointLength() counts the length of a string in Unicode
codepoints (characters).
* trimCodePointLength() trims a string to the desired length in
Unicode codepoints (characters).
* jquery.lengthLimit:
* $.fn.codePointLimit() enforces the specified maximum length in
codepoints of an input field.
* mediawiki.widgets.visibleLengthLimit:
* mw.widgets.visibleCodePointLimit() enforces the maximum length
in codepoints of an OOUI widget and displays the remaining
length in an inline label.
2. Add client-side mw.config variables:
* wgCommentByteLimit for the old byte limit, equal to 255.
* wgCommentCodePointLimit for the new codepoint limit, equal to 1000.
Only one of them may be set, depending on which limit should be applied.
3. Make use of both of these new features. For the sake of an example,
I updated the forms shown on action=edit (using visibleCodePointLimit)
and on action=protect (using codePointLimit). Many remain to be updated.
[1] https://www.w3.org/TR/html5/sec-forms.html#limiting-user-input-length-the-maxlength-attribute
Bug: T185948
Change-Id: Ia1269fd898dabbcf1582618eab46cef97e10a3b1
See the task, this was probably entirely my fault not having
looked at this more carefully. Technically the change is ok,
however, it seems to doesn't make much sense in combination
with the Reason dropdown box.
This reverts commit faab2411c2.
Task: T34950
Change-Id: I1eeb9c68ff0db20d29e7d5f0fb18f0bfa3224416
Most of these are simply changing annotations to reflect
reality. If a function can return false to indicate failure
the @return should indicate it.
Some are fixing preg_match calls, preg match returns 1, 0 or false,
but the functions all claim to return booleans.
This is far from all the incorrect return types in mediawiki, there
are around 250 detected by phan, but have to start somewhere.
Change-Id: I1bbdfee6190747bde460f8a7084212ccafe169ef
The title used for Linker::link in all places are mediawiki pages, which
are known to be exists (and blue), because there are definied in en.json
Change-Id: Ib3b6e4f4f6cef059a502aaabfcfc17730b4445a6
Some special pages or actions have a link for users with editinterface
rights to edit the message used in scroll down menu.
When the message is parsed for the scroll down menu the config
$wgForceUIMsgAsContentMsg is used, but that was not used for the edit
link.
Add a new function Message::getTitle and use it in all places in core.
Most benefit will have the edit link for MediaWiki:Licenses on
Special:Upload, because commons.wikimedia.org has that message in
$wgForceUIMsgAsContentMsg.
Change-Id: Ib800b9adcc9ae88ef53228b66838bf61d2065f0f
There's a bunch of stuff that probably only works because the database
representation of infinity is actually 'infinity' on all databases
besides Oracle, and Oracle in general isn't maintained.
Generally, we should probably use 'infinity' everywhere except where
directly dealing with the database.
* Many extension callers of Language::formatExpiry() with $format !==
true are assuming it'll return 'infinity', none are checking for
$db->getInfinity().
* And Language::formatExpiry() would choke if passed 'infinity', despite
callers doing this.
* And Language::formatExpiry() could be more useful for the API if we
can override the string returned for infinity.
* As for core, Title is using Language::formatExpiry() with TS_MW which
is going to be changing anyway. Extension callers mostly don't exist.
* Block already normalizes its mExpiry field (and ->getExpiry()),
but some stuff is comparing it with $db->getInfinity() anyway. A few
external users set mExpiry to $db->getInfinity(), but this is mostly
because SpecialBlock::parseExpiryInput() returns $db->getInfinity()
while most callers (including all extensions) are assuming 'infinity'.
* And for that matter, Block should use $db->decodeExpiry() instead of
manually doing it, once we make that safe to call with 'infinity' for
all the extensions passing $db->getInfinity() to Block's contructor.
* WikiPage::doUpdateRestrictions() and some of its callers are using
$db->getInfinity(), when all the inserts using that value are using
$db->encodeExpiry() which will convert 'infinity'.
This also cleans up a slave-lag issue I noticed in ApiBlock while
testing.
Bug: T92550
Change-Id: I5eb68c1fb6029da8289276ecf7c81330575029ef
Refactor out 'infinity' vartiant values which used in blocking and
protecting actions. This patchset adds GlobalFunction wfIsInfinity.
Bug: T68646
Change-Id: I60cc55a5bbd43c72916a1c2ea3807457d4e33765
Xml::option passed the first param to Html::element which escaped the
value, so no htmlspecialchars is needed for $show. The htmlspecialchar
moved closer to output, because the comparision does not need it
Bug: T85864
Change-Id: Ib8b948563095143de686756ceaf46c48cab2c5e0
Also use Language::userTimeAndDate instead of Language::timeAndDate,
avois using $wgUser for the timezone.
Change-Id: I3547bdc2ee2b787bcb301c4023512e31bc18b67f
Currently, modifying protection with infinite expiry time causes it to
be set to a blank "Other time", which causes an error. This fixes it to
act the same way as existing expiry times.
Bug: 70062
Change-Id: I3a7d45a677151597a941ecb11584bc1d67001136
- Set variables near to where they are used in buildForm()
and put variables that only need to be set once out of loops
- Move the definition of 'wgCascadeableLevels' javascript variable
near the inclusion of mediawiki.legacy.protect module, so that
this doesn't need to be set as a side effect of buildCleanupScript()
Change-Id: Ifb54723e7609f6fc5a8939e4fada5c2e664a22bd
