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
