If you produce invalid links, obviously they're not going to render nicely. This has always been the case.

qleah wrote:

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.

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.

qleah wrote:

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| ]].

The above describes correct behavior. 1.3 didn't handle these cases properly, producing invalid HTML.

qleah wrote:

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.

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.

qleah wrote:

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.

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.

qleah wrote:

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.

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.

sgwikieo wrote:

Just to ask, everyone noticed the new feature for sigs?