Assume the person setting up the wiki knows what they're doing since
we've warned them quite a bit already in the on-wiki documentation.
Bug: T140129
Change-Id: I1c7ffb22eba5ab5b5e7f92ae23da8fe9edf2606d
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
Stripped out X-Parsoid Performance Headers, previously used to gather and
forward Parsoid's performance information, from ApiVisualEditor.php,
ve.init.mw.Target.js and ve.init.mw.TargetLoader.js. Change I936ada7b1 strips
out the corresponding X-Parsoid Performance Headers from Parsoid. Parsoid's
current performance instrumentation is achieved using Graphite and txstatsd.
Change-Id: I57d6f866a7d8287a5115e6236b0fb25bc4d0eabd
Also introduces paction=metadata in ApiVisualEditor which
doesn't hit Parsoid but gets all the other information we need.
Bug: T90374
Change-Id: I71edbc0f8dc15a6f8d3672c10ca3c641cc172be7
These were only used in ApiVisualEditorEdit.php, seem to have
been missed when the split was done.
Change-Id: I60a9152d244100526cef755cf578d7dfd38a96b9
Change I4d4043e5052327bbd789331f1c05b607c45fe7cb introduces RESTBase's
virtual REST service in the MW core, as well as $wgVirtualRestConfig,
which represents the first step towards central VRS configuration.
This patch modifies VE to use RESTBase instead of Parsoid, if
available. RESTBase's virtual REST service transparently maps Parsoid
URIs to RESTBase's, so there is no need to change them in VE for now.
Note that the patch keeps full compatibility with systems/domains that
do not have $wgVirtualRestConfig declared (or even with those that do
not include the RESTBase virtual REST service class). This allows us
to use RESTBase as the back-end only on selected domains.
Bug: T89066
Change-Id: Ie7488f64868a41f28ec24ab1217c12c6249b5523
On a ParserCache miss when viewing the current version of a
page, we'd output {missing: [], extant: true} which means
all links are marked blue. That's wrong, instead output
that we don't know anything.
Bug: T91299
Change-Id: Icf66735141a8d2a6579dce0ffd847dd099437029
We used to send data like { title: { missing: true|false } }
With this change, we send data like { missing: [titles], existing: true|[titles] }
where 'existing' is set to true (assume all non-missing titles exist)
for current revisions and to an array of existing titles for
old revisions.
This is because we always output this data for links in the current
revision, even when loading an old revision: in that case we rely
on the client to request the omitted information, so there we can't
assume that all pages we don't have information about exist.
Bug: T88259
Change-Id: I7b58b3f669cc78fd81b60859cf76928a9087066f
Change I7b37295e for mediawiki/core deprecates several methods, and more
importantly changes the format of the data returned from
ApiResult::getData(). This change should handle these differences in a
backwards-compatible manner.
Change-Id: I7b37295e8862b188d1f3b0cd07f66ac34629678e
I2342fa5b added a dependency on Id658d925 in MediaWiki core which will first
be available in 1.25wmf14.
Also fix a spelling error.
Change-Id: I20a850f5da58b377b3c208d86b7f5c56f518fdb8
Breaking change: Introduces new dependency on php5-curl package.
Relies on Id658d925 which introduces this class into core.
Bug: T1218
Change-Id: I2342fa5b0a185f3e8d46d1ba8fa08278970cafb0
Instead of doing a whole new parse for displaytitle, just get it from
the same API action=parse internal request that is used for returning
the content HTML.
Also escape entities as in OutputPage::setPageTitle(). The format of
OutputPage::setPageTitle()/getPageTitle() is a bit confused -- it's
mostly treated as HTML, but Article::view() sets it to the unescaped
title text -- a historical error which was unfortunately wallpapered
over.
Change-Id: I387c1ccd9a75f9c6c6a006d83235c6c1c3d1ecb5
MediaWiki core change I04b1a384 added support for i18n of API module
help. This takes advantage of that while still maintaining backwards
compatibility with earlier versions of MediaWiki.
Once support for MediaWiki before 1.25 is dropped, the methods marked
deprecated in this patch may be removed.
Change-Id: I67395aff48185f3e09da31b51a08aa2541fe6a17
This will reduce the level to which the VisualEditor API looks like a
tempting target for third parties, given it is undocumented and isn't
supported.
Bug: 62452
Change-Id: Ib34e526fcee46ea4ffe76261012c706233461dad
VE doesn't use the debug log at all, it seems. This adds a single
wfDebugLog call so that the person using the debug log can see that it
actually does hit VE.
Also, returns better information for parsoid errors.
For example, without it, a parsoid misconfiguration of setInterwiki()
gives:
Error loading data from server: parsoidserver-http-bad-status:
500. Would you like to retry?
with it, you get something like the following:
Error loading data from server: parsoidserver-http-bad-status:
500: Page Fetch failure for "BADURL": Error: getaddrinfo
ENOTFOUND. Would you like to retry?
or
Error loading data from server: parsoidserver-http-bad-status:
500: Page Fetch failure for "BADURL": 404. Would you like to
retry?
Bug: 39057
Bug: 43147
Bug: 63149
Change-Id: I52db9fac42d7c0228b93ce3caec470fff98254f0
Also get rid of checking for NS_MEDIAWIKI explictly and use
MWNamespace::getRestrictionLevels instead
Bug: 50783
Change-Id: I5986ddb9b6f17e4a2aca12dbb551cce4a6cfd663
