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
* Only pass the oldid to the API from #load if we restoring from
oldid in the url. Otherwise load the latest version.
* Setting 'restoring' from mw.Target instead of mw.ViewPageTarget
so that we don't rely on mw.ViewPageTarget in mw.Target#load.
* Fix the API to not require 'oldid' to be passed.
* Fix the API to actually return the 'newrevid' property. It
was doing a no-op on a $result that is never used due to the
same variable being overwritten with the result of parseWikitext.
* Moved updating of wgCurRevisionId to mw.ViewPageTarget as it
belongs there (possible future inline editors probably act
on a different page than the main one). Also made it only
update if it isn't undefined, so that a null edit doesn't
result in wgCurRevisionId being unset.
Bug: 49943
Bug: 50441
Change-Id: I221e5038f95eadf6d87013e80f12394f0376a293
* 'captcha' property from ConfirmEdit API is already exposed
in ApiEdit and ApiVisualEditor through the 'edit' property
in our response data.
* Add parameters 'captchaid' and 'captchaword' to ApiVisualEditor
and mw.ViewPageTarget#getSaveOptions. ApiVisualEditor will
forward these to ApiEdit which forwards them to FancyCaptcha.
* We display the captcha through a saveDialog warning.
Bug: 50356
Change-Id: Ia7d2102cba89d00ec8508e846061023b330ece4f
They no longer overlap (except for 3 lines of code). The
double switch case for save/diff 90% of the body being if-save
and elseif-diff doesn't make sense.
Change-Id: Ic6f014393e72901bb5ab4449d946d94b87429e52
The sanity check converts the linear model back to DOM, then
compares this DOM to the original DOM and rejects the deferred
if they are not equal.
The DOM creation has to be done synchronously (before we unlock
the surface), but the actual comparsion can be (and is) done
asynchronously.
To make the UI flow of the save dialog easier we just keep the
save button on the toolbar itself disabled until the sanity
check is done. Though this should finish before the user starts
editing the document (let alone start saving), we do add a class
to the button to indicate a progress cursor.
To simulate a slow sanity check, set the setTimeout in
startSanityCheck to 5000, load VE, make a change, hover the
button, and see it change from disabled + progress-cursor to
enabled after 5 seconds.
To simulate the sanity check failing, change !== to === in
the first "if" in startSanityCheck.
Bug: 47521
Bug: 50067
Change-Id: I04f71fe8e00c6257fbc953cc9de3323e24709b0f
With explicit cache management on the Parsoid side there is no need to send
this explicitly any more.
Change-Id: I34bf3a6ffe631d3350c05ec4c21563f8a734effc
The Parsoid extension now keeps the cache for the current oldid up to date.
Removing the touched parameter lets VE use the cached HTML.
Change-Id: Id025c69060cb9a0bc2478ec49e2c436022049d97
Previously it was just being returned as the diff html, which
looked weird becacuse 1: it was the wrong width and 2: the
save buttons were still there.
Bug: 43754
Change-Id: I537bcae91f51a3f30ca4736c41f7a5619bbf321d
New ID is now passed from the API to the save event, to the onSave
handler. Empty diffs won't generate a newrevid.
Bug: 47420
Change-Id: I12ce27c8dc57f7aa753bcf5840635d5fea6b4e80
Currently this code is unreachable as line 27 of the hooks file
checks the user's options for 'visualeditor-enable' before allowing
VE to load. For testing just comment out that line.
Bug: 47842
Change-Id: Ib5c3284c646ebcc0a8cad0b02de559d7820e05a0
VisualEditor did not send an oldid on POST so far, which disabled
selective serialization in production.
Bug: 47434
Change-Id: Ib1b7079a7fd3357903e5a14795ed0d2f2bdc5d16
Apparently Parsoid has always required this, and we've never sent it,
yet somehow the code in production works. This may well be the cause
of some of the selser issues we saw after the deployment attempt in
January.
Made oldid a required parameter in the API module, and default it to 0.
When we get 0, we translate that to the empty string for Parsoid's
benefit. We also need to explicitly get wgCurRevisionId in
ViewPageTarget, and that's also 0 on new pages.
Change-Id: I3a55025246014cd74e15d6d5b6c4ede7b823e5df
The Status is marked as 'ok' if it completes with errors. We need
to check for the Status is 'good' as well, and if not we can
pass through the error.
MWHttpRequest only sets fatal errors so it can be assumed that if
the Status is not 'good' then there is one error in the error array.
Bug: 45916
Change-Id: Icb2d0253faaf4e00a9a1fe3091458b914e5b7579
Unfortunately the Http::get wapper provides no data if anything but
an OK status is returned, so ApiVisualEditor now uses MWHttpRequest
directly.
If a non-OK status in encountered the error code and message are
passed through to the JSON output, and rendered in the error
alert by VE.
The error code passed through is parsoidserver-http-NNN although
other suggestions are welcome.
Bug: 44354
Change-Id: I166ecf81c40f0f1c62663f2096753269d28f2916