This reverts commit 760641e180.
Reason for revert: it was a quick fix, has been fixed properly in core
instead in I907c22ef070616d81b9a50b0e807a7b8f78b59b5.
Bug: T357668
Change-Id: I4ec440c1e326419a8be5457b79c5374316755a53
Set hyperlink 'target' attribute to $wgExternalLinkTarget.
In addition, set the 'rel' attribute according to the
$wgNoFollowLinks, $wgNoFollowDomainExceptions
and $wgNoFollowNsExceptions settings (bug T186241).
Bug: T356730
Change-Id: If4880e4e0b3cd2056521d44baf261ed848511bcd
Also set @phan-var to handle nullable parentNode
DOMNode::$parentNode is documented as nullable in php8.1
DOMElement::getAttribute is documented to return string in php8.1
Reported by phan running under php8.1
Change-Id: Ia4abd7bf03bc52d7d4ba2c69738bb90c55d01a2b
The approach taken here is the same as in core for magnify links on
thumbs in Id46d1b2ab1af3baebff13e10f1485f3cfd9a4b37
The gist is that resource attributes are added on the mw-file-element so
that the necessary url is present in the html. A class is also added to
the wrapper element that designates where the link should be positioned.
Finally, a script adds the link which styles in appropriately.
Bug: T329364
Depends-On: Id46d1b2ab1af3baebff13e10f1485f3cfd9a4b37
Change-Id: I20130fd39135dfd5074590ee9c2b6e01693384e4
This was added in Ic0169d3914c5ce442b063f4bbbb6493966dbb302 and it
looks wrong on a few levels: the format isn't captured, and only
mw:File is emitted now.
Change-Id: I5aff7b53348696c485ef5683f6aab7aaafac4973
The insertBefore() and appendChild() methods return their first
argument, but Phan only knows that they return a DOMNode, even though
we passed in a DOMElement. Rearrange slightly to avoid this pattern.
Change-Id: I04c58458e1ba0d728374ead756afb6facf970766
Previously XML parsing and serialization was used, causing `<br>`
to be disallowed and `<br />` to turn into `<br></br>`.
Also update some uses of XPath to use querySelector() helper.
Bug: T113791
Change-Id: Ic2069015b4cbb5d05a72eb383052319048111623
This has been around for 16 years (since 284a684c) but throws when
strict_types are enforced.
Ternary is fine here since "0" doesn't seem like a legitimate type.
Bug: T302093
Change-Id: I1d2087ba28496e26c2718387cd735541698351f0
Additional changes:
* Removed phan-taint-check-plugin from extra, now inherited from mediawiki-phan-config.
Change-Id: I48df539047c1a2a481969ebd3736d73a52fbdbe6
Notable:
* Use strict === for string comparisons.
* Use ?? instead of isset(), where it makes sense.
* Avoid expensive recursiveTagParse() with empty strings.
* Add strict Parser type hint. Note this would have failed anyway
because the code below just assumes this is a Parser.
* Use the actual $lineNum from the loop instead of manually counting.
Note the loop is 0-based, while $lineNum is meant to be 1-based.
Therefor the ++.
Change-Id: I907b6c9ce3eef404dc7f048c14c4707dd1d0d98a
Previous attempts to clean this up followed similar logic to the
circle and rect types of imagemaps. However, in reality, we have
many image maps in our content that have negative values for poly
coordinates. While this isn't logical, breaking them so loudly
in the page isn't desirable.
This change then removes the check for positive value and passes
along the negative coordinate.
Bug: T217087
Change-Id: I0ee84f059dacde79a7e4fb0a172ac6937360d864
If a user provides a non-numeric coordinate in an image map, it
results in an unhandled exception. This change detects the incorrect
coordinate and warns the user with an error message.
This also cleans up a type casting that was old fashioned.
Bug: T217087
Change-Id: Ic1254dd0fe41d0499f71140466277fb58d1d194c
PhanUndeclaredVariable is reported, because the vars are not declared
outside of the loop and only conditional inside the loop.
The condition is run on first loop, so it is always run and the old code
works.
Declare the vars to make them visible before the loop
Change-Id: Ic33170fcb0e5b7e02b7269c83f27120989a6ca10
