Move the JS which is purely for accessibility purposes into a separate
JS RL module named ext.cite.a11y. Move all pure CSS, which is not dependant
on accompanying JS into a separate ext.cite.styles module
Bug: T101559
Change-Id: I58adcfbcf9af2bb3b6d5dabb6c38c42af78e0416
It's possible that the output type is set to HTML when extensionSubstitution
is called, but that when we eventually get unstripped, it isn't anymore. If
this happens, detect it and bail out.
Bug: T99787
Change-Id: I32abaefeebc5357a2ab3fd23bcd47aa9b2a1663a
Cite has side effects that currently happen at the same time that the
preprocessor is running. This can cause oddities like references being out
of order, or references showing up in the reference list but never used in
the text. By moving the work to unstrip, only references actually used in
the final text will be present, and the numbering order will always match
the order they were used in the text. This depends on If83b0623 in core.
Change-Id: I0e136f952302b65f1abeeac5273bd842867e1dac
As of Icdf82cb9771e6, MediaWiki core now looks for the "Cite" class
instead of the "wfCite" global function. The WYSIWYG extension is also
checking for wfCite and a patch was submitted for that in I3de3e069e4be.
Change-Id: Ie0f190b7bd9c9226856f150c95a0b139812dcf98
From prod error logs:
Undefined index: 0 in Cite_body.php on line 396
Undefined index: 1 in Cite_body.php on line 396
Undefined index: 2 in Cite_body.php on line 396
Undefined index: 3 in Cite_body.php on line 396
Undefined index: follow in Cite_body.php on line 396
Change-Id: Id727f2fd7e72d8c4ceb74fdac42885d5c030b4af
The coding conventions suggest avoiding ==,
and for this condition definedness is actually more relevant
than whether the string has any text, but since
the string can also be '0', checking for !$text doesn't work.
Similar to I15b422d3345bf4522e68a17dce9682ff28484559 .
Change-Id: Ib823678b639bf4f1a92dffcd9e41c780b56ab128
The coding conventions suggest avoiding ==,
and for this condition definedness is actually more relevant
than whether the string has any text.
Change-Id: I15b422d3345bf4522e68a17dce9682ff28484559
In this function $text can be both false and empty string.
It is more intuitive to use a boolean operator here than
to rely on the fact that comparing to '' using == happens
to give the correct result.
Change-Id: I08248a3fcade7744287e9b9f3bc176d29ac1ecde
We've had Parser::recursiveTagParse since MediaWiki 1.8, back in 2006.
Remove code that only gets used if it's not available.
Change-Id: I76eed5570a675a14cf70ab10981661e0bc8bda99
Using the new functions introduced in I95b3cf87, mark the output of
<ref> and <references> as volatile so that caching can be avoided.
Bug: 46815
Bug: 31834
Change-Id: I897defba32ac6adf72b6bc9ea7e933a87b1ba17b
For a value of the incorrect type, the type in question is a
relevant part of the error message.
Follows-up Ie0271de755a63fcda8a3671cc115af7bc931a02b.
Change-Id: I09d9f1975bdfabffe44a6f69b5296cdcbf03a51e
Problem:
* VisualEditor needs to be able to more reliably target Cite errors.
Solution:
* Add a more specific class to cite errors
Grumble:
* Ideally all extensions would use mw-ext-{extension name} as a prefix to
their CSS classes (or something similar).
Bug: 51337
Change-Id: If4f5360cc1c7b765ad896b14901a9b024782cc93
The cloned Cite object in the ParserCloned hook must be cleared, even if
the clone occurs inside a <ref> or <references> tag. The simple way to
do this is to set mInCite and mInReferences to false before calling
clearState().
While Cite could probably use a major cleanup, let's fix this bug now
instead of waiting for someone to get around to it.
Bug: 47291
Change-Id: Id3e91c41dc33a703b5326961fd57e1fe8ac61f5b
If the parser is cloned, we need to clone our data object and
reassociate the hooks. Otherwise references may be lost when the clone
has ParserClearState called.
Change-Id: Ic1d75850e8d610ea890e34c38d062a358fd55178
Depends-On: Ieec65c908d71e89b9a66f83b9a626f842aadacbb
If the <references> tag is wrapped (e.g. <div><references></div>) and
the first ref on the page contains a newline, Tidy will get confused and
insert extra paragraph breaks in the output.
We can avoid this easily enough by inserting a newline between
MediaWiki:cite_references_prefix and the first reference's <li>.
Note since this changes the output we also have to adjust the parser
tests to expect the new output.
Change-Id: I8222d53eaf2b20f842915fe90af724711a20bfc5
Fix for bug 10537: Cite anchors should be numbered starting at 1
On the way a small refactoring (getting rid of redundant variable)
Change-Id: Iee94917f3f860516cc310d1cdb1c4f9065d40984
The [[MediaWiki:Cite error refs without references]] message does not
correctly display wikilinks. This is because it takes effect during
ParserBeforeTidy, which misses the call to replaceLinkHolders(). And
parsing directly to HTML (with MessageCache::singleton()->parse()) would
lose categories and such added by the error message.
Gerrit change Iaa2755f994edb081eb1d176f632f7add41640dbf adds a
"ParserAfterParse" hook, which can be used to add this message in time
to be correctly handled by replaceLinkHolders().
Change-Id: I093d85d8f8c2ac3238609d145ae5b985602bb3fd
Depends-On: Iaa2755f994edb081eb1d176f632f7add41640dbf
This fixes bug 20748 and bug 15819 without breaking the other tests. Reverts r88971.
The conflict with CategoryTree was the old problem of a message being called inside
of a parser callback, this time with clearState for which the hook is global.
