When searching for a specific page title, it's necessary to specify
page_namespace, not just linter_namespace, so that the relevant index in
the page table can be used.
Submitting the form with an empty namespace box led to a search for
namespace zero, because getCheck() returns true for an empty string.
It's not easy to search for a title part in all namespaces. So drop
that hidden feature and interpret a title part with a missing namespace
as being a search for namespace 0.
It's possible to search for a category with an empty title and zero or
more namespaces. Implement the namespace filter in this case using the
linter_namespace field. But ignore the namespace filter if there is no
category, since there is no index on linter_namespace alone.
Bug: T360865
Change-Id: I00934eaaf1a99e4098f177166b43069d33d9f137
* Using namespacesmultiselect type in HTMLForm element to
provide multiple namespace selection criteria in reports.
* New namespace URL encoding implemented which matches namespace
parameters against active namespaces to ensure parameter
security and validation.
* Test system updated to use new URL namespace encoding
Bug: T231161
Change-Id: Ic3190cffe259aecdea429c10e35122eabdbe10d4
IndexPager::$mDb is documented as IDatabase, that interface does not
implement fieldExists. To use the correct static types get a
IMaintainableDatabase instead from the load balancer and call
fieldExists
Bug: T343495
Change-Id: I6a07ff2115de781e26f272126a72a9fbdef30223
* Tag and Template search is enabled using config variable
'LinterUserInterfaceTagAndTemplateStage' and also checks for
the linter table column 'linter_tag' to exist to protect the
report code from error if the column is absent. As the linter
table alter maintenance added both the linter_tag and
linter_template at the same time, there is no reason to check
both. The user interface code does not check for the field
presence only the config variable.
* This code depends on the recordLintJob code writing the tag
and template data which is enabled by the config variable
'LinterWriteTagAndTemplateColumnsStage' and also assumes the
data migration maintenance script migrateTagTemplate.php has
been run to populate linter error records created prior to
the table alter and the write code being enabled.
Bug: T175177
Change-Id: I2f951dfcd34e3dc6ca17e8754cfaeba8baa3e835
* This performance improvement patch uses the namespace from the
new field 'linter_namespace' in the linter table instead of
the 'page_namespace' in the page table. It checks for and
requires the presence of the linter_namespace field in the
linter table, as well as the config variable
'LinterUseNamaspaceColumnStage' being set true.
* If the linter_namespace field is present and aforementioned
config variable is true, the code assumes that the config
variable 'LinterWriteNamespaceColumnStage' is set true and
recording the linter_namespace for new lint errors is
active and the migrateNamespace.php migrate code has been
run to migrate the page_namespace data into existing linter
records that were created before the linter_namespace column
existed and were left NULL during the table alter maintenance
operation.
* A follow on patch should remove the configuration variables and
conditional code producing the final, refactored code dependent
on the new namespace column index.
Bug: T299612
Change-Id: I4a1497d9e4dcd6a9a7befdaccf3e34c61694365d
* UI and functionality working, SQL injection risk is handled using
the database wrapper function buildLike()
Bug: T185685
Change-Id: I1f630a83f01a1c93f29643e4fc8baf55391b758d
* 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 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
* 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
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
CategoryManager is a member variable. Also explicitly define the
haveParserMigrationExt member variable too.
Change-Id: I2aa77e5c1819a80ba18f67c0f65b2d47dbaa0303
* Since the high priority categories are being used to effect
Tidy migration, we need editors to be able to compare their fixes
and ensure that the pages look identical after the fix.
* This patch adds a new property for linter categories and displays
the requested edit link in the pager.
* This patch enables the property for high priority categories.
Change-Id: Ia9b23d79da686f0a6c0203e2dba58a876a4a3d4a
The following sniffs are failing and were disabled:
* MediaWiki.FunctionComment.Missing.Protected
* MediaWiki.FunctionComment.Missing.Public
Change-Id: I96e32df48d13040893bfd1be6d90d0db4f7c7d0a
The messaging is a bit tricky. In some cases, the flag is set
because the output involves a single template and some top-level
content -- not multiple templates always.
Ex: '{{1x|<div>}}foo</span>'
In this case, the entire content is considered template-affected
because of DOM structuring reasons. This wikitext will generate
lint errors with multi-part-template-block template info.
In production usage, however, the probability is quite high that
multiple templates will be involved. This is usually because of
tables that are constructed with multiple templates, for example.
So, if we want to fudge and hand-wave a bit, the i18n message can
say that the output came from multiple templates.
Bug: T162920
Change-Id: I35cee6787800b03724856775fdf53991ae8e8125
