Closed (fixed)
Project:
Link
Version:
7.x-1.x-dev
Component:
Code
Priority:
Normal
Category:
Bug report
Assigned:
Unassigned
Reporter:
Created:
14 Oct 2011 at 11:28 UTC
Updated:
31 Aug 2012 at 18:21 UTC
Jump to comment: Most recent file
When using the Link module with views the query string and fragment are not outputted the way expected. The reason this happens is because of a call to check_plain() that was added in this release. The line that was changed is line 412 in link.module
$item['url'] = check_plain($url);
Should be:
$url = check_plain($url);
Or even better the check should be moved above the fragment and query string substr() calls.
The reason for this is because $item is passed in by reference so it screws up when hook_token_values() is called.
| Comment | File | Size | Author |
|---|---|---|---|
| #18 | 1309658-link-url-building-went-crazy.patch | 1009 bytes | barraponto |
| #4 | 1309658-query-fragment-missinng-from-token-5168680.patch | 853 bytes | pheme |
Comments
Comment #1
pheme commentedComment #2
dqdthanks for info, aris. can U pls re-check err with latest dev? = always better for committing to next release and preventing double commits.
Comment #3
pheme commentedHi Digidog,
Thanks for your reply and sorry for mine being so late :) I have checked the code in the latest 1.0 release and dev version. The bug is still present. Please take a look at line 438:
The above line should be moved to line 424 before the
substr()calls are made.Thanks,
Aris
Comment #4
pheme commentedAttaching a patch that fixes the problem. It's my first patch so please forgive any mistakes.
Comment #4.0
pheme commentedUpdated because on second thought the check should probably be moved before the substring calls so the $item['url'] still benefits from the check
Comment #5
lsolesen commentedMoving status to critical as a lot of the link is removed after ?. However, the patch does not solve the problem when there is & or other stuff in the link, as check_plain() will convert all & to &.
It is not only a problem with tokens. It disappears from all links.
Comment #6
dqdplease stop tagging issues as major randomly here as along as there is no data loss or WSOD.
Comment #7
lsolesen commentedBut there is loss of data. Lhe last part of the link is lost. Hence I think this should be tagged as a major issue - the last portion of a link like this is lost and not saved in the database.
It happens when workbench_moderation is enabled. It saves correctly in revision_field_register_at when just saving the first time. When I hit publish the last portion of the link is removed in revision_field_register_at. And also in field_register_at.
Very strange!
Comment #8
summit commentedHi, patch http://drupal.org/files/1309658-query-fragment-missinng-from-token-51686... Solved for me also issue: http://drupal.org/node/1397978
May be you can look to the problem of #7, and then commit the patch please?
Thanks a lot in advance for your reply.
greetings, Martijn
Comment #9
ErikU commentedThe patch from #8 worked for me!
Comment #10
zach harkey commented+1 Patch from #8 worked great for me too. I tried everything — kept thinking it was a views issue. Please commit this patch, query strings are an important part of a URL.
Comment #11
sunCommitted to 8.x-1.x: http://drupalcode.org/project/link.git/commit/777434d581f4fe53ea16426cc5...
Comment #12
greenskunkAre there plans for this patch to be committed to Drupal 7?
Comment #13
naeluh commentedMy issue is similar to this one but after applying this patch a new issue has begun
I have used this patched the link module with this patch
http://drupal.org/files/1309658-query-fragment-missinng-from-token-51686...
I have urls that are now working properly as far as the query and fragment not being trimmed
here is the url I am using - which appears fine in the field -
http://www.facebook.com/permalink.php?story_fbid=418032621562946&id=1323...
But when the link field is used anywhere it adds amp; after all the &
So now everywhere on the site
The url above appears as
http://www.facebook.com/permalink.php?story_fbid=418032621562946&id=1323...
As you can see it adds the amp;
It seems like its not encoding the &s properly ?
Please help !
I can provide any info that might be helpful thanks !!!!
I have opened this issue in a separate issue here http://drupal.org/node/1688420
Please let me know if I can provide any info that would be helpful thanks again!!
Comment #14
jcfiala commentedYeah, the patch breaks links with querystrings, because the & in the querystring goes through check_plain and gets turned into &.
As such, I'm turning this back to needs work, and I suggest that sun take another look at the patch he accepted up there. :)
That said, I'm going to whip up a quick test and poke at this problem to see what's going wrong here.
Comment #15
jcfiala commentedOkay, after battering around the issue for a bit and pouring through the code, I've got this fixed up in 7.x-1.x. Please have a look.
Comment #16
sunCommitted corresponding follow-up to 8.x-1.x:
http://drupalcode.org/project/link.git/commitdiff/b1a7b0e1d35493e87ed2b4...
Comment #17
jcfiala commentedAnd... look! I managed to create a bug when the url was a relative link on the site. Because it was going through url() twice.
Yeah, so... new change updated.
Man, I wish I could get the simpletest to work on this windows box. I'm going to have to do some heavy testing when I get my hands on one of my virtual machines.
Comment #18
barrapontoHm, in my experience, this bug makes the output repeat the fragments and queries. I think this is an easy patch, but let's try it out.
Comment #19
rallycivic commentedThat patch fixed most of what I posted here:
http://drupal.org/node/1728098
Thanks very much!
The only problem left is that relative links come out like this in the node display:
...crm/event/participant%3Freset%3D1%26amp%3Bid%3D25%3Freset%3D1%26id%3D25Comment #20
barraponto@rallycivic can you try the patch at #1645640: Since <front> isn't implemented, take it off the project page until it is.? It probably fixes your other issue as well.
Comment #21
rallycivic commentedYes, that patch solves it all - Thanks.
Comment #22
jcfiala commentedI've pushed the fix on #1645640 up to the 7.x branch, so I think this will now be fixed as well.
Again, thanks, barraponto!
Comment #23.0
(not verified) commented