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
