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
Instead of checking section->exists() everywhere we have to call
getTruncatedSectionTitle(), override the method inside
PlaintextEchoPresentationModelSection class to make it always
return string for our case.
Call to getTruncatedSectionTitle() in the following classes now use
the method override:
* RemovedTopicPresentationModel
* SubscribedNewCommentPresentationModel
* AddedTopicPresentationModel
The call to getTruncatedSectionTitle() in CommentThanksPresentationModel
does not need nor use the override.
Bug: T378261
Change-Id: Ibe985da5c1a79c5a1853d9c4896f8769cce6ddfd
If the subject page/user doesn't exist it usually makes sense
not to show the "Start a discussion about X" message, but when
the talk page itself exists but without any discussions
(e.g. after a Flow archiving), then we _should_ show message to
start a new discussion.
Bug: T378392
Change-Id: I20dab0089691ba7a429c9a50f23b9e3afe61aaaf
EchoPresentationModelSection::getTruncatedSectionTitle() has a note that
it should not be called if ::exists() returned false. Among the reason
the section may not exist includes suppressing the revision where the
topic title was added or edited.
Add placeholder message text "(topic removed)", to be used in place of
the unavailable topic title. This is analogous to "(user removed)" which
would be shown along if the username is also suppressed.
Bug: T378261
Change-Id: I6db0872b8724323a5e15eb6a262c2c3d0bdd630d
Implicitly marking parameter $... as nullable is deprecated in PHP
8.4. The explicit nullable type must be used instead.
Bug: T376276
Change-Id: I40b301271ea0ae5d9123b06841eb8d3e4f9fbf86
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
Some extraSignaturesNamespaces often have pages which are never
used as talk pages. This check will suppress "topic not found"
messages from appearing on those pages.
Bug: T374598
Change-Id: I0073807b7f0291fb64aab54a19a4c05fceff968c
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
While investigating primary database queries as part of T370304,
we found that EventDispatcher currently issues a primary DB query
to fetch the previous revision of the newly created revision on
every edit, but discards the result for non-talk pages. So, as an
optimization, have it fetch the previous revision only after the page
has been established to be a talk page.
Bug: T370304
Change-Id: I301f5c3c002c6953ef0b3919a33667a809342b84
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
It's unlikely we'll do another feature A/B test any time soon.
Bug: T322492
Bug: T341491
Depends-On: Ia3712e2930fcd971bce44f568430602ce3949f23
Change-Id: I1ef4191f9466b7420a2fead571615ed6d49f873e
I've been reading some discussions in Special:DiscussionToolsDebug
and saw a good number of comments where the first paragraph has
a bullet point (`*`), and the following paragraphs are indented (`:`).
Change-Id: I1afadc49565e843c97286a3744941ffb4062ddec
