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
I999b9772 added a new parameter to the message, since then VE has just
been pointing this link to $1.
Bug: 63146
Change-Id: Icbaa79e6db9536c5bba2b8b3537f0920b0439f52
Bug is just about blocked-notice-logextract, but the same EditPage code also deals with
userpage-userdoesnotexist so lets deal with that too while we're here as it's trivial.
Bug: 51454
Change-Id: Ic8a8f135c9f76f645c25a31d9432b5e2786dcfa0
* Add ve.init.mw.LinkCache to track page existence and
transparently query it
* Populate it with initial data from the parser cache
if available, obtained in the VE API module
* Use linkCache data in link annotation rendering
This doesn't yet integrate the LinkCache with other
components like the link inspector. That should be
done so we can deduplicate the existence checks.
Additionally, we should generalize LinkCache and use
it for the category existence/status checks as well.
Bug: 37901
Change-Id: I9fd43e8c3864dd375cf6dadfdeedd05e4fe9cf3b
In our parse request for 'wikitext fragments', used in the transclusion dialog
and extension inspectors, we weren't passing 'pst' as true, so while [[Foo|Bar]]
came back as expected, [[Foo (bar)|]] just came back as plain text, confusing
users.
Bug: 60998
Change-Id: I9931ad8034273ceb19c027d5035c63422cc0e570
