* Remove the hook we used to disable that feature
* Remove CSS that only applied when it was enabled
* Update code comments that referred to it
Bug: T319145
Change-Id: If21a04f6a087289d8249a786f7c991e5e12c9bed
This can be done within sections using CSS:
* mw-notalk
Or at a page level using a magic word:
* __NOTALK__
"notalk" suppresses all comment detection, treating the content as
not containing any comments even if there are signatures present.
Bug: T295553
Bug: T249293
Change-Id: Ic1d7294bafcf7071e16838e70684ecadd7bc6fd3
This can be done within sections using CSS:
* mw-archivedtalk
Or at a page level using a magic word:
* __ARCHIVEDTALK__
"archivedtalk" still detects the comments, but disables features
as appropriate for an archived conversion, i.e. the reply tool.
Bug: T295553
Bug: T249293
Change-Id: Ic47693e9a2f53f92563ccdd50203fb55c12d0493
In local testing, this reduces the amount of data loaded by
Special:JavaScriptTest from 27 MB to 20 MB.
Change-Id: I37f0f677751031cc965d1921a62871154bbe9201
The tracking category is disabled by default and has to be
enabled by overriding the localisation message
'MediaWiki:Discussiontools-comments-before-first-heading-category'.
Bug: T324139
Change-Id: I6e4818e9421f76aec814444b2da9f5d8585c75fd
Some mass messages appear on hundreds or thousands of pages and it's
not good to try to list them all.
Change-Id: Ib903d67ba4fd9d85790ef4271933991b9b6f3834
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
We started using marker comments (HTML comments with special content
inserted into the page) for the reply buttons back in the day, because
we needed to indicate their location in the HTML. Later we used the
same idea for things which aren't actually tied to a specific location
in the HTML, such as boolean data like __DTEMPTYTALKPAGE__. There is a
better way to do this.
This commit stop writing the HTML comments, which are no longer used,
and cleans up the tests.
Bug: T328980
Change-Id: I37541356830945cc9abcc79d4c445ff6f2449759
(cherry picked from commit ab40ef62c0)
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
To avoid affecting existing preload forms, the new topic tool is only
used when the 'dtpreload' query parameter is also set.
Bug: T269310
Change-Id: I4ee024cc4760542790319f302f42b1b2389ac897
We started using marker comments (HTML comments with special content
inserted into the page) for the reply buttons back in the day, because
we needed to indicate their location in the HTML. Later we used the
same idea for things which aren't actually tied to a specific location
in the HTML, such as boolean data like __DTEMPTYTALKPAGE__. There is a
better way to do this.
This commit starts reading from ParserOutput::getExtensionData(),
which was generated by the previous commit, and should be present
in all cached ParserOutput objects by the time we merge this.
Bug: T328980
Change-Id: I9f7a907836b86f25567fd4b352464d62d76e20e4
(cherry picked from commit 0ac420ecbc)
This reverts commit 0ac420ecbc.
Reason for revert: this was supposed to be merged later; revert it now and reapply in a bit
Change-Id: I33fb07856152c2401b3a071c143f27f1e9753287
We started using marker comments (HTML comments with special content
inserted into the page) for the reply buttons back in the day, because
we needed to indicate their location in the HTML. Later we used the
same idea for things which aren't actually tied to a specific location
in the HTML, such as boolean data like __DTEMPTYTALKPAGE__. There is a
better way to do this.
This commit starts reading from ParserOutput::getExtensionData(),
which was generated by the previous commit, and should be present
in all cached ParserOutput objects by the time we merge this.
Bug: T328980
Change-Id: I4bf81ef3fd904f4d920d0756370c9bfa0a10a774
We started using marker comments (HTML comments with special content
inserted into the page) for the reply buttons back in the day, because
we needed to indicate their location in the HTML. Later we used the
same idea for things which aren't actually tied to a specific location
in the HTML, such as boolean data like __DTEMPTYTALKPAGE__. There is a
better way to do this.
This commit starts writing data to ParserOutput::setExtensionData(),
which will be used in a later commit to be merged separately to avoid
issues with cached ParserOutput objects.
Bug: T328980
Change-Id: Ieb7bc3f83a402f9ebb096ed63336c77073bd2e7c
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
Other DT markers are removed because we return the body text, but
in this case we return subtitle text to be inserted elsewhere.
Instead pass $text by reference so it can be modified directly.
Change-Id: I9fe4194681cd3737661dca3c8a16e30a6001bd73
This code was unnecessarily copied from VE. It's not needed for
anything in this extension, and it causes the headings to be treated
as modified by selser, which in turn causes dirty diffs.
Bug: T328268
Change-Id: Ibdbed430f2ff28d0ea2e67644075c1621d9fae53
ParserOutput::getTOCHTML() is being deprecated, and all skins are now
generating the TOC from the TOCData returned by
ParserOutput::getTOCData(). The SHOW_TOC flag was introduced in core
to determine if the TOC should be shown, but Vector-2022 *may* begin to
use other heuristics to determine whether to show the TOC (T315862).
We're conservatively going to process the TOC as long as there is
TOC present to process.
Bug: T328072
Change-Id: I38b439c6752157dbee9b09c9f5443a740dbaabf4
Otherwise, when a transclusion covers a section boundary, both whole
sections are considered to be transcluded.
We already use this method everywhere else (by way of
HookUtils::parseRevisionParsoidHtml), and VisualEditor also applies
the same transformation (mw.libs.ve.unwrapParsoidSections) before
opening the page for editing.
Bug: T327704
Change-Id: I9d8288e2740d816edb9cbc01d7e5642d52c610d3
Change code to match the documented consensus formed on T321683:
https://www.mediawiki.org/wiki/Manual:Coding_conventions/PHP#Exception_handling
* Do not directly throw Exception, Error or MWException
* Document checked exceptions with @throws
* Do not document unchecked exceptions
For this extension, I think it makes sense to consider DOMException an
unchecked exception too (in addition to the usual LogicException and
RuntimeException).
Depends-On: Id07e301c3f20afa135e5469ee234a27354485652
Depends-On: I869af06896b9757af18488b916211c5a41a8c563
Depends-On: I42d9b7465d1406a22ef1b3f6d8de426c60c90e2c
Change-Id: Ic9d9efd031a87fa5a93143f714f0adb20f0dd956
The alias stored in the language files is with underscores,
but the value is compared in CommentParser against text with spaces
Affected languages: bjn, hu, id, jv, kaa, tl, tpi, vi, war
Bug: T327021
Change-Id: I8626627d10a240973e631e24508937a9eee9fb14
We need to be careful about flooding the parser cache with parsoid
content. For this reason, we currently only write to PC for a certain
sample of edits. This logic is implemented in core in
ParsoidHandler::allowParserCacheWrite and controlled by the
TemporaryParsoidHandlerParserCacheWriteRatio setting.
DiscussionTools triggers parsoid PC writes when handling the
RevisionDataUpdates hook, so it should use the same sampling.
Change-Id: Ic33f57b10ae53f431a3c3484c4853e88bf80f47a
Test ServiceWiring.php using tests copied from CentralAuth. Because
phpunit does not support marking a file as covered, the ServiceWiring
file is ignored for code coverage as the tests fully cover the file.
Change-Id: I7da8d74fec84a5aa9c77bc0678ad8f55b550893a
We are seeing a lot of parser cache writes coming from
parseRevisionParsoidHtml. We should find out what is causing them.
Change-Id: I25440e0d759e19cc9769404beb6911c64d37d3e3
* Detect comment separators at the end of comments too
* Consider TemplateStyles associated with ignored templates
This unexpectedly improves a lot of cases other than T313097 too,
mostly where <br> or {{outdent}} was used within a paragraph:
splitting comments that were previously jumbled together, or restoring
content that was previously ignored for apps / notifications.
Bug: T313097
Change-Id: I9b2ef6b760f2ffd97141ad7000f70919aeab7803
Treat non-talk pages as empty ContentThreadItemSet objects, instead of
returning early from execute().
Exclude non-talk pages even if only the rev_id is specified.
If both rev_id and title are specified, use the title from the
database.
Bug: T325477
Bug: T325598
Change-Id: I3947ac94bb7c9a3d24b73c95f0df2cf847c955f2
The parser cache for parsoid output isn't yet ready for full load.
Don't flood it when running batch operations.
Change-Id: I77f3de30b0500f0e5c593f4d31dceef7720f848e
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
Used by MobileFrontend in I78cfb22fbe7d to prevent sections from
auto-expanding.
Bug: T321618
Bug: T322628
Change-Id: I6dafd5b9cb170bfa57f185849db6450162173399
Call ParserOptions::setRenderReason to allow us to track why we render
and in particular, why we write to the parser cache.
Change-Id: If42f802f4cf2da39b06cbb8a30c4dc7d9a663001
If the final content on a page is a heading, there would be an error as
we tried to access nextSibling on a non-existent node.
Also tidies up the case where there's an empty section that's not the
final section. It would have `othercontent` set to an empty string,
which was pointless -- the empty `replies` field is sufficient.
Bug: T321317
Change-Id: Ia58e97214e715c1f6b02c2e045d13f2df7393b80
Inspired by this Wikitech-l discussion:
https://lists.wikimedia.org/hyperkitty/list/wikitech-l@lists.wikimedia.org/thread/NWXPNHRNLEVXHSWX33H473OAWQP6CDOA/
To keep this simple for now, I am only removing redundant PHPDoc
comments on constructors, and only when all the documentation for
parameters completely duplicates type hints.
More could be done, but that can happen later when we have better
tooling. Redundant comments on constructors that take a dozen services
are by far the most annoying for me and I want them gone now.
Change-Id: I86cbf7d6e48035cfa06f780c8fb1b02e68709a0c
Also fix a CSS selector to handle content added in multiple
'OutputPageBeforeHTML' hook calls.
Bug: T323376
Bug: T323833
Change-Id: I480d9bf544d61f0cb7bfd04cadfbf053e7e1b70e
After recent changes (I101c1e84739a2ac1f562f2f7bdc4b8f53d9f3b23 and
Ifbde590ccb6bf3203a2f664cb0d8a73b8d507b78) these methods became
basically the same.
Change-Id: Iedc201e798a5a34713296b20b97ae6cc8b991b66
ApiDiscussionToolsPageInfo and ApiDiscussionToolsCompare in direct parsoid
or VRS modes tries to fetch HTML using VisualEditor thus stashing the
HTML gotten which we don't want, we only need it for viewing in these cases.
This seems like something that was/is already happening in RESTBase. So for
APIs in DiscussionTools that need the HTML for viewing, just get it from
parser cache and not stash it.
Bug: T323357
Change-Id: I101c1e84739a2ac1f562f2f7bdc4b8f53d9f3b23
Ideally this would just not run the hook for any interface messages, but
that condition isn't obviously available.
Bug: T316175
Change-Id: Ibd354eb7a0fb7a316dcbf09e64b80f2d9b4008c8
(Also fix some related CSS that was accidentally moved in
Ie5198e902ec3fa7a7eba56cef6c6f0ef71ef7314)
Bug: T323241
Change-Id: I1fa67965a1b6b827c500a9de63f5b5295bee840d
When a comment almost exactly matches the range of an
accidental complex transclusion consisting only of
pages from the 'Template' namespace and wikitext fragments,
I think we can safely allow replying to the comment.
Even if this turns out to be incorrect in some cases,
the failure will be more graceful after the changes in T313100:
instead of potentially duplicating contents from a template,
the worst case now is that the reply will appear in the wrong
place (at the end of the transclusion).
Bug: T313093
Change-Id: Ie8da09d74a652d893fd8c3e2435ef6cb70fad64a
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
Use revision IDs to break the tie, consistently with MediaWiki (see
RevisionStore::getRelativeRevision) instead of assuming that the
revision we're processing now is somehow both older *and* newer than
the other one (the mind boggles how that ever made sense to me).
Change-Id: I9f1a07124301a36be68578d908353b72f0442c00
isFeatureEnabledForOutput already checks if the mobile flag is enabled,
but it also respects the dtenable=1 override.
Change-Id: I95035281bf301b22c1a9ef4c06ec54cdd0cbc85c
We originally used 'templates' because it seemed like an obvious
choice for HTML files, and because 'packageFiles' requires extra code
to include anything that isn't a .js or .json file.
However, the templates are expected to be HTML fragments rather than
whole documents, and they are parsed in a particular way that takes a
lot of code to clean up (which we needed to do, because we use the
same test files for testing PHP code).
I tried doing it in the 'packageFiles' way, and the extra code doesn't
seem that bad in comparison after all. Moreover, the 'templates'
mechanism (when used the intended way) feels vaguely deprecated in
favor of Vue.js, and I'd rather move away from it.
This makes the tests faster too (probably mostly thanks to the removal
of the clean up code) – on my machine they go from 1800ms to 1500ms.
(Simplify linearWalk tests, as we no longer need to do weird things
with document fragments to get consistent outputs in PHP and JS.)
Change-Id: I39f9b994ce5636d70fea2e935a7c87c7d56dcb26
