It demonstrates how the DiscussionTools extension recognizes
the threads and comments present on a page, to help in debugging
or understanding its behavior.
Co-Authored-By: Ed Sanders <esanders@wikimedia.org>
Change-Id: Idbc90bd8d7742615178331889daae5f94a007fcc
PHP logging code is not moved.
* Use the new mw.track() handlers from WikimediaEvents
* Ensure that 'integration' and 'editor_interface' are set on init
events, since they're not hard-coded in the handler any more
* Remove the setting of 'editingStatsId' tracking parameter,
now happens in WikimediaEvents (by way of VE ArticleTargetSaver)
* Remove code connecting ve.track to mw.track, now happens in VE
This must be merged together with WikimediaEvents change
Iace4d53a972396ca5b8713000570cc47c9986034 (but we can't use
Depends-On, because CI requires code here to be removed first).
Bug: T332438
Change-Id: I0ef0a96aafdf89a4ebe32131a85b18c25744bb2c
Exclude the main namespace unless it allows signatures.
Allow this feature to be disabled via config so
we can do a slow rollout.
Bug: T331635
Change-Id: If46bff5620c5245d5b82653ee96282532fd00c28
Instead of generating the TOC HTML additions immediately, store
the data we need using ParserOutput::setExtensionData(), and use
the OutputPageParserOutput hook to fetch it and generate the HTML.
We check that the stored data is present before using it to avoid
issues with cached ParserOutput objects.
Bug: T328122
Change-Id: I7d4988cd568f10b7995a4d744e0ec6e7ce081b0e
New config: DiscussionTools_visualenhancements_reply_icon_languages
Config is set up with a provide_default merge strategy so we can remove
items from it quickly if need be.
Bug: T323537
Change-Id: Ib748897a2162bb233000f7364e30b268932f4c4a
We wrap a `<div>` tag around the `<h2>`, and move some elements there.
The markup is inspired by and compatible with my proposal for T13555.
The "ext-discussiontools-init-section" class is moved to the `<div>`.
A small patch is needed in MobileFrontend to preserve the section
collapsing functionality: I11bff21e81046898ca63f3f432797129fa70ad88.
The following elements are now outside of `<h2>`:
* Metadata bar
* Subscribe button
* Ellipsis menu (only shown on mobile)
The following elements are sadly still inside of `<h2>`:
* Subscribe links (only shown on desktop)
* Section edit links from MediaWiki core
Trying to move them mucks up the CSS too much. I hope we can resolve
this later as a part of the work on T13555.
Depends-On: I11bff21e81046898ca63f3f432797129fa70ad88
Bug: T314714
Change-Id: I0bbdcfa02c334858737855349d7a35746de1d8f2
Add brackets around the existing shortcut key labels, so that they
don't look quite so out-of-place next to the automatically added
accesskey label.
Bug: T278249
Change-Id: Icc0df5ba036080807ea0eb215f5526c93da78ef1
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
Change-Id: I7244ee4916fb011fad5faa1d9f837e83f6ac2dc1
Follow-up to d0126ce6de which made them
default-on for all mobile. These two taken together mean that the
mobile visual enhancement features now *only* depend on this config,
rather than on whether the individual features are enabled on desktop.
Bug: T318871
Change-Id: If767753e6d33f19bbc540d4e74273e478198388c
We already do this while editing so that users can quickly see which
tabs they are actively working on.
This extends the functionality to the reply and new topic tools.
Bug: T262066
Change-Id: Iae662ad26072617aad71e519bb6c3cbb19ef1246
From in-person code review with Amir: using tableExists() is a bad
idea, because the table might not consistently exists on all replicas.
It's better to have a config option despite the inconvenience.
Bug: T315353
Change-Id: I728759634c454c0dcbdc4603c15cab60415c7c03
It turns out that using the "enableSectionEditLinks" post-cache
transform option was not a good idea, as it is also set when viewing
old revisions and in some other cases.
However, in the pre-cache parsing, we have access to getIsPreview(),
which is exactly what we want. I think we can safely do this there.
We were already using that prior to 2bc76dabd7.
Bug: T314260
Change-Id: I7f769db48eff9fa434483902a4b5ac2f5fc96b3d
We remove the [reply] and [subscribe] links when they should not be
visible (controlled by 'enableSectionEditLinks' option, which is
disabled when previewing).
Bug: T309423
Change-Id: Ie0d3fba2c4d166daac3ea2e117a246c9584284ca
For comments posted on or after 2022-07-12 (configurable), use a
shorter format, identical to the timestamps MediaWiki uses in URLs.
Changing the format for already existing comments would involve
difficult migrations, therefore we elect not to do it.
Bug: T304595
Change-Id: I387051a6a3a1d84cfae45c3e1516db870cc8b977
