This is a clean up after collecting the necessary data related to
blocks and how often users see the block notices
See: https://phabricator.wikimedia.org/T189724
Bug: T214214
Depends-On: I047587c064e63e8bd4b933351edfec298f7c7956
Depends-On: I532a0cd95009109ba25caa8dd31badd5c1900da7
Change-Id: Icfa74ad6337c0a4f12ae24b43d36c0e3cb302a3b
This is a quick fix for the main symptom of the Chrome bug that results in
users being redirected to Special:BadTitle after section editing. We'll
need to discuss a more permanent solution.
Bug: T216029
Change-Id: I4b2d42ebc74031df86bc52310da71819da11c1ae
This was inspired by Idbbdb31. Originally, I did a regex search for
code that did string concatenations like `$str = $str . …` and replaced
them all with the .= operator. A duplicate patch was uploaded by another
author. I rebeased this patch on top of the other, which leaves all
the manual optimizations I did.
Change-Id: Iaeb73d9c63302c9409bd1051b91e0d2bd77788a7
This is inspired by Ib117e05.
As far as I can tell this is functionally identical. Even arrays should
behave the same, as both the getVal() and getCheck() methods do have a
special case that returns the `null` default in case the user tried to
pass multiple values instead of a single scalar.
Change-Id: Id4e4ec91f39d3c39461bd41673bdafc3bde11737
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
Show log extract if the user is sitewide blocked, or is partially
blocked and not allowed to edit their user page or user talk page.
Bug: T203171
Change-Id: I9bcc50cfc1fad23f6bbbe5374a9a866f77bebc11
Monitoring block notices is behind $wgEnableBlockNoticeStats config
flag which is set to false by default.
The reason behind this metric is to get an idea on how
frequently blocked users attempt to edit a page. Similar tracking
is being added to MobileFrontend and VisualEditor.
Bug: T201718
Change-Id: I6bd1c95548616677e1f72ba6bcfc6f2b551c1ca6
This forces the WikiPage returned by $this->getContext()->getPage()
to be the same as $this->page.
This seems to be redundant at the moment, but it seems prudent to
make sure this does not break. Having two WikiPage instances may
cause subtle problems, such as redundant parsing of content during
edits.
Bug: T205369
Change-Id: I8dd3235ec395fa8772ad810f8b09a098a940ab0c
It's important to send people back not just to the page they were
editing, but to the actual edit action as well.
Bug: T208989
Change-Id: I010145840da1ac93927db846872eaf9843116bd7
Use OutputPage::parseAsInterface() to tidy the output and make the
selection of user interface language explicit.
Bug: T198214
Change-Id: Ifeb1ca6eb8b5c743421b8f9e329f1e3658050e47
If we're going to call `OutputPage::addWikiTextAs*` or
`OutputPage::parseAs*` to parse the message, we don't need to
pre-expand `{{...}}` markup before passing it to the parser.
Follow up to I2f68f73365df876e6f9d017e4e3ddea39c4a1284.
Bug: T206574
Change-Id: I0ee493207ea80c1caba7e60a31714805dc54c64e
This ensures that broken messages can't break the <div> wrapper and
that the output is tidy.
Bug: T205624
Change-Id: I2511adf593a13528e205a82d9fcdc8a524d0a95f
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
With this change, MediaWiki will no longer have a 'JavaScript-powered'
wikitext toolbar, and instead sysadmins will be required to choose one
(or more) of the several extensions available for this purpose if they
need the functionality. For over half a decade MediaWiki's tarball has
included the 2010-era replacement for this feature, WikiEditor. We are
now working on replacing even that, with the 2013-era visual editor, a
mode of which is the forthcoming 2017-era wikitext editor, and several
more specialised editors like CodeEditor.
Beyond this, the core editor toolbar is ancient, un-loved, and is used
only exceptionally rarely, mostly by accident. It is unhelpful to give
implicitly this as the primary editor for MediaWiki just because we've
not removed it from core when it is not a very good experience for any
kind of user, and has not received the attention that users deserve to
be worth retaining in core.
The old core preference, which was intended to govern whether this old
toolbar should be shown, has since mutated into whether the to run the
EditPageBeforeEditToolbar hook. The hook is used by several extensions
to provide toolbars in lieu of the core one. This preference has been,
in practice, a very confusing preference for MediaWiki users, who have
to interact with quite similar preferences to toggle their real editor
which sit next to this one on the preferences page. Consequently, this
preference is also removed.
The code could be made into an extension for those (very few) users of
MediaWiki who might want to keep on using it. However, the author will
offer their services but not their encouragement in said undertaking.
Bug: T30856
Bug: T32795
Change-Id: I2b05f0ca25873ad8e0b33a5e4938bef52c4e9347
If we're going to call `OutputPage::addWikiText` to parse the message,
we don't need to pre-expand `{{...}}` markup before passing it to the
parser. This makes these callsites consistent with how
`OutputPage::addWikiMsg()` inserts messages.
Bug: T206574
Change-Id: I2f68f73365df876e6f9d017e4e3ddea39c4a1284
This is a follow-up to Ia58910164baaca608cea3b24333b7d13ed773339 which
added new & improved names for the addWikiText*Tidy() methods.
Bug: T198214
Depends-On: I42d198e6d03afd5b976da741f235c175bfe9f767
Change-Id: I1993c2009e861fdb45c9b1bd42eab1e28a776d9a
Added spaces around .
Removed empty return statement which are not required
Removed return after phpunit markTestIncomplete,
which is throwing to exit the test, no need for a return
Change-Id: I2c80b965ee52ba09949e70ea9e7adfc58a1d89ce
One use case of display title is to localise page names with Translate
extension or without. While the page title changes, the subheadings still
say something like "Pages in category Foo/de".
Also converted one raw HTML message to be a parsed message.
First version of this patch caused an issue when previewing
because page title in h1 is not the same as page display title.
This issue is fixed by promoting page display title as it's own member
in OutputPage. Also added getUnprefixedDisplayTitle that attempts to
strip away the namespace prefix to mimic Title::getText() but which
works with display title instead.
Bug: T43720
Bug: T46197
Change-Id: I6097a873297eb57759252fc56ad6d02c44e4c366
This injects the new, unsaved RevisionRecord object into the Parser used
for Pre-Save Transform, and sets the user and timestamp on that revision,
to allow {{subst:REVISIONUSER}} and {{subst:REVISIONTIMESTAMP}} to function.
Bug: T203583
Change-Id: I31a97d0168ac22346b2dad6b88bf7f6f8a0dd9d0
Since SDC doesn't actually require the edit form to handle multi-slot
editing, updating EditPage with its normal undo handling is being put
off for later. But in the mean time we still want some sort of "undo" to
work, hence this mcrundo that doesn't allow for editing.
Bug: T200216
Change-Id: I1f11d8ed141cb11576d2df883856d03e8f64bd38
Depends-On: Iedd9bf6c057e8b396a575bab700b15bd38b32cc9
Switch from passing a plain function to RLQ that calls depends
on using() from 'mediawiki.base' and 'jquery', to using the new
array format introduced in Ica7bb9c3bdb (T192623).
This ensures the code will keep after we change the fact that
RLQ is blocked by base modules.
Bug: T192623
Change-Id: Id50e6dcc28c13b021d8395a2da0d83b46f88e18c
EditPage::getPreviewLimitReport is called by EditPage::showEditForm
with $output = null. Specify this in the @param tag and allow this by a
default value.
Change-Id: Iec8905aab736a1f254a57853c7cab935d008653e
This reverts commit b24fafd606.
Reason for revert: T199504
The strict comparisons changes semantics when parameters are not set and thus null.
This could be fixed by setting the right defaults when getting parameter values, but needs a closer look.
Bug: T199504
Change-Id: I7b3e5d4f4d50af6603b3414be099d5bda6571387
