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.
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.
