* The code now produces an accurate count if the number of
errors for a category is below the threshold set by a
public constant MAX_ACCURATE_COUNT (currently 20).
The database record count limit was originally set to 1,
to determine accurately, if there were actually 0 errors
in a category as the estimate code would never report 0.
If not 0, it would use the estimated count which does not
produce an accurate count for any other number of errors.
For low error counts this is annoying to editors and
unnecessary. The additional CPU/disk activity to accurately
check for low error counts is not significantly more than
checking for 0 or 1, as checking for 0 likely requires
a complete table scan which is probably expensive compared
to a low count that early outs when it hits to record limit.
* An improvement to consider is recording the accurate count in
a separate tiny table, and maintaining an accurate count there
which is used in preference to doing the select with row limit
based on say a 30 second TTL, to prevent a stampede of requests
from doing extraneous database operations.
* Added unit test coverage for accurately counting low error
conditions that are lower than the threshold and also verify
that the estimate is inaccurate beyond the error count
threshold.
Bug: T194872
Change-Id: I4f74cfe3bf9601baa0dc8fa6464a68030ac2bc4b
Adding a new parameter 'lnttitle'.
The SQL queries should work the same as the ones when using the
existing parameter 'lntnamespace'.
Bug: T254930
Change-Id: Ic34617e2f56d1055388ea6e8a93ff641f0342240
The following sniffs are failing and were disabled:
* MediaWiki.Commenting.FunctionComment.MissingDocumentationPrivate
Additional changes:
* Also sorted "composer fix" command to run phpcbf last.
Change-Id: Icdd0d0e60dd543921a5757162548ae149c3316ea
This eases deployment dependencies by allowing Parsoid to supply an
appropriate database category ID so that new lint categories can be
appropriately stored during the interval between adding a new lint
category to Parsoid and deploying an Extension:Linter patch to
describe it.
Change-Id: Ib7b2342168fa53ca2abac7d5f54fe313be341eb7
We will crash trying to set `templateInfo` if it is present and `params`
is not.
On line 49 of RecordLintJob we're going to use `$errorInfo['params']`,
which will crash if `params` is not present.
Change-Id: I505c676cc0ccd8d54e44e65b04b10c2de03ee37c
If `"has-name": false` is set, then CategoryManager should interpret that
as false, and not treat the existence of the key as making it true.
Same with "parser-migration".
Change-Id: I6b8d5b23fb33707b7596d9172da26fd84d652da8
Originally we were dropping excess events inside the job queue, but that means
all of the events need to be passed into the job queue...which can cause
problems.
So drop them in the API module. The only other place we construct
RecordLintJob is when an article has been deleted, and those jobs have
no errors since they're all being deleted.
Bug: T202179
Change-Id: I61940280e0dfb99398d9f047d0e66007d91a0241
On large wikis with lots of lint errors, counting the entire table can
be problematic from a performance perspective, sometimes taking minutes.
Instead, use Database::estimateRowCount(), which uses EXPLAIN SELECT
COUNT(*) to get an approximate value for the number of rows. We do make
sure that if the category actually has no rows, that it will return 0.
This should be considered a temporary solution, and we should look into
doing something like the SiteStats incremental updates table in the long
run.
Bug: T184280
Change-Id: I2d4dcc615477fd60e41dfed4a3d1a3ad52a9f4af
This reduces the number of different files that need to be modified
in order to add a new linter category.
Change-Id: Id095317d6d761c57e2ce632d34ebd962bf85e785
* multiple-unclosed-formatting-tags: this is a subset of the unclosed
formatting tag lint, but is higher priority because unclosed tags
like <small> and <big> compound their effects
* unclosed-quotes-in-heading: unclosed wikitext i/b tag with a heading
ancestor (this causes breakage which leaks out of the table of
content to affect the rest of the page)
* multiline-html-table-in-list: html table with newline breaks nested
in a list
* misc-tidy-replacement-issues: this is a catchall category for
infrequent long-tail issues, used to enable speedy deployment of new
linter categories during tidy replacement as wikis get RemexHtml
enabled. These will have a subtype property to identify the
specific issue.
Change-Id: Ic2c965132f7a09679574489865bdc81df9e43845
Linter calls the deprecated ApiBase::dieUsage() function in
ApiRecordLint.php, replacing it with dieWithError().
Bug: T181758
Change-Id: I0cbf784f591b86b206b032fccbc0e32564a3e9e8
The pageid parameter limits lint errors to specific pages. Users can get
detailed lint error information of a certain page.
Bug: T181303
Change-Id: I164449254649caff29fcffa3bc7c923c20b8e837
If the user does not have permission to edit the page, still show a
"view source" and history link so they are able to figure out what the
error is.
Bug: T177289
Change-Id: I049d27d37073e452dc0c11128dab5204d110d81f
If a newer version of MediaWiki gets rolled back, it's possible for
there to be lint entries in the database that don't exist according to
CategoryManager.
Instead of showing an error to the user, just silently hide those rows.
All callers to CategoryManager::getCategoryId() already check the
category exists. The callers for CategoryManager::getCategoryName() will
catch the MissingCategoryException, and log it if necessary. Notably
LinterError::makeLintError() will return false on invalid rows, and all
callers have been updated to handle that.
Bug: T179423
Change-Id: Ia5f56f18a51fa871511b02410222a6079efbfff6
* <font> tags with color attribute that wrap links and images
will have different behavior and hence rendering compared to Tidy.
Change-Id: I7a551ef9b7e8f57d7a43c823832f0e3add6b1367
Page deletions were bypassing the logic in RecordLintJob that
ensured the right category totals cache was cleared and the
statsd updates. Fix that by just using RecordLintJob directly.
Bug: T170313
Change-Id: I06b821b65f65609ddac8ed4e7c662336082d8266
