Last modified: 2006-08-30 11:10:40 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 T9162, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 7162 - citation numbering has doubled
citation numbering has doubled
Product: MediaWiki extensions
Classification: Unclassified
Cite (Other open bugs)
All All
: High normal with 1 vote (vote)
: ---
Assigned To: Nobody - You can work on this!
: 7166 7167 (view as bug list)
Depends on:
  Show dependency treegraph
Reported: 2006-08-29 13:00 UTC by srope01
Modified: 2006-08-30 11:10 UTC (History)
3 users (show)

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


Description srope01 2006-08-29 13:00:07 UTC
While adding new citations to the above article, the citation numbering has
doubled. I have 37 citations (ref tag elements) and under the references tag, 74
footnotes appear (doubled the footnotes). If one goes to the article history
page and click on the latest article item in the history, then the numbering of
the citations appear fine (the true 37 footnotes appear). I tried reverting to
earlier versions of the article when the citation numbering worked fine,
thinking that it was due to a error on my side, but the earlier versions also
appear with doubled footnote numbering. It seems to be a problem on the server side.
Comment 1 srope01 2006-08-29 14:12:44 UTC
I found the source of the problem. An XML comment that is normally in the
Footnotes section is no longer parsed correctly. The old comment that was placed
there is

<!--See for an explanation of
how to generate footnotes using the <ref(erences/)> tags-->

I edited the comment suspecting that the problem is the parsing of the brackets
within the comment. I removed the brackets. The new comment is

<!--See for an explanation of
how to generate footnotes using the ref(erences tags-->

It is now fixed for my article, but for all the other wiki pages that used the
suggested comment, the inline citations are still broken. I would suggest fixing
the parser.
Comment 2 Brion Vibber 2006-08-29 16:18:22 UTC
I'm not able to reproduce any apparent problem with this.

1) What *is* the problem? What does it actually look like?

2) What are the *exact* set of circumstances under which you can produce the problem?
Please be very detailed, for instance the manner in which you edit and every click you make on 
the way.
Comment 3 Brion Vibber 2006-08-29 16:26:43 UTC
I can reproduce the doubling on page edit when logged out.
It has no relation to the comment mentioned above, and can be reproduced even after 
removing the mentioned bit.

Most likely this is due to reference data not being properly cleared when the parser is reused 
during save. The damaged result may end up in the parser cache, which is then showed 

action=purge clears it.
Comment 4 Aryeh Gregor (not reading bugmail, please e-mail directly) 2006-08-29 18:25:12 UTC
*** Bug 7166 has been marked as a duplicate of this bug. ***
Comment 5 Aryeh Gregor (not reading bugmail, please e-mail directly) 2006-08-29 18:26:54 UTC
From bug 7166 comment #0 (Dragons flight):
> It appears that recent changes to the way that parser caching is handled are
> unexpected behavior from Cite when references are present.
> I believe the change creating the problem is r16211 to OutputPage.php that
> made on the 24th.
> For examples of the problem see: 
> (showing a large number of "blank" references at the start)
> Or simply edit any page employing Cite.  (If section editting, the bug will
occur if the 
> section has references or if the whole page is editted.)
Comment 6 Robert Rohde 2006-08-29 18:40:29 UTC
I should say I think it is related to that revision because I can't find any other caching 
changes recent enough to be consistent with the onset of the problem (and Cite hasn't 
changed), but I haven't tested the code to verify that it actually is the source of the 
Comment 7 Aryeh Gregor (not reading bugmail, please e-mail directly) 2006-08-29 19:01:30 UTC
*** Bug 7167 has been marked as a duplicate of this bug. ***
Comment 8 Michael Gmirkin 2006-08-29 19:25:28 UTC
I've had this same issue a couple times. It was odd. It seemed like the cite
worked fine using ref & /ref, but then I added a comma and the citations
doubled. But I may have also  added titles with colons to the innards of the
cite links. And I don't know if the colons screwed up the parsing?

See Bug 7167 marked as duplicate above for more on my issue. This happened on a
couple pages I recently edited. I tihnk they all used commas as separators. And
may have used colons in the title of link to a citation site. So, I figure it's
one or the other. And taking out the commas didn't seem to fix the issue. Didn't
try taking out the colons though... So, maybe that has somethign to do with it,
since I know colons are used in parsing WP : BITE and such. I ended up just
moving the links wholesale to the References section and taking out the ref
tags. But I didn't change the titles, now that I think of it, and they work okay
there, so it seems to be something with the ref tags specific to either adding a
comma between bracketed citations or using colons in the citations
themselves...? And changing things back to the way they were before didn't seem
to "fix" the issue. But I may have overlooked something...
Comment 9 Michael Gmirkin 2006-08-29 19:28:14 UTC
Ohh, and it wasn't ALL citation links just the ones in that particular line.
Others remained unaffected in one ofthe articles I edited, making me think that
it was specific to the exact ref's and formatting used in that particular set of
ref tags.
Comment 10 Thomas Morton 2006-08-29 22:55:41 UTC
Without claiming to be an expert that change mentioned above looks like it could
be the porblem. That hook to pass extension data seems to me to be the only
change recently that could have caused this problem.

Also to note it is now popping up as other issues (ie just some of the refs
appearing twice and the ordering has messed up a few times).
Comment 11 Michael Gmirkin 2006-08-30 00:45:34 UTC
So, as an example, perhaps the "NOAA: What is lightning?" portion of the
citation title confused the parse into thinking that extra data was being passed
or something, thus made it go screwy? I was kind of wondering that myself...
Anyone care to test that theory and then try taking out the ':' from the title
and seeing if the problem corrects itself or it's still screwed up? IE, does it
go back to 1 citation line for everythign between the ref & /ref tags, or are
there still duplicated lines? Perhaps someone can play in the wikipedia sandbox
and find out? I'd do it, but I have to get going home from work.

So basically, it would just go 

LINE OF TEXT < ref > [ citation  title: subject] [ citation title: subject ] <
/ref >.

= = References = =
< references/ >

And then see if the References section picks up two duplicates of the same line
out of the reference? And of course take out all the extranneous spaces and
insert some dummy text...

Comment 12 Michael Gmirkin 2006-08-30 00:47:07 UTC
Might evene have this solved before supper time... ;o] OF course, as I type
this, I'm sure someone somewhere just finished supper. So, maybe not... ;o]
Comment 13 Robert Rohde 2006-08-30 01:12:35 UTC
Michael, it has nothing to do with the format of the refs.  The parser is registering the 
same reference information more than once (and sometimes handling it incorrectly).  Ref 
tags add persistent information to the parser stream by design (clearState = False) so 
that the references section can correctly identify all of the refs, which are parsed first.

Somehow the parser data generated by ref appears to have become persistent from one run to 
another, causing bogus refs and duplication to be added to subsequent runs.  I assume this 
means that Cite->clearState is for some reason not being called when the parser exits.
Comment 14 Deon 2006-08-30 04:40:52 UTC
I've noticed a few people having troubles with this, and using {{helpme}}. I have noticed on some (eg. ) that people use:
<div class="references-small">

which creates double. When i removed everything but the <references> (and added the <small> tags), everything was 
fine :)

Comment 15 Minh Nguyễn 2006-08-30 04:45:14 UTC
(In reply to comment #14)
> I've noticed a few people having troubles with this, and using {{helpme}}. I
have noticed on some (eg. 
> )
that people use:
> <div class="references-small">
> <references/>
> </div>
> which creates double. When i removed everything but the <references> (and
added the <small> tags), everything was 
> fine :)
> -Deon
> [[en:User:Deon555]]

I'm seeing this bug when only <references /> is involved though. Likely what
Deon is seeing it fixed because the article was edited. This bug disappears
whenever the page is purged (via ?action=purge), so I don't think it has to do
with the surrounding <div> tag.
Comment 16 Steve Bennett 2006-08-30 08:38:58 UTC
Just to create some more noise, I've just had this occur. What's interesting is:
a) it's a brand new article [[Vulture Bee]] at en (the second edit to the
article added this ref)
b) I used exactly the same formatting I always use: <ref></ref>

The problem appeared the very first time I saved the page with the new
reference. However, on clicking "edit", it disappeared in the very first preview.
Comment 17 Ligulem 2006-08-30 08:47:39 UTC
I can consistently reproduce the error now.

Testpage: User:Ligulem/work/bug7162-test-1

If the page doesn't show the doubled references, do a null edit to the page
(click on edit, then click on save). After that, the references are doubled
(this is wrong). Then enter User:Ligulem/work/bug7162-test-1?action=purge. After
that, the references are ok. Doing a null edit again doubles the references
(this is wrong).

Warning: another user might do that use case on my testpage. So I recommend
doing the test in your own sandbox for consistent results (copy the contents of
the page I noted above).

Comment 18 Ligulem 2006-08-30 08:49:25 UTC
(In reply to comment #17)
Sorry. TestpageURL is:
Comment 19 Brion Vibber 2006-08-30 11:10:40 UTC
Fixed in r16283, which requires a fix in r16282.

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