Link adding equals signs to URL

thx 4 report, samichx. I will try to reproduce and will come back to this issue.

Please - in future - use <code> brackets for such unreal links, which are not meant to be links to follow, because otherwise it could be understood as spam. This time I did it for you.

samichx, can U please retry with latest dev?

tested and works as designed ... ? + = they all stay in url as expected ...

Type InnoDB, utf8_general_ci - if that information helps.

... it helps

The issue is confirmed in an older case - http://drupal.org/node/1095312 although no solution is given there either.

please don't use code brackets for d.o. internal links. Use this: [#issue_number]

@samichx: sadly, ...still can't reproduce it. I run 6 diff test installs of Drupal here, and on one of them an even old version of link module to render search strings with already given words like for google or imdb without any problems. any of the mentioned chars are in that.

anyone else ?

Interestingly, Digidog, I just tested this with a 7.9 drupal install and the release version of link, and I got the same result as samichx - = got added to the querystring.

Samichx, what browser are you using? I'm using chrome when I got the effect.

Admittedly, I'm not certain having the querystring as http://www.guestserve.com/getflexibledates.cgi?3000207&2001062 is actually a 'legal' url.

No, same output if I do it in firefox, but I did notice that when I edited the value, the url showed as the original. That's good.

So, here's the situation, after reading over it.

Although the way that you're handling the url is valid, it's an unusual way to have a querystring, which is usually a series of key=value pairs - ?q=node is a common drupal one, for instance. What you've got in that url is a querystring that doesn't have values, so when we use parse_str to parse it and put it back together again, it comes out as the key being a number, and the value being an empty string, with an = in the middle.

I'm open to folks coming up with patches to fix this, but it seems like a pretty corrner-related case. Anyone want to boost their karma by coming up with a fix?

Got the same problem for external images with Link Image Formatter module. Displaying an external image with link as source fails for images of format http://example.com/?12345 always returns code like <img src="http://example.com/?12345="> - which is wrong.

It turned out that the problem is caused by this Link module while processing (dissect/reassemble) the query component as fixed key=value pairs as jcfiala already said. The query (or query component/string) is not bound to key/value pairs but can be used for anything. As a quick fix I changed the code in link.module from

if (strpos($url, '?') !== FALSE) { (around line 431)
to
if (strpos($url, '?') !== FALSE && strpos($url, '=') !== FALSE) {

This fix skips the split/join part of the query string if no "=" is found in the url. Handling of the fragment remains untouched.

This does not cover all scenarios but helps in my case. A proper patch should also consider the other sub-delimiters.

Just created a patch for the changes mentioned above.

had same issue and the patch worked great!

Hm ... even if I am open for "expanding" url exceptions in general, I honestly still worry a little bit about too many corner cases making url validation finally useless.

As jcfiala already sad, and I am also in the boat, these are corner cases and I would rather suggest an option to turn this addtional validation exceptions on and off with a warning to the user who sets up link field, since some of it could really start to cause security risks. Some malware, like last time happend to the author of the jQuery qtip plugin, etc., uses obfuscated code hidden in urls to cause danger. It has affected about 30.000 WP sites.

Please be careful by expanding the validation tunnel for urls going out of your site since you may don't have the proper imprint to avoid warranty issues with your visitors. ;-)

Thanks, your little patch fixed it for me

since I am still not convinced that this is a bug report issue but rather a feature request for additional validation exceptions I will remove the assignment. Maybe somebody can help here to bring more clarification what best is to do here.

Dear followers of this issue: please read the project page info of link module for further validation issues. There is already an issue to collect and discuss all possible validation scenarios in general. That's why I will mark this one here as duplicate. I need all concentration inside the ONE and only discussion to move forward. After a D7 implementation we will provide a D6 backport.

Explanation: There are too many corner cases and validation wishes of users to implement them all serially one after the other. We would have a 40 lines cluttered settings form for validation methods only conflicting each other. I think, the right way is to find a maybe more complex but all embracing configuration method, which lets the admin better decide how and when to validate the url. Including a good description which helps to set it up.

wrapped links in code brackets, which meant to demonstrate behaviour not meant to be real links

For anyone running into this problem on D8+ and find this in search results first, here is the current D9 issue. #1464244: Rewrite as URL adding equals sign to end of url.