Last modified: 2014-06-27 02:11:39 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T48815, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 46815 - frame:preprocess with ref tags loses the backlinks
frame:preprocess with ref tags loses the backlinks
Status: RESOLVED FIXED
Product: MediaWiki extensions
Classification: Unclassified
Scribunto (Other open bugs)
unspecified
All All
: Normal normal (vote)
: ---
Assigned To: Brad Jorsch
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2013-04-02 23:22 UTC by Robert Rohde
Modified: 2014-06-27 02:11 UTC (History)
9 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Robert Rohde 2013-04-02 23:22:38 UTC
All three of the outputs at

http://test2.wikipedia.org/wiki/Module_talk:BadRefExample

should be identical, but for some reason the construction that passes ref tags through frame:preprocess loses the backlink indicators.


For an extra dose of mystery, frame:preprocess with ref appear to work correctly within the confines of Special:ExpandTemplates, but not on ordinary pages.
Comment 1 Brad Jorsch 2013-04-04 14:58:26 UTC
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.
Comment 2 Gerrit Notification Bot 2013-12-07 00:58:39 UTC
Change 99792 had a related patch set uploaded by Anomie:
Add PPFrame::isVolatile and PPFrame::setVolatile

https://gerrit.wikimedia.org/r/99792
Comment 3 Gerrit Notification Bot 2013-12-07 00:59:01 UTC
Change 99793 had a related patch set uploaded by Anomie:
Mark parser hook output as volatile

https://gerrit.wikimedia.org/r/99793
Comment 4 Gerrit Notification Bot 2013-12-07 00:59:20 UTC
Change 99794 had a related patch set uploaded by Anomie:
Don't cache volatile wikitext

https://gerrit.wikimedia.org/r/99794
Comment 5 Gerrit Notification Bot 2014-05-30 18:21:38 UTC
Change 99792 merged by jenkins-bot:
Add PPFrame::isVolatile and PPFrame::setVolatile

https://gerrit.wikimedia.org/r/99792
Comment 6 Gerrit Notification Bot 2014-05-30 21:09:16 UTC
Change 99793 merged by jenkins-bot:
Mark parser hook output as volatile

https://gerrit.wikimedia.org/r/99793
Comment 7 Gerrit Notification Bot 2014-06-27 02:10:27 UTC
Change 99794 merged by jenkins-bot:
Don't cache volatile wikitext

https://gerrit.wikimedia.org/r/99794

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links