* The migrate code is designed to perform a one-time update of
linter_params JSON encoded template and tag information into
the new discrete template and tag text fields for use as
additional search criteria. The function can be restarted if
it is interrupted.
* It now uses configurable batching and sleep times between
batches to allow the database to do other work and replication
to occur without stressing infrastructure.
* The migrate code is only called by test code and needs to be
called one-time from a maintenance script.
Bug: T175177
Change-Id: Idc4ca88d4762bc7a3bcbc4e66c0f275562083867
* Migrates namespace info from the page tables page_namespace field
to the new linter table field linter_namespace. This duplication
of the namespace value was requested to greatly reduce the amount
of database activity required by the linter search and reporting
code.
* This patch has been prepared as a dark launch patch enabled with
config value LinterMigrateNamespaceStage and assumes that the
Linter table has had the linter_namespace column added to it,
and recording of the namespace field is already enabled and is
populating the namespace column.
* The migrate code now runnable from Linter/maintenance directory,
using migrateNamespace.php, which will be deployed in a separate
patch. The maintenance code creates an appropriate environment
to call migrateNamespace( in Database.php.
Bug: T299612
Change-Id: I73cb80729d6a5a8716fe93164ad1e42e6958d672
In practice this isn't a breaking change as no-one has any params to
re-name in callers.
Bug: T319202
Change-Id: Ic925e258ad3c2e194fd9f04f8afd255a9aa99e45
If908c4dc99c966cde2981f9a03be38a577406a4e introduced the
wgLinterWriteNamespaceColumnStage global but didn't add it to the
extension.json
Change-Id: I8ee5849f67ddfd894a25425582b59404eb52aef2
The form will automatically add an empty &titlecategorysearch= parameter,
so treat the parameter being absent the same as empty string.
Bug: T311202
Change-Id: I377c55a59ce60f81532ae7effba60fbe29da609b
* Writes namespaceID to new "linter_namespace" field if global
"wgLinterWriteNamespaceColumnStage" is present
Bug: T299612
Change-Id: If908c4dc99c966cde2981f9a03be38a577406a4e
* UI and functionality working, SQL injection risk is handled using
the database wrapper function buildLike()
Bug: T185685
Change-Id: I1f630a83f01a1c93f29643e4fc8baf55391b758d
* Add "mw-blank" as another tag value that erases all lint errors
for a page as a blank page cannot have any lint errors.
Bug: T280193
Change-Id: Iaad8ce75950588b2676de5dfb5f5221d64231f0e
* Determines if new content type is not wikitext and if so
deletes all existing lint error records for that pageID.
Bug: T298343
Change-Id: I20fac9a0c901f3e7a5cc898566a4487fbe70798f
Use WebRequest::getText, which discards array values since
the `pagename` param requires string value.
Bug: T301360
Change-Id: Ifc23a7020e410603ac86b71d7aee2d28f06b9ab2
* Adds template and tag name fields to enable better search
capability to the Linter extension
Bug: T175177
Change-Id: Iac22d99109bb1253f450a64254f50677e3cdefeb
* This patch contains the code needed to update the database with
the addition Linter table column linter_namespace <int/null>
and add an index with category and namespace for faster
selection of linter records.
Bug: T299612
Change-Id: I05da381b9a74294b44d4aef968614277d601a176
Html::openElement checks for this and logs a warning.
Html::closeElement does not, and this makes it return
</span class="error">.
Change-Id: I31c2809d2fd5421606fa877021d1636ac0eb4d26
The article id of the title is set to 0 when the page is deleted so,
although the lint job from the hook runs, it doesn't remove anything.
Reverts most of I06b821b65f65609ddac8ed4e7c662336082d8266
Bug: T298782
Bug: T170313
Change-Id: I2610b9b16d4032b0e18b3537cc9ed51bfdaff299
* Added error message when namespace and/or pagename is not
found or malformed which now displays a bold red message.
Bug: T151362
Change-Id: I70fde2676ded6a112f7f2b07f94f6f4b616f0e39
The global function wfWikiID() is deprecated since 1.35 and it's usages
should be replaced with WikiMap::getCurrentWikiId().
Bug: T298059
Change-Id: I695c20bff266f869f740baf7f3e335b357546fb4
Currently we select 20 rows, and return the accurate count if it's less
than that, so up to 19 rows. Since we want to return an accurate count
if it's 20 rows or less, select one more row, 21, so we can differentiate
between only having 20 result rows or hitting the limit. This is the same
technique used in MediaWiki's Pager system.
Change-Id: I50fa96238eb4c7178414ee92c53799fd69520926
* 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
