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
Swapped some "$var type" to "type $var" or added missing types
before the $var. Changed some other types to match the more common
spelling. Makes beginning of some text in captial.
Also added some missing @param.
Change-Id: I7f605aa9e117b5fd80d9b1440864fe526d2b14a5
Right now, if you set $wgNamespaceProtection, the protection interface
is confusing: it will allow you to apply "useless" protection levels for
any namespace except MediaWiki, where it will refuse to let you set any
protection at all.
The fix is to find which restriction levels are more restrictive than
the $wgNamespaceProtection restriction (i.e. where there is at least one
group that can pass $wgNamespaceProtection but not the level from
$wgRestrictionLevels), and use only those in the protection form. If
there are no such levels, we can skip showing the "protect" tab
entirely.
Change-Id: I9e2b29ade566abcd008ea2ad1e2f9818e315bb32
* Follows-up b2e2b2e016.
* Minor clean up of surrounding documentation comments.
* Fixed missing keys for messages in WebInstallerPage
Change-Id: Iaa692064262f3c0e10cfa5e4b1ec8c86e5d02362
Split parts of doUpdateRestrictions() into several more concise functions.
The biggest drawback is increasing $dbw->encodeExpiry() calls times 3. This is
not much of a problem given that's a very inexpensive function and it is only
called very few times ($limit holds 2 values in current codebase)
Added $reason to the ProtectionForm::save hook, so that other code hooking into
and adding their own settings into page protection form can also process the
reason for the protection change.
Change-Id: I879290ed83e4e47e9561d4c352fbd50c07d7e18a
It has long been recognized that using the 'protect' right to control
the ability to edit sysop-protected pages is troublesome. r31247 fixed
this by adding an 'editprotected' right, but for some reason in r32164
this was changed to bypass protection completely instead of fixing the
bug identified in r31462.
This patch goes back to do it the right way: editprotected no longer
bypasses all protection, and it is used instead of 'protect' for
controlling access to sysop-protected pages. For good measure, the same
is done with autoconfirmed protection (semiprotection): a new
editsemiprotected right is created instead of overloading the
existing autoconfirmed right.
This also fixes bug 27152 by making editprotected no longer special.
Bug: 13137
Bug: 27152
Change-Id: I6bf650a3fbdab8589ae6945c8c916eafd949e41c
