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
Categories can now have a severity level of "error" or "warning"
designated, which places them in a different heading on
Special:LintErrors.
Bug: T152822
Change-Id: I1276b9502d90765e88dcb8ea78569dee910c5d88
Move location to two separate columns in the database: linter_start and
linter_end. This allows us to have the database enforce the uniqueness
of those fields, instead of just relying upon the PHP code to do so,
which could be bypassed since we have multiple servers and concurrent
processes.
Change-Id: I3e67ce1b7cb3c93866a388ec3248af4cff2a81e0
Instead of having a complex auto-increment category manager that had
additional caching, just hardcode the (currently 6) ids for each
category, which allows us to simplify a lot of code.
If Parsoid sends a lint error in a category that we don't know about, it
is silently dropped.
Bug: T151287
Change-Id: Ice6edf1b7985390aa0c1c410d357bc565bb69108
linter_cat is now an int ID that points to a row in the new
lint_categories table.
The mapping between category names and ids is all handled in PHP, and
cached in APC.
Note that you will need to drop the `linter` table manually and re-run
update.php for this to take effect.
Change-Id: I369d9b4d8d08289b4a20d1cd29a2e327bad28ef8
