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
Presumably VE will move in lock step with the Parsoid library but this
retains the ability to negotiate even at this level.
Change-Id: Ice3beabcb1a475f2de9ad61e0f234a9cc23f80bd
Use the new hook to add the diff-mode selector to the area directly before
the diff table.
Also toggles the new inline-diff legend, when the initial diff-type is 'inline'.
Depends-On: I2a3c67bcfa47313dee597e602a62073e4e298cd2
Bug: T324759
Change-Id: I1584a84b3caea9eb142afba976c6ff47650c3832
Currently we only disable the desktop init code when this hook
returns false, but other integrations may want to know about this,
e.g. MobileFrontend.
Bug: T174180
Change-Id: I0268239cc9ea2d397140e617fcb6e4e104a75f31
Also supporting changes to support the new HelpCompletionAction,
including adding a preference to disable it if required.
New changes:
985b553cc Localisation updates from https://translatewiki.net.
aa26e27dc Localisation updates from https://translatewiki.net.
4cdc753ab Update OOUI to v0.47.0
bfc96a7ee Completions: always abandon if the first input is a space
616a6458f Fuzzy command bar
92b6525a2 Tweak the fuzzy command bar's behavior
fd2f048e4 Fuzzy bar: change how command groups are generated
Change-Id: Ic77b8822baecf5ad1ab466d94df29bb945172b55
Add a check of `$diff->getTitle()->getNamespace()` to ensure early
return on NS_SPECIAL pages.
Bug: T336582
Change-Id: I251db11e8cb5b785744ee2c111d20a346937b78c
Use MediaWiki core helpers to provide intro messages (including edit
notices), initial page content, and CSS classes for the edit area.
The following intro messages were previously unimplemented,
and will be shown now:
* 'sharedupload-desc-create'
* 'sharedupload-desc-edit'
The following intro messages were previously unimplemented,
but they only apply to pages where VE should never be available,
and will be shown now when editing those pages with 2017WTE:
* 'code-editing-intro'
* 'talkpagetext'
The following intro messages were previously unimplemented,
and are now explicitly skipped:
* 'editpage-head-copy-warn'
The following intro messages were previously unimplemented,
but they only apply to pages where neither VE nor 2017WTE should
ever be available:
* 'userinvalidconfigtitle'
* 'usercssyoucanpreview'
* 'userjsonyoucanpreview'
* 'userjsyoucanpreview'
Depends-On: If0b05710cb52a977bf4e85947d72d68683a0a29e
Bug: T201613
Change-Id: If26e39e383b983f7ee834ed6dd73b80e0545b068
The DifferenceEngineBeforeDiffTable hook is run when viewing a
diff after switching from visual to source editing, but the
mode selection widget shouldn't be shown then.
Bug: T324759
Change-Id: Ieb8a1b77928201a45635af46635b902cac01a36d
Visual editor is not in beta, and this preference is not temporary.
Change the message key to avoid outdated on-wiki overrides.
Unfortunately the internal preference name still has "betatempdisable"
in it. We should investigate renaming it later.
Bug: T197282
Change-Id: If1475a18474e85cd3a260224c738d087d472af70
The `preload` parameter currently does not work with i18n
messages, as pages representing those messages are known, but
do not exist. Resolve this by running any NS_MEDIAWIKI page
through wfMessage() first.
This feature will be used by Personalized praise in GrowthExperiments,
which requires the preload from i18n messages capability. As a benefit,
it also makes it easier to create i18n'ed preload-based systems
(one can create MediaWiki:Foo, MediaWiki:Foo/cs and MediaWiki:Foo/de);
MediaWiki will select the best language version automatically.
MediaWiki core equivalent is uploaded as
I693bcaf71d7b8557c63538a426d7a6bd4c3edf3d.
Bug: T330337
Change-Id: I961ff7ae2263e61161e686107d80bdafa3fe3c32
As temporary users will not have access to user preferences (T330815),
use cookies or localStorage to save them, like we already do for
logged-out users.
Also add some comments to point out where we intentionally distinguish
logged-out and temp users.
Bug: T332435
Change-Id: Ic83dd8bc8bc107f603a9b0340bd9e2bcaad8ff5a
Visual diffs are always enabled on history pages, there is no
long a need for this to be configurable.
Change-Id: I9cef558b2b9d32bc86c47f6a6095270220d036db
More could be done, but these are the ones that annoy me the most,
and I'm not willing to do more changes right now.
Change-Id: Ia02af09d631fea191e57da75420f0d2d1ed46c19
Use the new hook to add the diff-mode selector to the area directly before
the diff table.
Also toggles the new inline-diff legend, when the initial diff-type is 'inline'.
Depends-On: I6de30bf79eb5ac262285951792782b870d075e00
Bug: T324759
Change-Id: Ifc133856dd793693c3a2722a7b1319dfe74555a2
We're trying to avoid passing raw strings around, since they can be
ambiguous specifiers of language. This patch makes VE compatible
with I982e0df706a633b05dcc02b5220b737c19adc401, with a backward
compatibility workaround which can be removed after
I982e0df706a633b05dcc02b5220b737c19adc401 merges.
The new code also uses slightly more methods of the Language object,
which need to be mocked in a unit test.
Change-Id: I830867d58f8962d6a57be16ce3735e8384f9ac1c
These haven't been used for a while, and we usually enable experimental
features via BetaFeatures these days.
Change-Id: Iec3a7da3cc962d8ac9416b508780fcdc3ca58d3e
Helper classes have been moved to a dedicated namespace
of their own, this patch references the new namespace.
Depends-On: Ieeb7a0a706a4cb38778f312bfbfe781a1f366d14
Change-Id: I5a2792a3536f6d953905561410f0e4966254ccbe
Catch HttpException from REST helpers, even when they are triggered
already during initialization. This will happen e.g. when the request is
asking for a render key for which the stashed rendering has expired.
Bug: T325310
Change-Id: I9e622b5bb253f5e40fe2b50ff08471beddac9acf
This isolates this extension from knowledge about the constructor
signature of the helper classes. Constructore signatures are not stable
interfaces.
Needed-By: Ie430acd0753880d88370bb9f22bb40a0f9ded917
Depends-On: I10af85b2da96568cfffd03867d1cb299645fb371
Change-Id: If1914dbfbefc3501b4d4cef4beb1fae307c36455
We want to be able to measure how backend performance changes
when we switch from RESTbase to calling Parsoid directly.
We expect to see a performance boost, in particular for
html/to/wikitext, since we avoid the network overhead.
Since we will make the switch by wiki, we need to be able to compare
the metric before vs. after for a single wiki. So, this adds the
wiki ID as a prefix to all existing metrics. Once fully rolled out,
we should get rid of the wiki prefix.
We will need to update the dashboard found at this url:
https://grafana.wikimedia.org/d/000000249/edit-stash?orgId=1
Change-Id: Iac9070b27f4b0d25b0e31c9fad38abc08c433a28
When using DirectParsoidClient, switching should be lossless.
Depends-On: I86c611fa0b717ef619e5ffe550b6c2be49a28c99
Change-Id: Ie30ccbc8c12ce48f481b9f727f28e60d21ee37b9
* Rename imported classes in VE that will be renamed in core
* Re-enable tests that would fail when the core patch is merged
Depends-On: I506f3303ae8f9e4db17299211366bef1558f142c
Change-Id: I59ebeb24fa0de5f10d1501cc0830c7e4805e1003
When receiving HTML from a VE session, process it with the same kind of
ParsoidClient that was originally used to generate the HTML. If we were
to use a different implementation, the ETag wouldn't match, so we would
fail to find the stashed data-parsoid map, and the edit would fail.
Bug: T320704
Change-Id: I3b73431fccacecb4ad88b82f8f5675b1042e03ce
AutoConfig was used to set VE to call internal REST API endpoints exposed by the parsoid extension.
With DirectParsoidClient available, this is no longer needed.
NOTE: this causes all wikis that do not have a RESTbase backend
configured to start using DirectParsoidClient. This is true in
particular for officewiki and labswiki.
Bug: T320704
Change-Id: Ia4c6184dd75a653c3202ea160b6605335f36f6eb
If VE is configured to call parsoid directly in PHP, the client
should not try to fetch HTML from restbase. Doing so will
lead to inconsistencies, and may cause edits to fail.
Bug: T320704
Bug: T320703
Change-Id: I98bfdd305dcd188d91db6a8fe5885156cdeca7db
* DirectParsoidClient makes use of parsoid directly for performing
transformations on both wikitext and/or HTML contents.
* Also, it's used to fetch HTML from parsoid's parser cache. Before,
this operation was done via RESTBase but now it's being fetched in
core's parsoid parser cache.
* This patch also enables VE clients to transform HTML to
Wikitext when switching from HTML to source mode on. It
makes use of the HtmlInputTransformHelper to perform this
transformation.
* Now, VE client can make use of core code for switching
between HTML to source mode and back without RESTBase.
Change-Id: I5c7cfcc4086d8da7905897194d8601aa07418b59
Part of my secret plan to delete ApiParsoidTrait.
* Inject RevisionLookup into ApiVisualEditor
* Use RevisionLookup::getRevisionById instead of ApiParsoidTrait::getValidRevision
* Use RevisionLookup::getRevisionByTitle instead of ApiParsoidTrait::getLatestRevision
* Use standard MediaWiki error messages
* Delete unused ApiParsoidTrait::getValidRevision
* Delete unused ApiParsoidTrait::getLatestRevision
Depends-On: I7244ee4916fb011fad5faa1d9f837e83f6ac2dc1
Change-Id: I8089c0c516d9dba52e931a0a80740c0361216dbd
This VE paction was removed in I90d775dd71d5f5a61d651b63d946ab60a27e2ca3
so this code can be deleted per Bartosz, so this patch removes the code.
NOTE: A merged API test that uses this is also removed along side.
Change-Id: I4ff75df57fd58f508ef7212486e52cb11a7cfb57
* DirectParsoidClient: Actually allow null to be provided.
Previously we tried to call methods on it unconditionally.
* VRSParsoidClient: Require the param to be provided (even if null).
No reason to diverge from the interface, which requires it.
Change-Id: Id9a450dc8b8eb3e82cf87718b96975e5a3c6180c
This follows up the initial fix with additional sanitation and a
regression test. See I21c7a2b2541061a858a9791a2cb12866acd38dc5.
Bug: T318083
Change-Id: I4e433e711c068336a888f4aafa243455764fd710
All code that used to live in ParsoidHelper has been moved to
VisualEditorParsoidClientFactory and VRSParsoidClient.
ParsoidHelper is no longer needed.
Change-Id: I21c4a8cd86f8d085e75a601ed6d2509dedd75d42
This makes the "direct" client and the VRS based client
implement the same interface, so the caller doesn't have to know
which one it is using.
It looks like ParsoidHelper will not be needed if we use this approach.
Change-Id: Ib1c1d7355951fc0765227dd01a9edfc554fc448d
In order to make this interface cleaner and not promote the
use of optional parameters when not needed, make the factory
required so that callers should worry about it and not overwork
the helper.
In this case, DiscussionTools extension is already using this
interface and has the factory injected appropriately.
Depends-On: If682af406c0fc7a9eca106eb3ebd95e6c14baddd
Change-Id: I836c0ad73687d8b99d1e067a5c3a3e512b4bd37a
Getting the correct client is now done via the VisualEditorParsoidClientFactory
so this is no longer needed. Follow-up of: I787c0afb227308aab56770d.
Depends-On: I4b9e7362a1bf1b4f224c8c652d40851a18c19824
Change-Id: I175aef2326a0d784fb8211542a3fe90cbf6c6d08
This patch introduces a factory service for creating VE Parsoid
clients.
NOTE: This patch also injects a GlobalIdGenerator to the client
and avoids usage of deprecated UIDGenerator class.
Change-Id: I787c0afb227308aab56770d14d62e08eb0084a6c
Follow-up to 951348dbbf. When creating a
new page on a RESTBase wiki, ETag is actually expected, but it will be
in a different format; the code comment was wrong.
Bug: T316969
Change-Id: Ia36488616ced70b900d2e67ce8e28993cc2c7514
While a missing etag on a RESTBase wiki still indicates a problem,
we worked around these problems long ago in T233320 and we don't
really care about the logs any more, and the logging is now dominated
by requests on private wikis where etags are not expected.
Bug: T316234
Change-Id: I4cc29847524863af2c5642cb60371893533a9df8
For error responses, the response body should be JSON containing a
'detail' key with a human-readable error message.
Remove old debug logging for T233320, it's no longer needed and it
stopped working on WMF wikis anyway (again, previously it was broken
due to T234564).
Change-Id: I64d0b934c90c7e9582e5433ae7a1b9ed2bc0c9a2
Introduced in FlaggedRevs with Idbdab9a7396 (6bfd276e64), and I've
migrated consumers away from the singleton in I192b962147 (5ee96e5ca7)
and I04fdbd497b8 (bbdfc4c024).
The one thing that remains global by default is the context, but
VE already avoids that with setContext, and (correctly) restores this
afterward since the FlaggablePageView object is re-used by title.
That's exactly as terrible as it sounds, but at least it's a bit more
visible after my refactor.
Bug: T314008
Change-Id: I0008818ec821c35c570d9db9c82f737783e6729b
We can simplify the code in Hooks.php to use revision.rev_actor
unconditionally, reverting 391c30da67
(the migration is done: T275246).
Bug: T312472
Change-Id: Iaab268409ec4ad0a8d3a835057321aa3c01a2cc7
ApiParsoidTrait depends on some ApiBase methods, which is inconvenient
when one wishes to access Parsoid HTML outside of the action API. Move
the bulk of the code into a new class ParsoidHelper, which doesn't.
Replace the uses of methods:
* dieWithError: throw a different kind of exception where it makes
sense, or change the method to return a StatusValue instead of
throwing where it doesn't
* getPageLanguage: use Title::getPageLanguage() or pass as parameter
* getConfig: pass to constructor
* getLogger: pass to constructor
* getRequest: pass the only required part to constructor,
leave some other API-specific code using it in ApiParsoidTrait
Bug: T314565
Change-Id: I90656cc74bb1cb1f2f3c82ad51cfb164cb8a4a4b
This is send as an associative array. Instead of adding elements that
are null we can just not add them.
Bug: T291729
Change-Id: I28d847941eec865cb255779534eca14ec88f588f
Before, permission editnotices didn't have access to the page titles, so
magic words like {{PAGENAME}} would give a subpage of Special:Badtitle. This
formats the message in the appropriate context.
Bug: T313372
Change-Id: I93894a4fc129de9da4b120c084b1d343b4021cdd
visualeditor-dialog-media-thumbdimensions
Added in 2014 via I7b4d019, but never used, as far as I can tell.
visualeditor-dialog-media-searchselect
Unused since I65aed34 from 2015.
visualeditor-dialog-meta-settings-displaytitle-enable
The feature was removed in 2017 via I46db6b1.
This patch also marks some other messages as being used via comments.
Change-Id: Ia10b6a5c0ea83dd670e2cfdbaa768c41fc0cf392
Remove WikiFilePage instance check, isLocal exists also on WikiPage and
newFromTitle never returns null
Bug: T297688
Change-Id: I925771a84afe4402fdb0f201c0b562c7028c44b2
Web team plans to deprecate the SkinTemplateNavigation
and SkinTemplateNavigation::SpecialPage hook. The
Universal hook can cater for both cases.
Bug: T255319
Change-Id: Ifad4918cf5d3d6b3f4d7abeb48d27fc5a46764b3
I suggest this as the first, most minimal step. This allows us to
slowly remove all the code that uses this flag without breaking
anything on wikis where the feature flag is not enabled. In other
words: this patch turns all code that expects this flag to be false
into dead code. We can then slowly remove said dead code.
Bug: T289049
Change-Id: I523978f7ca72dfc1cc7b64741e2f4f20ed3adfb7
Following the MediaWiki changes from T301203, we should use
the messages 'skin-view-edit' and 'skin-view-create' instead
of 'edit' and 'create'.
(Also remove redundant definitions in extension.json, we load
all messages listed in 'VisualEditorTabMessages'.)
Bug: T310529
Change-Id: If055fa2a4dc009be869425e6c2262c9b62056179
