Last modified: 2013-04-18 22:05:27 UTC
While debugging the Extension:AJAXPoll, I noticed again, that when having a <pre> <poll> ... </poll> </pre> section on the page with <ref>...</ref>, the <references /> are not shown. The same happened with DynamicPageList or SubPageList3 on the same page.
I can second this behavior. Whenever there are other parser tags on the page (and sometimes I find that even simple template-calls), the <references /> section fails silently. It generates no HTML, and throws no PHP errors. The need for a footnote is function of page length and complexity. However, due to this bug sufficiently complex pages that require footnotes fail to get them because the functionality fails. This is definitely a bug.
This is a bug with the Cite::clearState() method, which clears the state of the Cite object (which is for some reason assigned as a property of the parser) when the parser's state get's cleared. The intended function seems to be to avoid getting cross-page-references, but a side-effect is the loss of references when the parser's state is cleared (possibly after a template is called.)
This bug is soooo old and was already in pre-2012 versions. I would be very happy if you can fix it.
This sounds suspiciously like bug 32368. Can you try it with Gerrit change #33508 applied to Cite?
Sigh. Repeat "Gerrit change #33508" so it links.
I took a look at this, and am completely confused...bug 32368 seems to have fixed a slightly different problem: when one parser clears the state of another (if I'm understanding it correctly.) I think the problem here is that the state of Cite _shouldn't_ be cleared each time Parser::clearState() is called. I can't figure out when Parser::clearState() is called, nor any logic that I can use to drop out of Cite::clearState early. I'd love to do something like this (in Cite::clearState): if ( /* we're still parsing the same article */ ) { return true; // don't lose Cite's state }
Can you provide a simple testcase that is failing?
(In reply to comment #6) > I can't figure out when Parser::clearState() is called, Probably in MessageCache with its cloned parser, which is bug 32368. Or else one of the extensions you're using is broken and is calling Parser::parse() where it should be using Parser::recursiveTagParse(), in which case it's a bug in that extension.
Unfortunately I can't link to an example where this fails because I'm working on a private, enterprise wiki. However, Brad's comments make sense to me and I'm going to do some digging -- I'll try to report back here. Thanks, all.
fyi: the issue with linking gerrit issues when there is a line break in them that appeared as a "side bug" on this one is now fixed.
