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
User-options related classes are being moved to the MediaWiki\User\Options namespace in MediaWiki Core; reflect that change here.
Bug: T352284
Depends-On: I9822eb1553870b876d0b8a927e4e86c27d83bd52
Change-Id: Iaf161106c323461929abe9b8a021bbb3e34c4ae7
This might be a matter of personal preference. Not sure if it's
worth it. Both is well readable. On the other hand, the method
exists. Why not use it?
Change-Id: Id66fc6c888db6ae1cf28e60a51f90d9ae2cdb6ee
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
Why:
- The button should only display for Minerva
What:
- Consult the skin name before adding the "Edit" button to the menu
Bug: T342251
Change-Id: I52cf2ca0663a4de0ee7add82910e745bcabf1c5f
Why:
- We want to allow extensions to register interactive menu items in the
overflow menu.
What:
- Create a PHP hook to allow extensions to provide menu items
for rendering in the overflow menu
- The hook allows for registering resource loader modules required by
the menu item
- The hook passes in some contextual information, like the thread
item data, context source object, and if the page is editable
- Create a JS hook that fires when a user selects one of the menu items
- Example implementation: Ie9afbedb4f24cbd75eb48bb21dc9f6d8d732d853
Misc:
- Remove b/c code that existed to handle a transitional period where
JSON encoded overflow menu data did not necessarily exist in the
parser cache
- Rename code instances of ellipsis button / data / menu to refer to
"overflow menu"
- Some renames will have to wait until parser cache is updated; these
are noted with TODOs
Bug: T342251
Change-Id: I5f2a51791f8ba7619d1399a4b93111e9bb44e172
Parsoid can be expected to throw limit exceeded exceptions so a more
graceful response should be provided.
Bug: T325298
Change-Id: I6bedc7639a68311d5247331d5e53f88c004ebc5e
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
* Add @var comments to untyped getService() calls so IDEs and tools
are able to understand where the callers are.
* Use the more specific IReadableDatabase where possible.
* Fix missing import.
Change-Id: I9c1153cb9fe872227753628a947f40bd5ee447fa
