The 'eye' icon is in the 'accessibility' pack, not 'alerts'.
Compare to the dependencies of 'ext.visualEditor.diffPage.init'.
Change-Id: Ie14ab6be756fd9e0bef59475466674a41273046f
No longer needed after Id36aa6bdb8f873fe7deb8123a7fc774103721c01,
which teaches SpamBlacklist to return its own error messages.
Depends-On: Id36aa6bdb8f873fe7deb8123a7fc774103721c01
Bug: T211443
Change-Id: I462c2002f9b596cbdfd7ce3673d4e362e5bd1aaf
Unnecessary suppression causes build failures. Probably fixed by the
EditPage.php changes in e2e543f7c2a98f40c9b43ba3989d0f6689f4cb67.
Change-Id: I2ac7e95886ce6bef2ba08e1614728caae7d26442
Context items can be created for specific template titles. Titles
are mapped to context items using an on-wiki message.
Bug: T211243
Change-Id: Icfc39e350452da238d0e0c17cb2305c60d9ca16a
New changes:
1a7460058 Remove ve.newMobileContext feature flag
Local changes:
* Remove ve.newMobileContext feature flag
Change-Id: Ia8def997b7cba4623866080752b06068d2118cc3
* Change the query in ve.init.mw.ArticleTargetLoader#requestParsoidData
so that in non-RESTBase mode with wikitext it still returns the
metadata required to initialize the editor, using the backend API
code added in I1b35b28e428a1f86d2e34d90ddbe73361ce14818. This fixes
the exception from T222312.
* Introduce new configuration option $wgVisualEditorAllowLossySwitching
to control this feature. It is enabled by default, fixing T214542.
We allow it to be disabled because switching in non-RESTBase mode may
cause "dirty diffs" (non-semantic changes to the wikitext), which are
undesirable on wikis where users carefully review all changes.
Bug: T214542
Bug: T222312
Change-Id: I58879cba5612002c70c24731306214d2577c2c52
In general action=edit could be bound to a wikitext-specific
edit link, but in the case of redlinks we can use the
preferred editor instead.
Bug: T223793
Change-Id: Ib0851e9e2ce441ae93311153801e2c3de0a2063d
We don't currently support it in NWE. It has a very different design
for previews that wouldn't really do what users expect. Let the old
editor handle this.
Bug: T195914
Change-Id: If0c0312347c212447bd8da7336c80bd4a1cb246a
There are various circumstances where the wgIsProbablyEditable check
gives incorrect results (hence the 'probably'):
* User is blocked (T111217)
* Page is protected from creation (T173763)
* Page is transcluded on a cascade-protected page (T217217)
Bug: T111217
Bug: T173763
Bug: T217217
Change-Id: I7df8909c31f29d2e7521bef8612c27cb61146a4d
Prior to 80bfbfc54b this worked by
accident, and with a number of bugs depending on your settings (see
T219457). It turns out that Wikipedia users have invented various
workflows that depended on this bug (mostly involving sandbox pages in
namespaces where VE is not enabled). Restore it as a supported
feature, and in a way that avoids the problems it previously caused.
Bug: T221892
Change-Id: I62714b6f2905efd1d1b34c7a13b9917cb6c609fc
Use an API 'parse' call with a sectionid to trigger
a full document expansion using replaceSectionAtRev.
Then send this off the RESTBase to convert to HTML
and statsh.
Ensure the etag is passed back to the API response.
Bug: T117716
Bug: T223023
Change-Id: I1b35b28e428a1f86d2e34d90ddbe73361ce14818
This is necessary to allow the unmitigated removal of
ApiQueryUserInfo::getBlockInfo to be fixed. See discussion on
I84ed21641c44b2f65.
Change-Id: I9f40666a31bd4af50762c197c2ce5bf089a5e68c
The method ApiQueryUserInfo::getBlockInfo() was removed in unannounced
breaking change in MW core: I84ed21641c44b2f65ebe1980b0893d1846db3b34.
Apparently we're supposed to use the method from ApiBlockInfoTrait now.
Bug: T209599
Change-Id: I7ab5492310980b1527c7329faf65655330b8bef0
RESTBase is changing the way it is storing HTML/data-parsoid renders. In
order to still support VE (and other editors) with quick access to HTML
and matching data-parsoid (needed later for transforming the modified
HTML to wikitext), VE now needs to let RESTBase know it intends to
perform a transformation call later on. In that case, RESTBase will make
sure to keep the matching data-aprsoid around for long enough.
Bug: T222639
Change-Id: I02672e29bd0f331794fd77d9e56f9cc6822d9b9e
Is replaced by MediaWikiServices::getInstance()->getConfigFactory().
Also, did a few minor cleanups where necessary such as; objects are
passed as references by default etc.
Change-Id: I42cd242ebdbc0b091a99e771289020d498bf2bba
Mobile builds its own block message from the block information,
rather than using parseAsBlock.
Bug: T209599
Change-Id: I8b200f258b50f7048aded22ec7ab81a49937c5a9
This is a clean up after collecting the necessary data related to
blocks and how often users see the block notices
See: https://phabricator.wikimedia.org/T189724
Bug: T214214
Change-Id: I532a0cd95009109ba25caa8dd31badd5c1900da7
This check currently requires LCStore, MessageCache, and (sometimes)
Database to involved to check whether the message and/or local override
exist.
Using `useDatabase(false)` should take away most of this cost
by no longer performing the multiple Memcached/Database roundtrips,
and leaving only a cheap in-process check on LCStore.
Bug: T221294
Change-Id: I6bf47cd84cdf9bfdd63bee0a613425bb79595e4f
The latter is being deprecated as of I74a9535918e because it was
almost never used intentionally. When module objects are created,
the appropriate context object is injected via setConfig. That is
the one the modules should use.
The context object has a reference to the ResourceLoader object
(although unsure why actually), but shouldn't be used for this
purpose as there could be a 1 to many relationships further down
towards modules.
Change-Id: Icab0f12141a46476618f984d4548a82fdae33275
For a while now, the 'ResourceLoaderRegisterModules' hook is
the last oppertunity to register modules. Therefore, the
isModuleRegistered() check covers everything it needs to.
In addition, at this point modifications to ResourceModules would
be ignored even if it did contain additional entries.
Change-Id: I77714fca0f561f5817a45dd3be5fd8d3ba42f969
These do not vary by user or page, and can thus be loaded asynchronously
via the startup module, rather than blocking rendering and fetching
of modules on all pages.
In a future change, it might be better to go a step further and bundle
these with a module so that they only load as-needed instead of still
on all page views, but this should be an improvement nonetheless.
Change-Id: Icae3712ac5546a90bc7ffd787b0f3285dff6a26f
Remove overkill $VisualEditorSerializationCacheTimeout config setting
and just use a simple constant instead (convention over configuration).
Bug: T203786
Change-Id: I94424088a03a3262fcea30132883a612465c546e
