setWrapperLegendMsg and setSubmitTextMsg are calling Message::text
Replacing setSubmitText + Message::text with setSubmitTextMsg makes the
code easier to read
Change-Id: I73389991fea82e1927027dc95c3debc3d8c15939
The documentation of OutputPage::wrapWikiMsg says it is
equivalent to OutputPage::addWikitextAsInterface called
with wfMessage()->plain(). This is correct, as it parses
it in addWikitextAsInterface. If used with addHtml, no
parsing/escaping is done automatically.
Follow-up to I83f2828bcde160c98a1d97e783a869e64fb4c6ea.
(NOTE: the above, related change set is NOT currently
on a wmf production release branch. So this issue only
exists on master for now. This should all be resolved
when both are part of the cut for wmf.4 next week.)
Bug: T281595
Change-Id: Ia6c7a7447e5cea903be9f5d9e76320ea56fedd4c
These are styles for actions that do not have a dedicated style module.
Given that the amount of css it contains it marginal, creating a
dedicated module for each action would be overkill.
Bug: T278504
Change-Id: Id03c81e7d5ebf179731649aa230def2e8e21ac02
Use the name of the input for the value where possible.
Additional change: Use `default` rather than `invert` for checkbox
default state.
Bug: T275018
Bug: T274980
Change-Id: Ie08b192ad4967ac6c6d80b9c76224acd183fc1e8
Breaking changes:
* Ids 'mwProtectSet', 'mw-protect-table3', and
'mw-protect-table-$action' are no longer present on page.
* Module 'mediawiki.legacy.protect' has been removed and replace by
'mediawiki.action.protect'.
Deprecations:
* ProtectionForm::buildForm has been replaced by
ProtectionForm::addFormFields with backwards compatibility.
Other changes:
* Expiry is no longer editable when "Allow all users" is selected
* When "Unlock further protect options" is disabled, the expiry of
the first section is used for the other sections
* Legacy form elements added by extensions are added to a separate
section which uses a blank i18n string as the header
* Unprivileged users see the expiry selector instead of the expiry
text input as it has the expiry date
Changes to ProtectionForm.php are based off of
I95d0289acceaa7ede789d5a6ea094fae757af6dc.
Bug: T235424
Bug: T236218
Change-Id: Ib22a3b53c1933e107ef5609bb2262aa44b5abb7a
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
