Last modified: 2005-06-24 19:28:09 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 571 - Include option to add a talk link to signatures
Include option to add a talk link to signatures
Status: RESOLVED FIXED
Product: MediaWiki
Classification: Unclassified
User preferences (Other open bugs)
unspecified
All All
: Low enhancement with 2 votes (vote)
: ---
Assigned To: Nobody - You can work on this!
:
Depends on: 1142
Blocks:
  Show dependency treegraph
 
Reported: 2004-09-25 12:39 UTC by Leah
Modified: 2005-06-24 19:28 UTC (History)
0 users

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


Attachments

Description Leah 2004-09-25 12:39:27 UTC
When ~~~ is expanded for User:X, it produces [[User:X|X]] by default.  However,
if the user changes their signature to contain internal links (for example, by
changing it to [[User talk:X|]]), the code for the User:X link continues to be
included, so that ~~~ expands to [[User:X|[[User talk:X|]]]], which is
fortunately still parseable, though it is functionally identical to [[User
talk:X|]].  This exposes odd bugs in the parser depending on what exactly the
signature contains, particularly when normal text is included with links.
Comment 1 Brion Vibber 2004-09-25 20:09:02 UTC
The sig is meant to be a link to the user page; the nick is plaintext. It's a cute thing that you can make funky links with it by 
breaking the rule, but it's just a cute plaything, not an intended or desired feature.
Comment 2 River Tarnell 2004-09-25 20:10:25 UTC
Including a link to the talk page is useful enough that it should be possible
without hackery.
Comment 3 Brion Vibber 2004-09-25 20:12:59 UTC
(In reply to comment #2)
> Including a link to the talk page is useful enough that it should be possible
> without hackery.

If that's so, then this request, which is for such hackery, should be denied.
Comment 4 River Tarnell 2004-09-25 20:13:43 UTC
How is it a request for hackery?
Comment 5 River Tarnell 2004-09-25 20:25:53 UTC
Changed summary to the actual feature that's being requested, and which is
widely used.  It would be even nicer if we could entirely disallow wikitext in
signatures and just use a username or nickname and optional talk page.

BTW, you can omit the [[ and ]] in your signature as a temporary workaround.  I
use "<nowiki></nowiki>]]&mdash; [[User:Kate|Kate Turner]] | [[User
talk:Kate|Talk" which produces correct wikitext and renders correctly.
Comment 6 MacGyverMagic 2004-12-23 09:11:50 UTC
Note that the implementation of this feature in MediaWiki 1.4 also messed up old signatures by 
adding coding to them.

Comment 7 Brion Vibber 2004-12-23 09:16:45 UTC
Option for 'raw' signatures added: you can put whatever you want in the nick field 
and have that inserted without the surrounding automatic user page link. Resolving 
as fixed.

Regarding comment #6: 'correct' hackery was *not* affected by parser fixes in 
MediaWiki 1.4 -- but a few people had incorrectly set their nick fields in a way 
which produced invalid code which happened to look right previously due to parser 
bugs in 1.3. Correct hackery would have been a nick that looked something like 
"name]] [[User_talk:Name|talk", producing as final output "[[User:Name|name]] 
[[User_talk:Name|talk]]"

The sig is inserted at edit time, so the parser can't "undo" your old, invalid sigs.
Comment 8 MacGyverMagic 2004-12-23 09:24:56 UTC
(In reply to comment #7)
> Option for 'raw' signatures added: you can put whatever you want in the nick field 
> and have that inserted without the surrounding automatic user page link. Resolving 
> as fixed.
> Regarding comment #6: 'correct' hackery was *not* affected by parser fixes in 
> MediaWiki 1.4 -- but a few people had incorrectly set their nick fields in a way 
> which produced invalid code which happened to look right previously due to parser 
> bugs in 1.3. Correct hackery would have been a nick that looked something like 
> "name]] [[User_talk:Name|talk", producing as final output "[[User:Name|name]] 
> [[User_talk:Name|talk]]"

Please check my edits from yesterday or before at the Wikipedia Help desk and Votes for 
deletion for proof of old signatures changing.
> The sig is inserted at edit time, so the parser can't "undo" your old, invalid sigs.

Comment 9 MacGyverMagic 2004-12-23 09:28:35 UTC
See English Wikipedia Help desk for old bugs (even from November 11) changing with new signature 
implementation.
Comment 10 Brion Vibber 2004-12-23 09:34:45 UTC
This is explained above. Your old nick generated invalid code, which due to a bug 
turned out in a fashion that you found acceptable. With the parser bugs fixed, you can 
now see that your code was, indeed not correct.

You can now check an option in your preferences to produce the _correct_ output for 
that type of signature.
Comment 11 Leah 2004-12-23 18:40:22 UTC
(In reply to comment #10)
> This is explained above. Your old nick generated invalid code, which due to a bug 
> turned out in a fashion that you found acceptable. With the parser bugs fixed,
you can 
> now see that your code was, indeed not correct.

As I have noted on bug 1142, the invalid code is present in uncountably many
talk pages and their archives.  It is entirely unhelpful to declare the old
behavior buggy; do you expect somebody to hunt down all occurrences of the bug
and fix the old signatures?

> You can now check an option in your preferences to produce the _correct_
output for 
> that type of signature.

Thank you.

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


Navigation
Links