Historically, Parsoid would suppress emitting lints for fostered content
that was purely rendering transparent since it's common to put include
directives, categories, etc in fosterable position and it made no
difference to rendering.
However, clients like DiscussionTools can benefit from this knowledge,
especially outside of templated content where it could result in edit
corruptions.
A separate category is used to avoid disrupting the work of editors
cleaning up lints in the "fostered" category, as in T369317.
Bug: T371142
Bug: T290936
Bug: T369317
Change-Id: I3519d86898df262eaea1a3303130453497ff27aa
It's not actively used at this time and it's causing a lot of writes,
affecting production. Disabling it should be harmless and reduce load.
Bug: T370304
Change-Id: I2170f657088993dd3fb81a9601284d3af7fc1883
I015fbe2ab613619c8805d12bfd397cc08450ef24 falsely assumed these were
ending up in logstash already but, unless explicitly asked, logstash
doesn't go below "info", regardless of the channel's level.
Change-Id: I55884a2535e839ca92d5d679cc4dc7911050f298
* When the user does not specify any namespace in a category
subpage search it should return all namespaces. This duplicates
the behavior for when the category is first selected from the
main Linter page.
Bug: T361081
Change-Id: Iccb195bf1b679e6e0165e4b1dde6e8d84db4d5b0
* Removed the write and user interface config variables and
fixed the tests affected by their removal.
Bug: T331883
Change-Id: If44ceedae7278f498158b8cdd528dfa32be609eb
When RESTBase is turned off, Parsoid runs will no longer be triggered
on template changes. This creates a new mechanism to do that, based on
the RevisionDataUpdates hook called by DerivedPageDataUpdater. The new
behavior is controlled by a feature flag, LinterParseOnDerivedDataUpdate,
which is enabled per default. In WMF production, this should be
turned off as long as we are still triggering Parsoid parses through
the pregeneration mechanism in RESTBase.
Note that this will not write ParserOutput to the ParserCache. On edits,
pages will get parsed with Parsoid twice, once to trigger the lint data
update, and once by ParsoidCachePrewarmJob to populate the ParserCache.
Both parses will trigger the ParserLogLinterData hook, the lint data
from the second parse is redundant.
However, while ParsoidCachePrewarmJob and RevisionDataUpdates get
triggered together on edits, they also get triggered separately:
ParsoidCachePrewarmJob by page views with parser cache misses; and
RevisionDataUpdates when pages get invalidated due to template changes.
Because ParsoidCachePrewarmJob and RevisionDataUpdates generally get
triggered in different situations, it seems cleaner to keep the two
mechanisms independent of each other, and live with the duplicate parse
on edit.
Bug: T361013
Change-Id: If53841ee583ce240dd245d640b9ea9c97e1eaa55
Since linting is currently tied up with read views, don't let a failure
to enqueue block a parse.
Bug: T364229
Change-Id: I9e8391d9f193aef72ca13ccda8ff6ab58ffc34da
