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
