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
This was a soft transition left over from when "edittime" was the last
form parameter. It has been replaced with an explicit "ultimate" param.
Change-Id: I28767fdf8fab512830fe6e24cacabb598d7cca90
This is an attempt to clarify the semantics of several fields
and methods in EditPage that represent some kind of parent or base
revision.
Bug: T197685
Change-Id: I37b3803fc558fecc0c7b0c3cfb4ec93dce6997a5
This introduces PageUpdater to replace WikiPage::doEditContent,
and DerivedPageDataUpdater, to replace WikiPage::doEditUpdates
and WikiPage::prepareContentForEdit.
See docs/pageupdater.txt for a description of their
functionality.
MCR migration notes:
* The interface of PageUpdater is expected to
remain mostly stable after this patch. Code that has been using
WikiPage::doEditContent can be confidently migrated to using the
new mechanism for revision creation.
* This patch keeps the code inside PageUpdater largely aligned
with the old code in WikiPage, to make review easier to to avoid
mistakes. It is intended to be refactored further, moving
application logic into stateless services.
* DerivedPageDataUpdate is intended as a stepping stone for further
refactoring. Its behavior is designed to be compatible with
callback code that currently relies on
WikiPage::prepareContentForEdit. Much of the code that currently
lives in DerivedPageDataUpdate should be factored out into
services, all behavior relevant to calling code should be exposed
via narrow interfaces.
Bug: T174038
Bug: T196653
Change-Id: If610c68f4912e89af616cdcac1d35a1be3946afa
Uses new PHP 5.6 syntax like ...parameter unpacking and
calling anything looking like a callback to make the code more readable.
There are much more occurrences but this commit is intentionally limited
to an easily reviewable size.
Change-Id: Idcec077ef3fdf029b632cceafd0150851ad723e3
Find: /isset\(\s*([^()]+?)\s*\)\s*\?\s*\1\s*:\s*/
Replace with: '\1 ?? '
(Everywhere except includes/PHPVersionCheck.php)
(Then, manually fix some line length and indentation issues)
Then manually reviewed the replacements for cases where confusing
operator precedence would result in incorrect results
(fixing those in I478db046a1cc162c6767003ce45c9b56270f3372).
Change-Id: I33b421c8cb11cdd4ce896488c9ff5313f03a38cf
A cookie will be set when ip users try to edit and their IP has been
blocked or if they try to create an account and the block prevents
account creation
This feature is disabled by default and can be enabled by
setting the new $wgCookieSetOnIpBlock config variable to true.
Note: this is meant to discourage vandals that try to avoid blocks by
switching their ip address while editing anonymously.
Bug: T152462
Change-Id: I0b78a5e174bcd882edea39e868a08f9a347f5aba
Disable it in specific files and places where there are legitimate uses
to access $_GET and $_POST directly.
For EditPage, which wants to output $_POST for debugging information,
introduce WebRequest::getPostValues() as a wrapper, matching the
existing ::getQueryValues().
Change-Id: I2cb0a7012fb7ed29dcd720056b42f56508ddc5fa
The primary goal here is a defense in depth measure to
stop an attacker who found a bug in the parser allowing
them to insert malicious attributes.
This wouldn't stop someone who could insert a full
script tag (since at current it can't distinguish between
malicious and legit user js). It also would not prevent
DOM-based or reflected XSS for anons, as the nonce value
is guessable for anons when receiving a response cached
by varnish. However, the limited protection of just stopping
stored XSS where the attacker only has control of attributes,
is still a big win in my opinion. (But it wouldn't prevent
someone who has that type of xss from abusing things like
data-ooui attribute).
This will likely break many gadgets. Its expected that any
sort of rollout on Wikimedia will be done very slowly, with
lots of testing and the report-only option to begin with.
This is behind feature flags that are off by default, so
merging this patch should not cause any change in default
behaviour.
This may break some extensions (The most obvious one
is charinsert (See fe648d41005), but will probably need
some testing in report-only mode to see if anything else breaks)
This uses the unsafe-eval option of CSP, in order to
support RL's local storage thingy. For better security,
we may want to remove some of the sillier uses of eval
(e.g. jquery.ui.datepicker.js).
For more info, see spec: https://www.w3.org/TR/CSP2/
Additionally see:
https://www.mediawiki.org/wiki/Requests_for_comment/Content-Security-Policy
Bug: T135963
Change-Id: I80f6f469ba4c0b608385483457df96ccb7429ae5
There has long been a hack for previewing edits to user JS/CSS, where
OutputPage would pass an 'excludepage' parameter to
ResourceLoaderUserModule to tell it not to load one particular page and
would instead embed that page statically. That's nice, but there are
other places where we could use the same thing.
This patch generalizes it:
* DerivativeResourceLoaderContext may now contain a callback for mapping
titles to replacement Content objects.
* ResourceLoaderWikiModule::getContent() uses the overrides, and
requests embedding when they're used. All subclasses in Gerrit should
pick it up automatically.
* OutputPage gains methods for callers to add to the override mapping,
which it passes on to RL. It loses a bunch of the special casing it
had for the 'user' and 'user.styles' modules.
* EditPage sets the overrides on OutputPage when doing the preview, as
does ApiParse for prop=headhtml. TemplateSandbox does too in I83fa0856.
* OutputPage::userCanPreview() gets less specific to editing user CSS
and JS, since RL now handles the embedding based on the actual
modules' dependencies and EditPage only requests it on preview.
ApiParse also gets a new hook to support TemplateSandbox's API
integration (used in I83fa0856).
Bug: T112474
Change-Id: Ib9d2ce42931c1de8372e231314a1f672d7e2ac0e
Also recognise MediaWiki: JSON pages (with the existing protection of
the editinterface right).
Bug: T76554
Change-Id: Idba166d82ee6dd507d7345c9bdbefc8ca78ed7b4
