I tried to benchmark this. It's not really a big bottleneck in this
codebase, but can still be seen. For example, the relative runtime
of the method CommentUtils::isCommentSeparator (the heaviest user of
this feature) goes down from 1.5% to 0.3%.
Depends-On: If9252a97562542e7a4bec29edcc6e8dee0fb8221
Change-Id: I6b94a2481b5c4f7983df78ee48d45c0d8a50e53b
For interface messages, like the talk page header, tranformHtml isn't
run so no value is set while parsing it. The double negative in
I5c1877f7f9eb73f88a33e001ca3c2f3d06bb90e4 failed to account for that and
was reverted in I23a3f937201d93c7c7645a09c4fccfcf1c14008a.
By always setting a value, we'll overwrite a value that may have been
set when Parsoid calls the legacy parser to parse extension content for
which it doesn't have a native extension, which then gets merged into
the metadata for the main parse. However, setting with a different
value is deprecated and will eventually throw, but we already need to
find a solution for T372592 so what's one more.
Bug: T371125
Bug: T372592
Change-Id: Id73a1b5751cfc055e84188bcb19583c72b84032f
This reverts commit 7e5f9b59a2.
Reason for revert: Causes empty state to always appear on wikis using Talkpageheader
Bug: T373100
Change-Id: I23a3f937201d93c7c7645a09c4fccfcf1c14008a
Silence the deprecation warning instead to avoid regressing T372193.
I filed T372592 about the bigger problem we have here.
This reverts commit fe8526caf2.
Bug: T372499
Change-Id: I47884f99e9c18fffd22ffdc27f5c61515b60c8f8
Record if a talk page is not empty, rather than empty.
This helps prevent Parsoid from mislabelling pages as empty when they
contain extension tags it needs to call out to the legacy parser to
process. Metadata from the legacy parse is merged into the overall
metadata for the page.
For example, a templatestyles extension tag parsed in the context of a
talk page would set the empty state which would then fail to cleared if
the overall parse of the page wasn't empty.
Bartosz (@matmarex) proposed this idea in T371125#10053043
Setting and using these flags all appear to be post-retrieval from
cache.
Alternative to I1deb679ef0e19dc3a36e377c183dd1b4ab0003e9
Bug: T371125
Change-Id: I5c1877f7f9eb73f88a33e001ca3c2f3d06bb90e4
The previous approach no longer works due to changes in MediaWiki.
We must now pass the data between the hook which has access to request
state needed to determine if we should show this, and the hook that is
capable of showing it in the right place.
Bug: T362496
Change-Id: I290422c4249d288badd7c7d25e5e7e435dfd1800
Changes to the use statements done automatically via script
Addition of missing use statement done manually
Change-Id: I492ddae3c3e9f81d551ea8b348b7148893f4f590
The PHP code should never see a `<span class="mw-headline">` node
since MediaWiki change If04d72f427ec3c3730e757cbb3ade8840c09f7d3,
but we have to support it for our old integration tests (T363031).
Improve code comments to explain this and move the handling to
one place, so that it can be deleted more easily in the future.
Follow-up to 08f61b2609.
Change-Id: I5ab9d3373a6911c1456c30d844b66576b278a1b5
MediaWiki's PHPCS plugin requires documentation comments on all
methods, unless those methods are fully typed (all parameters and
return value).
It turns out that almost all of our methods are fully typed already.
Procedure:
1. Find: \*(\s*\*\s*(@param \??[\w\\]+(\|null)? &?\$\w+|@return \??[\w\\]+(\|null)?)\n)+\s*\*/
Replace with: */
This deletes type annotations, except those not representable
as PHP type hints such as union types `a|b` or typed arrays `a[]`,
or those with documentation beyond type hints, or those on
functions with any other annotations.
2. Find: /\*\*/\n\s*
Replace with nothing
This deletes the remaining comments on methods that had no prose
documentation.
3. Undo all changes that PHPCS complains about (those comments
were not redundant)
4. Review the diff carefully, these regexps are imprecise :)
Change-Id: Ic82e8b23f2996f44951208dbd9cfb4c8e0738dac
Place the "[subscribe]" links used when the 'VISUALENHANCEMENTS'
feature is disabled in the same DOM position as the "🔔 Subscribe"
buttons used when it is enabled.
Recent changes in MediaWiki core caused them to move inside the
`<span class="mw-headline">`, breaking some gadgets (T13555#9615648).
Moving them all the way outside should avoid problems.
I don't remember why we placed them inside the `<h2>` tags, but there
doesn't seem to be any reason to do it now. It must have been easier
that way before we introduced the `<div class="mw-heading">` wrappers.
Note that I'm keeping the `<!--__DTSUBSCRIBELINK__...-->` placeholder
comments in case it turns out there is a reason, and we need to revert
this change. If everything goes well, they can be cleaned up in change
Ie3348671c486de5bbd9f286772a8d145e3609bd5 later.
Bug: T13555
Change-Id: Idb23b0f5e438d35ed74569ff50302c7fad5ba688
We no longer need to support toggling visual enhancements without
reloading the page, so we can remove the extraneous set of buttons
to reduce HTML size.
Bug: T322457
Change-Id: I54e57c754c54b7e611069f9832d1ebabf141a396
To get ready for the subtopic subscriptions feature, this patch
separates the code that adds the topic container from the code
that adds the subscribe button.
The idea is that in the future, an H3 would need a subscribe
button, but not a topic container. Whereas an H2 would need both.
Bug: T275943
Change-Id: I6a82773ed200dcb4083ac38a4d41838f639c097e
Why:
- Per T338534, we want to display the overflow menu next to topics and
comments. Supporting topic-level placement is a little more
complicated, so just go with comments for now.
What:
- Rework the is-mobile check to allow the code to run on desktop/mobile,
while excluding topic-level replacement on desktop (T342627)
Bug: T338534
Bug: T342625
Change-Id: I520c377120e16aa3a6fedcc8c39075958a942e4c
'editable' refers to the section being editable, and is only for
use by heading items, not individual comments.
Change-Id: I3fb5841609c40a928071cea8987cf035ade464c2
Why:
- We want to provide contextual actions adjacent to comments, not just
topic headings.
What:
- Consolidate the logic for embedding the overflow menu button HTML into
a function, and add this for both topic and comment items.
- For this patch, this is done only for mobile; in a follow-up patch, we
can add support for desktop
- This doesn't use a feature flag as 1) no one is implementing the
DiscussionTools hook yet, 2) the 'edit' menu item is disabled at the
comment level. Merging this change would be a no-op until an extension
implements the DiscussionToolsAddOverflowMenuItemsHook.
Bug: T342251
Change-Id: I15a151f151e2fa04398876b559d93d45c42f6ef6
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
Unsubscribing was already available from Special:TopicSubscriptions
when JavaScript is disabled.
* Add links to subscribe/unsubscribe in CommentFormatter
* Update links in skin navigation
* Add support for subscribing in the actions
Bug: T321431
Change-Id: If3c4bf7df309d0d98237c3b7b9c129cc2f72cda3
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
