Last modified: 2004-12-27 01:46:45 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 1142 - Spurious server-generated wikicode in signatures
Spurious server-generated wikicode in signatures
Status: CLOSED INVALID
Product: MediaWiki
Classification: Unclassified
Parser (Other open bugs)
unspecified
All All
: High major (vote)
: ---
Assigned To: Nobody - You can work on this!
http://en.wikipedia.org/wiki/Wikipedi...
: parser
Depends on:
Blocks: 571
  Show dependency treegraph
 
Reported: 2004-12-21 22:07 UTC by Leah
Modified: 2004-12-27 01:46 UTC (History)
0 users

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


Attachments

Description Leah 2004-12-21 22:07:42 UTC
The 1.4 parser reacts to links in signatures by rendering the "fixed" part of
the signature ([[User:Name| ]]) in plain text, without an obvious method for
preventing it from doing so.  The server should omit the fixed portion instead.
Comment 1 Brion Vibber 2004-12-21 22:38:45 UTC
If you produce invalid links, obviously they're not going to render nicely. This has always been the case.
Comment 2 Leah 2004-12-21 23:22:21 UTC
The point is, the server is producing invalid links by adding wikicode even when
it shouldn't.  Users have no control over what it adds.  1.3 at least handled
this gracefully by allowing piped links to contain links.

Wouldn't it be possible to have a User:Name/Signature subpage with behavior
similar to the custom CSS subpages?  That would eliminate all current problems
with signatures; the server would simply have to write [[User:Name]] to the page
at account creation.
Comment 3 Brion Vibber 2004-12-21 23:23:20 UTC
If you reopen, please add information which could be used to reproduce the problem, such as an example of text which causes a 
problem but is not expected to.
Comment 4 Leah 2004-12-22 00:35:25 UTC
Simply placing [[link]] or [http://link] in the signature is enough to trigger
the bug.

[[User:Name|[[link]] ]] produces [[User:Name|<a href="/wiki/Link">link</a>]]

[[User:Name|[http://link] ]] produces [[User:Name|<a href="http://link"
class='external'>[1]</a> <span class='urlexpansion'>(<i>http://link</i>)</span> ]]

[[User:Name|[http://link link] ]] produces [[User:Name|<a href="http://link"
class='external'>link</a> ]]

The first and third of these are valid in 1.3; en: produces <a
href="/wiki/User:Name"></a><a href="/wiki/Link">link</a> and <a
href="/wiki/User:Name"></a><a href='http://link' class='external'>link</a>.  For
no apparent reason, [[User:Name|[http://link] ]] doesn't work properly in 1.3. 
The server should at least drop <a href="/wiki/User:Name"></a>; 1.3 and 1.4 both
produce this empty link even for [[User:Name| ]].
Comment 5 Brion Vibber 2004-12-22 00:38:43 UTC
The above describes correct behavior. 1.3 didn't handle these cases properly, producing invalid HTML.
Comment 6 Leah 2004-12-22 00:57:17 UTC
That's a little disingenuous, isn't it?  1.3 and 1.4 produce valid HTML in all
cases; the empty links might be odd, but they don't interfere with anything. 
1.3 at least gives what everyone would expect (mostly; [[b|[[a]] b [[c]]]] gives
links to "a" and "c" but not "b").  On the other hand, 1.4 dumps unmodified
wikicode onto the page, producing invalid, visible text.

Besides, you aren't addressing the problem, which is that the invalid wikicode
is produced by the server.  The server shouldn't add code it will later refuse
to process.
Comment 7 Brion Vibber 2004-12-22 01:28:05 UTC
The parser is acting correctly in trying to make sense of broken wikitext, and this will not be changed.

Changed summary field to describe what seems to be requested.
Comment 8 Leah 2004-12-23 04:08:30 UTC
Now that 1.4 is live, you can see quite clearly what the bug is (for example, at
the [[Village Pump]].  It's a bit late for idealist prescriptivism; this problem
is simply not going to go away.
Comment 9 Brion Vibber 2004-12-23 04:42:13 UTC
Closing as INVALID, since apparently you *don't* want the sig to not create the surrounding link if the 
nick contains link characters itself and have changed the summary and made comments which appear to 
reject the idea.

If you do want that after all, please please file a separate enhancement request.
Comment 10 Leah 2004-12-23 05:05:16 UTC
Oh come on, these aren't separate problems.  Did you even look at the [[Village
Pump]]?  How do you propose to fix the "invalid" wikicode there and who knows
how many other places and variations?  There may be like 300,000 pages across
the entire project with some form of this bug, depending on how creatively this
allegedly invalid syntax has been used.

Existing signatures have to be dealt with in some way, and to prevent similar
problems in the future, the server should do sth more intelligent than pasting
wikicode where it doesn't belong.
Comment 11 Brion Vibber 2004-12-23 05:08:49 UTC
You're the one who insists on not using this bug report to hold the fix for new signatures. I'm not sure why you insist on this, but 
since you do I ask that you file a separate bug report (which will remain open until I mark it as FIXED after checkin the code to do it 
later tonight).

Existing invalid code remains invalid because it's _already invalid_. We're not going to _put bugs back_, I'm sorry if that bothers you.
Comment 12 Sgeo 2004-12-27 01:46:45 UTC
Just to ask, everyone noticed the new feature for sigs?

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


Navigation
Links