Last modified: 2006-11-03 14:09:25 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 5885 - Non-first reference with common 'name' attribute hidden in rendering
Non-first reference with common 'name' attribute hidden in rendering
Status: RESOLVED FIXED
Product: MediaWiki extensions
Classification: Unclassified
Cite (Other open bugs)
unspecified
All All
: Normal enhancement with 7 votes (vote)
: ---
Assigned To: Ævar Arnfjörð Bjarmason
http://meta.wikimedia.org/wiki/Talk:C...
: patch, patch-need-review
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2006-05-09 17:38 UTC by David Mertz
Modified: 2006-11-03 14:09 UTC (History)
1 user (show)

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


Attachments
Patch for Cite.php to allow late definition of reference content (726 bytes, patch)
2006-10-21 21:18 UTC, Phil Boswell
Details

Description David Mertz 2006-05-09 17:38:39 UTC
When several m:Cite.php <ref>s with the same name are used, only the first
reference is considered for rendering by the <references/> tag; this applies
both when the first <ref name=foo> is altogether empty, and when differing
contents occur in multiple such named references.

If this limitation were lifted, editors of pages would have a variety of more
flexible options for organization of references.  For example, using non-first
named references when earlier ones were empty would allow references to be
grouped together at the end of an article, or at the end of a section, if
article editors judged this more desirable.

I have examined the code for m:Cite.php, and believe that the fix for this is
below.  This change should cause no change in the rendering of articles that use
Cite.php in a bug free manner, but will allow additional uses in the future
and/or fix articles with current reference ordering errors.

--- Cite.php    2006-05-04 13:12:19.000000000 -0400
+++ Cite.php.new        2006-05-04 12:47:24.000000000 -0400
@@ -291,7 +291,12 @@
                                                        $this->mRefs[$key]['number']
                                                );
                                } else
-                                       // We've been here before
+                                       // We've been here before 
+                                       $found_text = $this->mRefs[$key]['text'];
+                                       if ( empty($found_text) and !empty($str)) {
+                                          // If no text found before, use this text
+                                          $this->mRefs[$key]['text'] = $str;
+                                       }
                                        return 
                                                $this->linkRef(
                                                        $key,
Comment 1 Steve Bennett 2006-05-18 12:33:33 UTC
See also bug 5997 (this one apparently solves one of two problems there)
Comment 2 Francis Tyers 2006-06-14 20:45:50 UTC
Please see
http://en.wikipedia.org/wiki/Wikipedia_talk:Footnotes#when_will_this_be_solved.3F

28 people on aggregate will you to fix this bug!!!!

There is a patch right there ---^

Please please please apply this patch!
Comment 3 Brion Vibber 2006-06-14 21:01:41 UTC
Restoring priority.
Comment 4 NikoSilver 2006-06-14 22:57:56 UTC
Do these people have to register and vote here too to increase priority? The result was 
33 vs 5. This is compelling majority, through extensive discussion that lasted for more 
than a week!

1.It's crazy to force editors who re-organise articles to move refs from second-used-to-
be-first-pars to first-used-to-be-second-ones.

2.Safety mechanism: non-first-ref text appears ONLY if first-refs before that are EMPTY.
Comment 5 Aryeh Gregor (not reading bugmail, please e-mail directly) 2006-06-14 23:17:58 UTC
(In reply to comment #4)
> Do these people have to register and vote here too to increase priority? The
result was 
> 33 vs 5. This is compelling majority, through extensive discussion that lasted
for more 
> than a week!

I believe you misunderstand the purpose of the "priority" tag.  Wikimedia
Foundation programming is done by two paid programmers (Tim and brion), who make
the final decision on whether changes make it into the software, plus a team of
unpaid volunteers.  What this means is that all programmers fix whichever bugs
they would like to fix: Tim and brion are in charge, so no one tells them what
to do, and the others are volunteers, so no one tells *them* what to do.

"Priority" is a way of indicating what bugs *will* probably be fixed soon due to
programmer interest, not a way of indicating what bugs *should* be fixed soon
according to what other people think.  The latter is what votes are for.  You
could get everyone to vote here if you like, but it probably won't move up the
timetable very much, if at all.  Nagging various people who don't have any
reason to listen to you isn't going to help, either.  The only surefire way of
getting anything done here is to do it yourself--and the difference between that
and what happens in most commercial software is that here, you *can* do it yourself.

And as for *why* people like brion have decided not to spend any time on this,
please keep perspective.  It would take time to test this patch, even for
someone familiar with the code (such as Avar), and the gain would be small
compared to many of the other open bugs and enhancement requests.  60 of those
bugs are rated as "major" or more severe; try running a search and looking over
those bugs and their implications before you complain about why this minor
feature addition rates above all 1,610 other open bugs and enhancement requests.

*As it happens*, *if* someone with SVN access volunteers to look over submitted
code for such minor matters, I've been making tweaks to Cite.php lately anyway,
largely because it's an extension and it doesn't deal with database stuff, so
it's easier for someone new to MediaWiki to work with.  I *might* therefore get
around to doing this at some time in the next month or two, if all goes well. 
This is not, however, related to your behavior.  I suggest you (and, e.g.,
Francis Tyers) just drop the issue and hope someone handles it rather than
nagging, because nagging is just going to piss people off.
Comment 6 NikoSilver 2006-06-14 23:36:24 UTC
Point taken. No offence but it sounded simpler than that. No further nagging whatsoever. 
Also noted no mass-voting needed. Only too many editor-working-hours consumed due to this 
glitch to move around ref texts from one par to the other. Hope it's solved soon, and 
admire your work (wish I myself could write/test the darn code too to help).
Comment 7 Francis Tyers 2006-06-14 23:41:32 UTC
Thanks for your time. Regards. 
Comment 8 Matthew W. Jackson 2006-08-29 17:32:30 UTC
I'm all for this, but I'd like to see one additional change made.  (I'm not sure
if this warrants opening another bug or not).

The <references> element should allow <ref> child elements.  I'm not sure how
hard this would be to parse given the existing code-base.  Any <ref> elements
inside the <references> element would not be rendered, and there'd be no
back-links to them.  This would allow the references to be defined at the bottom
of a page, in the references section, without any CSS visibility hacks.

Here's some example Wikitext:

==Content==
* Item A <ref name="A"/>
* Item B <ref name="B"/>
* Item C <ref name="C"/>

==References==
<references>
<ref name="A">Reference A</ref>
<ref name="B">Reference B</ref>
<ref name="C">Reference C</ref>
</references>
Comment 9 Phil Boswell 2006-10-21 21:18:59 UTC
Created attachment 2533 [details]
Patch for Cite.php to allow late definition of reference content

I have submitted a patch which appears to work properly: it will register the
content the first time that a non-empty reference appears rather than simply
the first time.

I have checked it with "php -l" but further testing would probably be a good
idea.

Would it be a good idea to display a warning message if no content is ever
defined, or is it sufficient to display an empty reference?
Comment 10 Matthew W. Jackson 2006-10-21 22:33:27 UTC
Would the warning messages have to be localized?  If so, I think an empty
reference would stand out enough, and there's no need to complicate matters.

Someone may very well want an empty reference for some reason.
Comment 11 Andrew Garrett 2006-11-03 14:09:25 UTC
Fixed in r17382.

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


Navigation
Links