The <exclude name=".."/> is managed by libup and when a rule passed,
it get removed from the list. Failing rules on update are added.
Setting the severity for the rule to none avoid that this is changed by
libup and it is more visible, that the disable is wanted and there is
nothing to "fix" as usually assumend for sniffs in the exclude list.
Follow-Up: I8adfdce01ea96f4b62dabd3dea130f9593c7e5ac
Change-Id: If42dade02c6ceed1e00f5a3dc846e1578b960ca6
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 following sniffs are failing and were disabled:
* Generic.CodeAnalysis.AssignmentInCondition.Found
* Generic.CodeAnalysis.AssignmentInCondition.FoundInWhileCondition
The following sniffs now pass and were enabled:
* Generic.CodeAnalysis.AssignmentInCondition
Change-Id: I8adfdce01ea96f4b62dabd3dea130f9593c7e5ac
getToolbarDialogs defaults to the `side` position, but we actually want
the `above` one here.
Bug: T371341
Change-Id: Ib42f6a4877d3b0efb87199f60cce7a7416ce9b8a
Some of what happens when you click reply happens in
CommentController (in #save) and some error handling
happens in ReplyWidget (in #onReplyClick).
Move most of the logic to CommenController.
Change-Id: Ib6208c0b8d2ddbbcf08adfcca7875ab8b026f598