Ib70e4e67e4cb1b65ac218c095864fb6eb43d0929
changed the type of the last parameter of
BeforeInitializeHook::onBeforeInitialize
Bug: T354216
Change-Id: Icd9e2a70fe001aa706b4059236b93db2eeb79369
Despite outwardly behaving just like a Message, in fact MessageValue
stores its parameters in an incompatible way.
Bug: T352012
Change-Id: I16c64cdc8c2795536579c52a0aa21832900d96b6
User-options related classes are being moved to the MediaWiki\User\Options namespace in MediaWiki Core; reflect that change here.
Bug: T352284
Depends-On: I9822eb1553870b876d0b8a927e4e86c27d83bd52
Change-Id: Ifb380012959b5b2853586cd25b0d003b53dc38eb
We diff only on provided wikitext. This was causing inaccurate diffs on
pages with slotted content (e.g. File: pages on commons), which would
claim the edit would delete all the slot contents other than the
wikitext in main.
Also, remove the very old backwards compatibility params that were being
passed to getResultData in this method.
Bug: T351235
Change-Id: I135082162b96503e8d896aa4014abc9f4b936580
Since Parsoid now treats DEFAULTSORT like any other template, we have to
scan mw:Transclusion spans.
Bug: T337398
Change-Id: Icba92fc14c1c56ec4711ba49407e8be368d57842
According to EventLogging 'editattemptstep' data the error hasn't
happened in the last 90 days.
It probably can't happen since we switched from RESTBase to direct
Parsoid access, but keep the checks as assertions just in case.
Change-Id: I0bad1e4364c2f1b154383bc1a984c4ccc83e1700
This also removes double escaping from the messages as 'options'
for type = select gets escaped by the html form
Change-Id: I31cc19cbe1f6e61849f3ff806e53a14082e06849
This introduces an extension attribute EditIconSkins which allows extensions
or skins to request the rendering of edit icons.
This will be used by Minerva in I3c9d59f49f1b939981a7b2b450448db6736d5958
Bug: T346944
Change-Id: I401805224c0f387ac85b52b50c1f298b83c03a91
There's no product need for anything other than an upper limit
on edit count. If one arises in the future we can adjust accordingly,
but better to keep the JSON, and any UI implementation, simple
for now.
Change-Id: I892847ad78b19695f0f0f664002d3c566f7806de
This solves a conflict with RevisionSlider, in which navigating
between diffs caused inconsistent rendering depending on whether the
user first entered the page through a diff with or without a
text-slot change. After this change, the ResourceLoader modules are
always available.
Module initialization seems to be safe to run on non-text diff pages.
Bug: T344596
Change-Id: I936d45a132dee3a044a52e22c4751c0538a5bcdc
This creates a message called `editcheck-config.json` which will be
loaded and sent to the `modules/editcheck/config.json` packageFile.
Bug: T330112
Change-Id: Idc58ddf1045fcc0491701a739f3778c8cf4dd955
Abortable promises are definitely among my least favorite things.
It takes all of this bookkeeping to make .abort() work consistently
(so that it always aborts a request if one is in flight, and always
causes the final promise to be rejected even if we didn't start a
request yet or it has already finished). But, if you squint and ignore
every line with the word "abort", it's like a normal promise chain.
Depends-On: Iec8a15dadd595bed0f7e54f907fbb8e192b45cf3
Bug: T331397
Change-Id: I67309c79e6d211d69630fe89cbf5402f8fbd350c
* Remove full stop. No other preference label has a full stop.
* Mention "2017 wikitext editor" as the alternative name, similar to
WikiEditor (I6d17359166f58811ba99893ce4a4500a87deb827).
Change-Id: I48f64f1507b263da61c8a5711afc8ac4981763ee
Don't use RawMessage, the API error formatter doesn't know what to do
with it. Instead call dieWithException(). These exceptions probably
shouldn't bubble up here, but we can worry about that later.
Bug: T344173
Change-Id: I3d1645a3580feeed6fe1431a7bfcdc584f681061
After catching the REST exception, just throw an API exception.
Remove the step inbetween where we built a response array.
Bonus:
* Remove tests that only tested this array building.
* Remove the unused 'code' from successful responses, and update
documentation of return value shapes.
* Remove impossible check for `$ex instanceof LocalizedException`.
After moving the code into one place, it's obvious that it can't
happen, since LocalizedException doesn't inherit from HttpException.
Bug: T341613
Change-Id: I31370efeed9d5283b53eafca102b2f1efc811d27
- The code in the hook handler is more related to the hook and the
structure of the $links array as to the special page.
- Loading another class to process the hook is not necessary.
- Allows better migration to new hook handlers (special page classes and
hook handler should be separated).
- Replace SpecialCollabPad::getSubPage with
SpecialPageFactory::resolveAlias.
- The local url to Special:CollabPad is now in the content language
(only relevant for non-english wikis).
Change-Id: I82985a8ba129b4e336cee337af31452e804090b3
After we removed other clients, the $response array can only be
generated by DirectParsoidClient::fakeRESTbaseHTMLResponse(),
which never includes a fake 'x-cache' header in the response.
Bug: T341613
Change-Id: I90bcb1e26e4164f8f4a34da3abcb01ac0769e21a
Why:
ApiVisualEditorEdit passes most of its params down to
action=edit. However, $params contains parsed version
of the params. Using it with tags results in the param
validator logic on ApiEdit's end receiving a PHP array,
which it does not expect (neither it should; it is impossible
to pass one via an actual API call).
This feature will be used in DiscussionTools,
which itself reuses ApiVisualEditorEdit.
What:
Use WebRequest::getText() to get the unparsed
value for 'tags', which makes the parameter
forwarding actually work.
Bug: T343339
Change-Id: I0ac60ca8473fe28461b2da60f9911baac4994388
I've verified that no other extension uses this code apart from VE
and locally tested that with this patch, VE still works and nothing
explodes.
There parent patch takes care of making sure the mode is no longer
injected and we now have just etags with no hacked in modes because
we now use direct mode always.
Bug: T341612
Change-Id: Ib1756bf60104467a3a34be9bbb06d8f63537e550
In order not to break clients who already have VE open with etag
that injects the "mode:direct..." in their etag, let's first stop
injecting the direct mode to subsequent VE sessions (for edits)
and wait for 24hrs+ so that we're sure we've processed all sessions
with the direct mode etag.
After 24hrs of this patch merged and going live, we'll then remove
the DualParsoidClient entirely as the p.2 of this cleanup.
Bug: T341612
Change-Id: Ie4f43089ee6f94f51fc0398e84604a17bc5bebcf
This patch makes the following assumptions:
1. There is no class outside of this codebase that implements the
ParsoidClient interface. According to CodeSearch this appears to be
correct.
2. It is fine to use the Bcp47Code instead of the internal MediaWiki
language code in the "Accept-Language" HTTP header. As far as I
understand this might even qualify as a bugfix.
Depends-On: If059674597e261039df7f4613a89cb08120c3262
Change-Id: Icd160da2d5555891b9a91a0cb966bd36a55f6fdd
This follows the event of VE no longer using RESTBase anything. All
actions related to stashing and Parsoid and now handled in MW core.
Bug: T339227
Change-Id: I50b20ed5abb721a6ac8987cac37a6f395a4816dc
Setting `$wgVisualEditorUnifiedPreference = true` makes the VE enable
preference appear consistently on the preferences page, while still
being backed internally by the old 'visualeditor-enable' and
'visualeditor-betatempdisable' preferences.
(It effectively overrides `$wgVisualEditorEnableBetaFeature`, which
needs to remain unchanged to use the values from the right preference.)
Bug: T335056
Change-Id: Iad710a769c7176c4673c475d540dff2b7782e159
Previously, this code relied on 'visualeditor-enable' being set to '1'
when VE was opt-out (so not using that preference). That default does
not make sense for a beta feature (which uses that preference), so WMF
config was overriding it to 0 when the beta feature mode was wanted.
Instead of making assumptions about the default values of preferences
that depend on whether beta feature mode is enabled, just check the
beta feature config.
I also added and updated comments documenting this preference.
Previously I never really understood what it was for, and I think
I figured it out now.
Bug: T340696
Change-Id: I45eef42939149ff5be63bf299c48ef70ee535e76
This reverts a change from 5a792b6558. The hook only requires
a PageIdentity, and we only used toPageRecord() because it takes
a parameter to read latest data, and toPageIdentity() does not.
Instead call another method to update the internal data within the
Title instance. Maybe it's not great to rely on this side-effect…
Bug: T340568
Change-Id: If9cbd95eb84b6c39bf50af4564710839628a9bc3
React to hooks fired by core when the inline diff type switch is
present. VE needs to be able to disable the inline switch
when 'visual' mode is selected and enable the switch when 'wikitext'
mode is selected. When the 'wikitext' mode is selected and there is an
inline switch, the interface needs to show the diff type format previously
selected.
Toggle using new `mw-diff-element-hidden` class that is used by core so
that there's no clashes when hidding and showing the diffs.
Bug: T331589
Depends-On: Ie6a48e495f2bb299d8b984e7c40363d534c7915b
Change-Id: I4f790370dbfeb521f3b61c4d604245f77094abe9
After the demise of RESTBase we are always able to switch from
wikitext to visual mode with changes, and we no longer need to
support these two poor experiences.
Bug: T339871
Bug: T339872
Change-Id: I2be4068447b21e16c87db0e56d6422ea64ba4708
Sometimes we call this API and then reload the page (or navigate to
another URL), without using the page content it returns. Save some
work and some data transfer and don't generate it in those cases.
Change-Id: Ic5fac61f3ef9b2dfce6ff757f1d414a9f41f217d
Having per-wiki statistics is neat but expensive. Now that VE has been
switched to not use RESTbase on all wikis, Go back to collecting
all stats under a single key. The relevant dashboards have already been
adjusted accordingly.
Change-Id: I9666bfa3fed547f3f619a9e0c9c24b9240edc359
There are no occurrences of the error message in our error logging
data, so it most likely can never happen.
https://superset.wikimedia.org/superset/sqllab/
```
select count(*)
from editattemptstep
where event.save_failure_message = 'visualeditor-docserver'
```
Change-Id: I8172564057418283468c657cbc6d42ce8ddb35f4
This will ensure that media have the mw-file-element classes so that the
styling changes in I70c61493fe492445702f036e5b24ef87fc3bdf43 apply.
Older 2.7.0 content still in storage is missing the classes and doesn't
render correctly.
Note that I545ed75ed3c87e88b5e776696754e23c05645f81 made sure that
editing of both versions was always compatible.
Bug: T337596
Depends-On: Ia70f819df79fbb12a5b1dd6a98bfe0b968808d18
Change-Id: I40ed887e03f983e0737e1ee7cba5a4012fea31db