While debugging the Extension:AJAXPoll, I noticed again, that when having a <poll>…</poll> section on the page with <ref>…</ref>, the <references /> are not shown. The same happened with DynamicPageList or SubPageList3 on the same page.
Version: unspecified
Severity: normal
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?
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
}(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.
We suspect this was never really an issue in the Cite codebase, but because of the way other extensions interact with the Parser. Sure, when an extension modifies or even resets the Parser state (instead of creating a new Parser) this will affect other extensions.
After 10 years of inactivity I suggest to clean up our backlogs a bit. There is specifically T343230 that will certainly have an impact on issues like this one here.