Like this:

http://en.wikipedia.org/wiki/Inverter_(logic_gate)

It is possible to use the "Insert Link" function to properly wrap URL tags:
http://en.wikipedia.org/wiki/Inverter_(logic_gate)

However, something in the "auto URL tag" code isn't quite right.

 

Testing:

http://en.wikipedia.org/wiki/Inverter_(logic_gate)

http://en.wikipedia.org/wiki/Inverter_(logic_gate)

Dave

 

How strange. Nice find Wook, I'll have a look at vbulletin.com to see if this is a bug.

Dave

 

Hello,

I noticed that everyting behind the closing hook is not in the link.
It happens on more forums, a phpBB forum has the same problem.
I used the escape characters %28 = ( and %29 = ) to overcome the problem.

Greetings,
Bertus

 

convenience<-------------------------------------------------------->security

Anti-SQL injection/XSS from a nefarious user, no easy workaround.

 

convenience<-------------------------------------------------------->security

Anti-SQL injection/XSS from a nefarious user, no easy workaround.

I'm not convinced that is such an issue with ()'s for unencoded URLs, as is the case being discussed here. According to w3.org, the unsafe characters are "{", "}", "|", "\", "^", "~", "[", "]", and "`" and therefore must always be encoded within a URL (in the vB world this would mean passing to the editor through the -tags or "Insert Link" tool; "(", a...http://www.w3.org/Addressing/rfc1738.txt"]ref).

Having considered this, part of me thinks this behaviour is by-design to prevent links being incorrectly displayed when put in common parenthesis for normal discussion, i.e. in normal discussion you would put something in brackets - like a link - in () parenthesis, e.g (http://www.google.co.uk).

So a trailing "(" should be ignored too? (http://www.google.co.uk - EDIT: Yes it does, so I'm sure that is the reason this behaves like it does.

There is nothing I can see at vBs website that indicates this is an active bug. At least there is a way of getting such links to display.

Dave

 

Well, if the opening parenthesis occurred AFTER the http://, and there were no spaces, then there should be a check for a closing parenthesis I would think.

Had a somewhat similar problem occur when I was doing programming on IBM mainframes; the JCL (Job Control Language) parser (INTRDR) would get confused if both parens and quotes were used when specifying a filename as a passed symbolic parameter. The parser would simply discard the trailing parenthesis, and the submitted batch job would bomb out with an error - that didn't exist!

Example:
//STEPNAME EXEC procedure,DSN=("My.Dataset.Name"),...
// more parameters

Everything on the STEPNAME line past the close paren was discarded, causing an error due to the subsequent line not being a continuation. But I digress...

 

Well, if the opening parenthesis occurred AFTER the http://, and there were no spaces, then there should be a check for a closing parenthesis I would think.

One could construe that was a bug, however the counterargument is that it is a rare case - the wiki links being an obvious exception - and that users should pass URLs to the editor via either the -tags or the "Insert Link" button (...of vbulletin) saw it as a feature! :D Dave

 

The regex removing it is in /includes/functions_wysiwyg.php around line 80-100. The use is by "tacking on", such as

 ') or ('id'='0)