While that commit fixed the issue it was intended to address, it also
completely broke VE everywhere else. Basically you'd end up with a result
like this:
array(5) {
[0]=>
int(14)
[1]=>
int(6)
[2]=>
int(2)
[5]=>
int(0)
[6]=>
int(250)
}
With the lack of 3 and 4 keys making the JSON formatter think we've got an
object.
Bug: T139094
Change-Id: Ia21fd4bd352afc9170357576a3e0eb17b4528326
array_merge renumbers numeric keys. The namespace configs can be either
numeric or names. If they're numeric, they shouldn't be renumbered. So just
add them.
Bug: T138980
Change-Id: I3e3ecb3e9e65443ba0d44f8eeb67d6b390eca0bd
This will disable ProofreadPage's addition of the Page namespaces (e.g. on
wikisources), but this is more important right now.
Bug: T138980
Change-Id: I23ee26fa95a01b3e0881a4ca16e70247839d9cd9
Note that this does not add support of the preload GET parameter,
which is in T51622.
Bug: T138588
Change-Id: I46ade4de02f15444c1ca5731a475ed89b31960d9
This should really be done automatically by resource loader,
but merging only works on globals. We use this same hack
for plugin modules.
Change-Id: I5f729ddb6146565dc839f60353ac8fa5b2a29ca8
* Don't just fail to load, action=visualeditor itself should not write to the DB
(we have action=visualeditoredit for that)
* Send notice to the client in the usual way
* Handle read only errors on save, log as unknown
This won't let you review changes because that uses visualeditoredit
Bug: T129501
Change-Id: Id78c06b031423e47a7ddf94ec615b6d6975309d3
getDescription() and getParamDescription() have been replaced by a proper i18n-based
API documentation system since MediaWiki 1.25. Retaining these does not help us with
backwards-compatibility given that the repo already requires MediaWiki 1.27.0-alpha,
so just drop them before they become out of date.
Change-Id: Ic8b87235aeb7e1bcd7b24d5609c7d002658a66ba
'nocreatetext' is only the right error message when anonymous users
are generally not allowed to create pages on the wiki. But there are
other situations, for example a title might be blacklisted.
Change-Id: I7b8e83fa0bf98449e63e67705b709d227d9a379f
This requires https://gerrit.wikimedia.org/r/214351 in core, which adds
support for emulating the RESTBase v1 API to the
ParsoidVirtualRESTService.
$wgVisualEditorPrefix is now deprecated. Parsoid is configured using
VRS (preferred) or $wgVisualEditorDomain, which defaults to
$wgCanonicalServer.
This bumps our MW-core dependency to 1.26wmf21.
Bug: T110780
Change-Id: I9175ac8db8310f0c9574c8272b5e39932557d57e
This data is used for marking links red, but links which are known
but don't exist (e.g. interwikis) are not red.
Also fix bug in API caused by trying to return a value of (bool)true which is
apparently not allowed. Use (number)1 instead.
Bug: T104604
Change-Id: I599a513a27b31f7167e688d73bc3685141249971
By default 'helppage' is set to a full url (using Special:MyLanguage
on www.mediawiki.org). When it is set to a page name, we expand
to a url. However that url is relative (e.g. "/wiki/..") which
is not a valid external link in the "[$1 ..]" syntax MediaWiki
uses in the 'newarticletext' message.
In MediaWiki's EditPage.php this is handled by wrapping the return
value in wfExpandUrl(), we should do the same here.
Without this, on wiki's like pl.wikipedia.org that set 'helppage'
to a local wiki page, "[/wiki/Project:Help Help]" shows up literally
in the message shown to the user instead of a clickable link.
Change-Id: I2ffc35a1b255269d5b489c68eace9edafb42d8ff
PS25 and later changed things around a fair bit, meaning the previous update
needs some further updating. In some cases additional cleanup is also necessary
for future core API changes.
Bug: T96595
Change-Id: Iaac674f77079d29d42813fd69620bdce8905730f
* The standard core method for page saving already checks the cache.
By stashing the parser output as the user types, the final save step
will be faster, just as with the wikitext editor.
Bug: T90040
Change-Id: If10a79381c6301d52f4a68ca91d0e1d7fbc79bb5
