Not spotted in code search due to wrong case, which PHP forgives.
Whoops.
Bug: T360991
Depends-On: I73e4d3ab3158659b6a3c0a942f6bef10820b4248
Change-Id: I2d1cfd0f05c962f2d62dde911e4b0eed1ca02d83
Top is in the WHATWG spec as a magic value that always navigates to the
top of the document.
There used to be a #top element in pre-Vector2022 skins, and it's in
fairly wide use on some wikis in signatures and via gadgets, so many
links exist that point to it.
Bug: T360274
Change-Id: Ia12464239ab2cdc428c570d0cf5df1c0d1780b7a
Mixing different binary boolean operators within an expression
without using parentheses to clarify precedence is not allowed (T358966)
Change-Id: I9e9c9531ab0fa373606b19a5865cec748a3f36ff
MediaWiki's PHPCS plugin requires documentation comments on all
methods, unless those methods are fully typed (all parameters and
return value).
It turns out that almost all of our methods are fully typed already.
Procedure:
1. Find: \*(\s*\*\s*(@param \??[\w\\]+(\|null)? &?\$\w+|@return \??[\w\\]+(\|null)?)\n)+\s*\*/
Replace with: */
This deletes type annotations, except those not representable
as PHP type hints such as union types `a|b` or typed arrays `a[]`,
or those with documentation beyond type hints, or those on
functions with any other annotations.
2. Find: /\*\*/\n\s*
Replace with nothing
This deletes the remaining comments on methods that had no prose
documentation.
3. Undo all changes that PHPCS complains about (those comments
were not redundant)
4. Review the diff carefully, these regexps are imprecise :)
Change-Id: Ic82e8b23f2996f44951208dbd9cfb4c8e0738dac
There's now a different rule for the same thing in
mediawiki/mediawiki-codesniffer v43.0.0. Also document the reason for
the override. Follow-up to 8b00546749.
Change-Id: I392ee10639ffda6de55b091555e8c3cadd2af485
Place the "[subscribe]" links used when the 'VISUALENHANCEMENTS'
feature is disabled in the same DOM position as the "🔔 Subscribe"
buttons used when it is enabled.
Recent changes in MediaWiki core caused them to move inside the
`<span class="mw-headline">`, breaking some gadgets (T13555#9615648).
Moving them all the way outside should avoid problems.
I don't remember why we placed them inside the `<h2>` tags, but there
doesn't seem to be any reason to do it now. It must have been easier
that way before we introduced the `<div class="mw-heading">` wrappers.
Note that I'm keeping the `<!--__DTSUBSCRIBELINK__...-->` placeholder
comments in case it turns out there is a reason, and we need to revert
this change. If everything goes well, they can be cleaned up in change
Ie3348671c486de5bbd9f286772a8d145e3609bd5 later.
Bug: T13555
Change-Id: Idb23b0f5e438d35ed74569ff50302c7fad5ba688
We no longer need to support toggling visual enhancements without
reloading the page, so we can remove the extraneous set of buttons
to reduce HTML size.
Bug: T322457
Change-Id: I54e57c754c54b7e611069f9832d1ebabf141a396
We need to more carefully wait for mobile section toggling to happen.
Follow-up to 3957d7ac25.
Bug: T338920
Change-Id: I1bd31483c5be9428075f07494e89b06f19f8bf23
MediaWiki should never generate links like this, but users or 3rd
party tools probably create them accidentally quite regularly, and
we do a similar thing with Title normalisation.
Change-Id: Ia467f422578bcb9b4d3fb8feab0b85f4b6436f7e
In this case, the generated regexp would match the '/local' part in
the generated URL. Prefixing 'https://local' is no longer necessary
since 10899af666.
Add tests for this, and some tests to cover T261711 as well.
Bug: T358321
Change-Id: Idf54deba13f30b799b7b8d17de1897bc90f95701
