Last modified: 2011-03-13 18:06:20 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 T21807, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 19807 - References (<references/>) are not always rendered
References (<references/>) are not always rendered
Status: RESOLVED WONTFIX
Product: MediaWiki extensions
Classification: Unclassified
DumpHTML (Other open bugs)
unspecified
All All
: Lowest minor with 1 vote (vote)
: ---
Assigned To: Tim Starling
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2009-07-18 12:42 UTC by Kelson [Emmanuel Engelhart]
Modified: 2011-03-13 18:06 UTC (History)
2 users (show)

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


Attachments

Description Kelson [Emmanuel Engelhart] 2009-07-18 12:42:49 UTC
Using dumpHTML do get static version of an article does not always provide a good HTML code: the <references/> tag is not always correctly rendered.

This is the case for this article for example:
http://it.wikipedia.org/wiki/Provincia_di_Ragusa

It seems that between the last <ref> tag and the <references> tag, the Cite::clearState() is time to time called.
This erases the intern ref array ($this->mRefs = array()) and <references/> will be rendered afterwards as empty string.
Using Mediawiki "online", Cite::clearState() is not called in this context (between the last <ref> and <references/>).

I have tried to find the root cause and it seems that something runs differently in MessageCache.php. "Offline" (with dumpHTML) the method transform() is called a lot of time with the following values of $message:
* Utenti registrati
* {{ns:project}}:Utenti

... and this (both or one of them) generate the issue.
Comment 1 Kelson [Emmanuel Engelhart] 2010-08-26 10:37:32 UTC
It seems that the problem does not occure anymore...
See https://sourceforge.net/tracker/index.php?func=detail&aid=2845907&group_id=175508&atid=873515

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


Navigation
Links