So other extensions can use it, e.g. ContentTranslation.
Eventually we could upstream some of these document
editing APIs.
Change-Id: I1e4925c7302fbe90ab4f9380c5efb83c9c379609
We already ensure any new regular modules are loaded after saving,
and that any changes to jsconfigvars are applied. But we don't
currently ensure styles-only modules are loaded.
Live Preview in MediaWiki core has always done this properly, but
the VE implementation forgot to consider the other two properties.
Issue was mentioned in otherwise-unrelated T156699.
Change-Id: I2e9fedc6dffcac4385ebac27571cc3e4f6fb1542
The Translate extension emits errors when the saved text is in error —
* pt-parse-open,
* pt-parse-close,
* pt-shake-position,
* pt-shake-multiple,
* pt-shake-empty, or
* pt-parse-nested
Switching to 'html' error message format means we pay attention to the top
error, displayed in the user's language. This avoids showing 'editaborted'
generic messages when we can actually help people with specifics.
Change-Id: Id9d7e510e32a3a13cc061648679e01edd68a3868
See Iae0e2ce3. Since VisualEditor master requires core master, this just
depends on the master patch instead of trying to maintain BC.
Depends-On: Iae0e2ce3bd42dd4776a9779664086119ac188412
Change-Id: I0e802a47302725f062334a437bff84e3b2b8b9a6
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
