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
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
On sites using $wgHTTPProxy, any curl requests made via MWHttpRequest
would be passed through that proxy. The Parsoid daemon is most probably
reachable directly, hence we want to be able to disable the proxy.
This can be done using the new $wgVisualEditorParsoidHTTPProxy which is
passed to MWHttpRequest in VisualEditor API.
Change-Id: I855249950b1b368ae0afe662154eb48e5b1a14f2
Add paction=serializeforcache, which serializes the given HTML, stores
the resulting wikitext in memcached, and returns a cache key. This
cache key can then be passed instead of HTML to paction=diff or
action=visualeditoredit for quick diff/save operations using the
cached wikitext, or to paction=serialize to just retrieve the wikitext.
This lays the groundwork for front-loading serialization in the editor,
and for avoiding the double serialization that occurs when the user
first views the diff, then saves.
Bug: 55979
Bug: 56011
Change-Id: I223b1717890632c39e2509967149551f807119f8
If configured to do so, the VE API will forward the Cookie: header to
Parsoid. This allows VisualEditor to be used on read-restricted wikis.
Bug: 44483
Change-Id: If4a0cf1e5785b332ec9b014b783412805cf8af75
The header should comprise 'key=value; ' pairs rather than 'key: value', and
the key name 'cached-response' is less tied to the particulars of the current
Parsoid storage setup (which is being revised). Follows I8085fdba3.
Change-Id: I8bcf947763512ba700793974ab0c48d65c171bbb
Change I1d7fd94f2 to Parsoid adds a custom header on Parsoid HTTP responses,
'X-Parsoid-Performance', which contains data about how long it took Parsoid to
handle the request. This patch makes the API pass through the header from
Parsoid to the client, where it will be logged as an event (along with
additional datapoints that are only available on the client). When the request
is fulfilled entirely by Varnish, the XPP value is replaced with
'backend-varnish-hit: true'.
Change-Id: I8085fdba35c860eaaa4df020d06d1d45d4ea5813
See ApiVisualEditor.php#parsefragment.
Error code is also incorrectly about Parsoid, method
parseWikitextFragment does a FauxRequest to MediaWiki. Fixed
error.info. Keeping the same error.code for now for consistency.
Bug: 52483
Change-Id: Ic473ae4a5c1e9706140f6ec4cc8157fadd02c318
It makes no sense that we should have to pass this by reference but
if we don't do it, we get a PHP notice.
Bug: 52466
Change-Id: Ibc8e33c4776a325cd32b6526dacc200994a73f7f
EditPage has a lovely getCheckboxes() function which includes the
minor and watch checkboxes as rendered by MW core, as well as any
checkboxes extensions like FlaggedRevs might have added. Output
these in the API, render them, and send their values back.
ApiVisualEditor.php:
* Build a fake EditPage, get its checkboxes, and return them
ApiVisualEditorEdit.php:
* Pass through posted request data to ApiEdit, which passes it
through to EditPage thanks to Idab5b524b0e3 in core
ve.init.mw.ViewPageTarget.js:
* Remove minor and watch checkboxes from the save dialog template
and replace them with a generic checkbox container
* Have getSaveOptions() pull the state of all checkboxes in
** Special-case minor and watch, and pass the rest straight through
** Move normalization from true/false to presence/absence here, from
ve.init.mw.Target.prototype.save(), because here we know which ones
are checkboxes and we don't know that in save() without
special-casing
* Remove getSaveDialogHtml(), we don't need to hide checkboxes based on
rights anymore because in that case the API just won't send them to us.
** Moved logic for checking the watch checkbox down to where the same
logic for the minor checkbox already is
* Unwrap getSaveDialogHtml() in setupSaveDialog()
* Access minor and watch by their new IDs throughout
ve.init.mw.Target.js:
* Get and store checkboxes from the API
* Pass all keys straight through to the API
Bug: 49699
Change-Id: I09d02a42b05146bc9b7080ab38338ae869bf15e3
This allows us to make the token no longer a requirement
for non-save actions while still using the built-in system
for token verification.
Update documentation for "oldid" since it is not required even
outside (paction=save). In fact, if we require it VE loading
fails because it doesn't pass oldid unless it has to when
restoring a specific version.
Bug: 50424
Change-Id: I7b1b50a43648b1cc40a984340846efdb0ba2ecc9
