Page MenuHomePhabricator

Enable RemexHTML on metawiki
Closed, ResolvedPublic

Description

https://quarry.wmflabs.org/query/26090 shows the linter counts on metawiki for ns0.

While the numbers look high, there are some mitigating factors:

  • The tidy font bug counts are high because of lots of signatures on proposals, election pages, and the like. And user signatures have a lot of this broken usage. There is no point fixing those old pages where the only thing that will change is a color of parts of a user signature
  • metawiki is a wiki with translate extension enabled. So, a lot of issues might be in the translated blobs.

At this point, it might make sense to make the switch and have editors fix any other pages that look broken.

Unless there are objections, I'm going to make this switch on May 2nd during the morning SWAT slot.

Event Timeline

Change 427182 had a related patch set uploaded (by Subramanya Sastry; owner: Subramanya Sastry):
[operations/mediawiki-config@master] Enable RemexHtml on metawiki

https://gerrit.wikimedia.org/r/427182

Johan subscribed.

(No need to put something that's specifically for one wiki in Tech News, I'm notifying Meta separately instead.)

(No need to put something that's specifically for one wiki in Tech News, I'm notifying Meta separately instead.)

Thanks.

Hi. Sorry but I object to turn this on until all errors have been fixed. There are +/- 500 k high priority errors. There's no point imho to break such a high number of usages and put the burden later on the editors to fix them. There's no active maintenance on this area either for now. Please wait until we've found a solution to deal with this as I bet it'd be far easier to fix this now than when things break because of this. Thanks.

Hi. Sorry but I object to turn this on until all errors have been fixed. There are +/- 500 k high priority errors. There's no point imho to break such a high number of usages and put the burden later on the editors to fix them. There's no active maintenance on this area either for now. Please wait until we've found a solution to deal with this as I bet it'd be far easier to fix this now than when things break because of this. Thanks.

As Subbu said, many of those are signatures, and it might not even be worth trying to fix them...

The Centralnotice lint errors seem a bit more concerning though...

Most of the tidy-font-errors are from signatures and I think those are safe to break -- all that changes there is loss of colored links in signatures. And, it is also easy to run a bot and fix all those easily at any point.

In any case, https://quarry.wmflabs.org/query/26090 shows up the lint errors counts from the main namespace and the mediawiki namespace, which are not as many.

As for the centralnotice errors, of all the ones I clicked through are from this pattern in those pages. For example, see https://meta.wikimedia.org/w/index.php?title=MediaWiki:Centralnotice-template-dsk_lg_esLA_copy_var2&action=edit&lintid=501030

<div class="frb-footer">
    {{MediaWiki:FundraisingBanners/SmallPrint-2017}}
</div>

The indentation is causing a span to be broken up and rendered in a <pre> tag, which is triggering the error. See below:

<div class="frb-footer">
<pre>
       <span class="frb-localize-links">
</span>
</pre>

In practice, this error is harmless since all this <pre> block does is probably render some whitespace. So, you have 2 options (a) ignore the errors for now (b) run a bot and remove that indentation before the use of that template in all central notice pages.

We do plan to remove Tidy from wikimedia wikis by end of June. I think we should switch earlier than later to discover any real issues vs. mostly harmless issues.

Thanks @Legoktm and @ssastry: I'm trying to get some help at https://meta.wikimedia.org/wiki/Meta:Babel#RemexHTML_replacing_Tidy but I'm not optimistic. I think I remember @Xaosflux had a bot that fixed most of this but I can't remember very well. Regards.

https://quarry.wmflabs.org/query/26532 shows the distribution of the html5-misnesting errors by namespace and 95% of them are in the User namespace which aren't high priority to fix, in my opinion.

By bot tasks were mostly related to Special:LintErrors/self-closed-tag ; I'll see if anything else is easily scriptable.

@MarcoAurelio @Xaosflux Based on what I indicated above, any reason to wait longer before deploying? I am happy to wait since the scheduled final switch is just 2 months away, but, deploying it early will let us discover anything else that needs fixing.

@ssastry Given the above, I no longer oppose deploying this. We can continue fixing errors later if we need to. GoatGo for it :-)

Change 427182 merged by jenkins-bot:
[operations/mediawiki-config@master] Enable RemexHtml on metawiki

https://gerrit.wikimedia.org/r/427182

Jdforrester-WMF removed a project: Patch-For-Review.
Jdforrester-WMF subscribed.

This is now deployed. If people run into problems please shout and we can help (or if it's severe, revert and try again later).

This is now deployed. If people run into problems please shout and we can help (or if it's severe, revert and try again later).

Not yet deployed .. in another 10 mins. :)

Mentioned in SAL (#wikimedia-operations) [2018-05-02T17:48:26Z] <catrope@tin> Synchronized wmf-config/InitialiseSettings.php: Enable RemexHtml on metawiki (T192386) (duration: 01m 17s)

Done now.

This is now deployed. If people run into problems please shout and we can help (or if it's severe, revert and try again later).

Not yet deployed .. in another 10 mins. :)

Done now.