https://bugzilla.wikimedia.org/show_bug.cgi?id=46815
Brad Jorsch <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugzilla.wikimedia. | |org/show_bug.cgi?id=31834 --- Comment #1 from Brad Jorsch <[email protected]> --- It's the same caching issue as what happens if you use enwiki's {{reflist}} with no parameters multiple times in a page (e.g. bug 31834). Note you can see the same thing with ordinary templates by creating a parameterless template containing a <ref> and use it multiple times on the page. The Cite extension expects that it will get called for each <ref> tag, and returns a distinct strip marker each time. But frame:preprocess (and parameterless template transclusions, and frame:expandTemplate with identical args) doesn't bother to make a second call with the same wikitext; it just reuses the old output text (with the old strip marker) and so Cite never even knows that there was another <ref> tag. In addition, both of the "[1]" markers wind up with the same HTML id. The solution to both this and bug 31834 is probably for PPFrame::expand() to be able to return some sort of "do not cache" indicator so callers would know when it was not safe to cache the returned string. And then Cite would arrange for PPFrame::expand() to indicate this when <ref> or <references> is found. BTW, the reason that it "works" in Special:ExpandTemplates is because that half-parses the wikitext to get new wikitext, and then parses that new wikitext for the rendered view at the bottom. But this two-step parsing can sometimes have different results. Try it sometime with nested refs (e.g. {{#tag:ref|Ref A<ref>Ref B</ref>}}) to see another example of this. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes. _______________________________________________ Wikibugs-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
