These require POST, especially paction=serializeforcachekey because
it calls ApiStashEdit::parseAndStash() which needs a master DB connection.
Move them to the edit module so we can require POST for that one and keep
allowing GET for the main module. This fixes the warnings we currently get
for using parseAndStash() in a module that does not require POST.
Change-Id: I64a8ed7305105fa4c46902b99984306a7ff468cc
Since this extension uses extension.json, it already requires 1.25+ so
no need to keep the old code around.
Change-Id: Iff2eeb2bbfba15c84a4fcec85b6647c28886e9aa
Instead of letting the API formatter set it to empty string if so
or not set it at all if not, have it set to "1" if so or "" if not,
so the JS will handle it correctly.
Bug: T136546
Change-Id: I7308ab1efc1c3060606b61893432b685038192a9
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
* On save, VE will now fetch and append modules and jsconfigvars to the save
event, which respectively contains necessary JS config module data and the
list of required modules to be added on the page.
* The jsconfigvars are now properly added to mw.config on edit save.
* If any new modules are now required by the page after an edit, they will be
loaded by ResourceLoader through mw.loader.load.
Change-Id: Ib3990078a22ad9e46debf3ce174e7cf27b86d944
Non-executable files should have permissions set to 644 – touching:
ApiVisualEditorEdit.php
VisualEditor.hooks.php
VisualEditor.php
Bug: T104044
Change-Id: I73fcee410fa1d538e05a7f494871f20531665701
* At this point the IDs are all known so there is no need
to re-query what was written in the transaction
* This works when recent change insertion is deferred
* Also deferred tagging in ApiVisualEditorEdit to after
the RC row is saved
Bug: T100439
Change-Id: Ic4c7d8d89b8cfeee57eda867c0ff74fa9682ffc8
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
If we don't explicitly pass the revid of the new revision we
just created, ApiParse will be lazy and get the latest revid
from the slave DB, which will probably be out of date.
Bug: T95466
Bug: T94367
Change-Id: I2149c7a710075eff9292d0c25ca40d10b325ad44
It's slow, especially on large pages, and it's triggered
very infrequently these days, and only for known bugs.
In the future we should replace this with a debugging
interface that displays the DOM diff between the original
DOM and the round-tripped DOM, as opposed to the boolean
interface we have now.
By extension, this also means the visualeditor-needcheck
tag won't be applied to new edits any more, although
its registration and messages are kept around because
edits with this tag still exist in page histories.
Bug: T87161
Change-Id: I909153492a5786b4b69fccd42ce3c1d4bdb3a059
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
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
ApiEditPage can give us 'nochange' instead of the
'oldrevid'/'newrevid'/'newtimestamp' keys if we gave it a null edit.
Bug: 73463
Change-Id: Ic22597dfed11de3823471673404090a9bce12928
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
MediaWiki change I2793a3f2 changes API handling in a way that needs
updates to extensions for proper operation:
* needsToken() now returns a string
* Most custom token types are being replaced with a 'csrf' token (the
former 'edit' token); any others need a new hook.
* All tokens must use a static salt. Compat with web UI using non-static
tokens is supported and also serves to handle the now-deprecated token
fetching.
* Documentation in getParamDescription() should return a string (not
array) for 'token', as the signal to core that it should be replaced
with a standardized message.
When compatibility with earlier versions of MediaWiki is no longer
maintained, the entry for 'token' from getAllowedParams() and
getParamDescription() may be removed, as may getTokenSalt(). This patch
leaves them in place.
Note this is intended to be compatible with earlier versions of
MediaWiki, and so should be safe to merge before the core change.
Change-Id: Ia6e512aae366996de4e73a8d7f4f03fcddd77286
This reverts commit b7401f838b.
Didn't break everything, but we should probably avoid this getting deployed until I can work out wtf is going wrong with it.
Change-Id: I048143239e998b30aba79fa395a0af1cb06c6a9b
This reverts commit 5565ccca54.
I have no idea what is going wrong on deployment-prep to cause
the error in bug 66792. Let's try to find out.
Bug: 50341
Change-Id: I5041de838128bb55c57baddae01cdcb263626537
