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.
This time, I've written a Parser method called serialiseHalfParsedText, which, as the name implies, grabs some half-parsed text, and fixes up all of the strip
markers, and link comments, and makes it safe to import some other time with unserialiseHalfParsedText. I tested it by live-hacking the cache key to be a constant,
and then putting <references /> on a completely different page, where it worked perfectly.
Calling it with no extra arguments will now assume that you're escaping
a whole id, not an id fragment, which is safer. Also, instead of ugly
bitfield-based options, I've changed the options to use an array of
strings. I fixed all callers in trunk. Out-of-tree callers that were
using Sanitizer::NONE will get correct behavior, while those that were
calling it with no arguments will get slightly changed behavior (an x
will be prepended). I think this is harmless enough that we can skip
back-compat cruft here.
This should cause no visible changes. No parser test regressions.
My last commit didn't catch anything but plain <ref>: <ref name="foo"> would be allowed. Fixed using a regex from the patch on bug 12757 by Max Semenik.
This basically uses the patch I posted to that bug two years ago. It's crude, but it should avoid the most common false positives while hopefully not causing too many false negatives. It should be possible to refine it to avoid even more false negatives, but for the time being, this will at least prevent most of the constant headaches that newbies get when chunks of articles vanish because they forgot a closing </ref>.
It isn't obviously clear how this is meant to be used, and there are no test cases for the newly added mode.
Newly added code doesn't match our code standards, making it harder to read, and contains mysterious things like "$argv=array_merge($argv);" which seem a bit odd.
