This will let us render reply links on wikitech and run visual diffs
(which runs in anonymous user mode). This will be reverted after
the visual diff test run.
Change-Id: Ibf175a7f5b1e68f66c257fc26ba9e4b55f752fbd
This data was added to core in I328f533e6cdb11c0c3a873d23bab1a113dfa39be
and it will have been in production for 4 weeks next week which is
enough for all content to have rolled over.
Change-Id: I3d568eed56446f26aa329bfa554d609b8bcb973a
This reverts commit 7aaaf51dfd.
Reason for revert: This is not right and doesn't work either.
See T351461#9358034 for why this strategy will not work right now.
We need a different strategy to prevent duplicate transforms if
they continue.
Change-Id: I97efee9197359ecdccdf89a0be850a707a11cc98
* getText() could be called multiple times on a ParserCache object
which would fire the ParserOutputPostCacheTransform handler
multiple times.
But, I could not track down how this could happen right now.
* As a separate issue, while conceptually there are no restrictions
against calling getText() multiple times, there is a semantics and
performance issue if that did actually happen. getText() does a
bunch of transformations and makes no effort to avoid duplicate
work. It will accumulate more transformations over time via the
OutputTranform pipeline and it is preferable for getText() and/or
the OutputTransform pipeline to guarantee semantics where the
pipeline won't be run multiple times on the same content. That will
free both hook handlers (like this) and the transforms themselves
to avoid checks as in this patch.
This patch should be reverted once such a change is made to core.
Bug: T351461
Change-Id: If5dfa0954e3fd2b7dbea1ed29b475be07f0f3986
* This patch enables DT to work with Parsoid HTML without changing
the functionality for legacy HTML.
* The code comments document some of the decisions being made here.
Some of these decisions are temporary and need better solutions
but this patch will let us run visual diff tests and expose any
other latent bugs.
TODO
----
* We need to add new tests to verify CommentFormatter expectations
for Parsoid HTML. I'll tackle this in a followup patch.
Known issues:
-------------
* Performance: Since the getText() transformed output in ParserOutput
is not cached, if DiscussionTools is to switch over to Parsoid HTML,
we have to add some form of caching of the transformed output because
transformHtml can take a couple seconds in the p99 case which is too
long to render uncached!
* Longer-term: Since this hook is called when getText() is
called, all calls to getText() will now invoke this handler
(which will return but still has to do a bunch of checks to
determine this won't apply). Presumably, transformHtml() is
idempotent because when some other code (other extensions, for ex)
calls getText(), we will run the transfromHtml() on previously
transformed content.
My understanding is that getText() is going the way of the dodo
and that getText() callers will have to explicit call the output
transform pipeline code (and presumably this issue of repeatedly
calling the same transforms on previously transformed content will
be addressed there).
* Some CSS doesn't apply to Parsoid HTML because intervening <section>
tags interfere with existing query selectors -- will be addressed
separately.
Bug: T341010
Change-Id: I9846193656cdc658f5237df0a133d9d4dcc20d00
It wasn't appearing in normal previews thanks to some redundant checks
elsewhere, but it was appearing in our own internal previews using
ApiDiscussionToolsTrait::previewMessage(). It wasn't causing any
problems until change Iac3778a4a88a4def234be9d10b80d9796d35bceb, which
detects headings in the preview, and it was detecting the empty state
heading.
Follow-up to commits 8fb467896f and
ab40ef62c0, where I replaced a HTML
comment with ParserOutput extension data to indicate this, and then
accidentally removed the cleanup code from removeInteractiveTools()
with no replacement.
Change-Id: I4b650f82c711d65e200758e981ce338202deeaa6
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
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
The config is currently unused in some classes, but this is okay since
it might be used in the future.
Change-Id: Ie25fc52cc5d3476c9445e182975d229991316bd3
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
The ParserAfterParse hook will likely be deprecated, as Parsoid can't
properly support it as-is. Luckily, DiscussionTools isn't doing
anything in ParserAfterParse that couldn't happen in the (supported)
ParserAfterTidy hook.
Bug: T303630
Change-Id: If72feb1e277c09f4ea0df339f2dd097a9b329d71
We always do our processing in the parser now, so we don't need the
marker comment to detect whether we've already processed the page.
Bonus: include the time taken by our processing in the limit report.
Bug: T291831
Change-Id: Ife7ddffbad1b1495b004739212002a98fdebe6c0
Using `updateCacheExpiry()` in this way appears to be established
with examples of other use in WMF production such as:
- CategortyTree extension:
custom cache expiry for pages with `<categorytree>`.
- RSS extension:
custom cache expiry for pages with `<rss>`.
- intersection extension:
custom cache expiry for pages with `<DynamicPageList>`.
- Math extension:
custom cache expiry if `<math>` failed.
- Wikibase extension, Flow extension:
no caching for certain namespaces or content types.
- Graph extension, Kartographer extension:
via onParserAfterParse hook, no caching if on preview.
Bug: T280605
Change-Id: Iea41ab8599ffae4622c97d682258b1b64eaf9ba2
