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
Turned saveDialog-body into slide-based swapper.
Moved footer into saveDiaog-body so that the license text doesn't
stay under the diff-slide (and move body bottom padding to foot
top)
Wrapped buttons and title in a saveDialog-header and converted
closeButton from absolutely positioned to a floated layout.
This way the title doesn't need to be repositioned but will scooch
over if the prevButton gets shown/hidden.
Update API "diff" action to include table wrapper and table
header. Without it the mediawiki CSS for diff doesn't work
properly (needs colgroups for proper width of the "-" and "+" column etc)
Renamed -saving class to -disabled for consistency.
Set prop.disabled to really lock/unlock buttons, not just visual
(otherwise the click handlers are still triggered on click, can
potentially cause actions to be triggered when not expected)
Using a ve message for "Show your changes" title instead of
re-using core tooltip-savepage in a different context.
Diff slide triggers "auto width" on dialog (inline undo of width: 29em), keeping min-width, to allow it to expand as wide as needed.
Functions that I copied as base for onShowChanges and
onShowChangeError had some incorrect argument descriptions. Fixed
in both.
Note:
* Pass function to .off(), so that only that one is unbound
instead of any "resize" handler on the page (by other extensions
or gadgets or core)
* NB: ve.bind ($.proxy) preserves internal guid, so that $.Event
can find the bound function by the original reference.
* keydown has an anonymous function, should either moved to
prototype or namespaced, did latter for now, save enough and
better than destructive .off('keydown')
Change-Id: I9d05ef6e3e2461bdcf363232f7b0fbad5e24f506
ApiVisualEditor
* Reverted some of I223235a6ea8b4178c50beeaaedb709b2de7cf0b5 turned out to be full of problems - the race condition is only relevant to getting the HTML
* Fixed check for $content to be false before it was defined
ve.init.mw.ViewPageTarget
* Reverted some more of I223235a6ea8b4178c50beeaaedb709b2de7cf0b5 - wgCurRevisionId is not equal to oldid, it's equal to $title->getLatestRevId() - this was causing lots of oldid problems
* Added use of restored message
* Made save button not locked when using oldid
* Customized save buttons depending on oldid
ve.init.mw.Target
* Reverted even more of I223235a6ea8b4178c50beeaaedb709b2de7cf0b5 - we don't want to keep a copy of the wgCurRevisionId at all, we just want the oldid if it was given
VisualEditor.i18n, VisualEditor
* Added restored notification and restore save button label messages
Change-Id: I8b30c2a153911f44643e369b7c6a9b89c0fb2c5b
Use mw.config wgCurRevisionId for oldie instead of uri query.
That way it also set on regular views, and as a bonus it the
normalised value (e.g. if on a page with oldid in query but the id
doesn't exist or is somehow invalid, it won't use it).
Centralise page existence logic in JS and rename Target.oldId to
Target.pageRevId (to further indicate that it is always set, not
just on oldId views. To detect an oldId view, do a boolean check
on value from currentUri.query.oldid directly).
In PHP Api, move oldid logic to execute() method instead of
locally from the getHTML call. That way it is always set, avoids
hitting this bug in other methods instead of just getHTML().
Since the mw.Target constructor now retrieves the ID from
mw.config directly, the second argument was removed.
Change-Id: I223235a6ea8b4178c50beeaaedb709b2de7cf0b5
ApiVisualEditor
* Including notices in response to parse actions
ve.init.mw.ViewPageTarget
* Added styles for editNoticeButton and editNotices
ve.init.mw.ViewPageTarget
* Added toolbarEditNoticeButton and toolbarEditNotices
* Combined toolbarEditNoticeButton and toolbarSaveButton setup
* Moved toolbar buttons setup to onLoad (it could vary per-parse now)
* Added tearDownToolbarButtons which fires on deactivate
* Renamed some instances of teardown to tearDown
* Added click handler for toolbarEditNoticeButton
* Added toolbarEditNotices setup method, called on load
* Made notices fade in and out, in by default on load if any
* Made notices hide when save dialog is opened
ve.init.mw.Target
* Added storing of notices on parse
icons, alert, ve.ui-Icons
* Added alert icon
VisualEditor.i18n, VisualEditor
* Added notices button message
Change-Id: I581bf5a005a9c18422f952d71064d17d0ba9b540
ApiVisualEditor
* Added basetimestamp and starttimestamp to all methods where appropriate
* Added new serialize method which converts HTML to Wikitext
ve.init.mw.ViewPageTarget
* Added edit conflict handling
* Moved form value reading code into getSaveOptions method
* Prevented edit warning from appearing while submitting
ve.init.mw.Target
* Added serialize and submit methods
* Fixed some documentation
* Added support for baseTimeStamp and startTimeStamp
VisualEditor.i18n
* Added edit conflict confirmation box message
VisualEditor
* Included new edit conflict message to resource loader module
Change-Id: I002c5aa23704c1c46ef46fa1970a4254614b9eb1
Uses MW's built-in change tagging. Made this configurable so it can be
turned off if it looks like we're blowing up the tags system with the
volume of VE edits.
Change-Id: I63052d90772906e34021035de496a65fea7945f7
