Posted by skessler on March 9, 2012 at 11:14pm
7 followers
| Project: | Link |
| Version: | 7.x-1.0-beta1 |
| Component: | Code |
| Category: | bug report |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | postponed (maintainer needs more info) |
Issue Summary
When I save links like https://cc.readytalk.com/cc/s/showReg?udc=tn9kykvvigxh they are being cut off at the ?. I have searched through lots of resources and am not fining anything on this.
Thanks,
Steve
Comments
#1
Looking into this further the link is getting cut off when the status is changed using the Workbench module. We are not finding any other abnormal changes in the content when the Workbench status is changed.
#2
The Workbench Moderation form results in a node_save() when changing a node from an unpublished state like "draft" or "needs review" to published. The $node object passed from node_save is one that just comes through hook_node_view() or some other means.
The loaded node might have a link field value that looks like this:
array ('und' =>
array (
0 =>
array (
'url' => 'http://google.com/',
'title' => 'google',
'attributes' =>
array (
),
'query' =>
array (
'test1' => 'test1',
'test2' => 'test2',
),
'display_url' => 'http://google.com/?test1=test1&test2=test2',
'html' => true,
),
),
)
_link_santize() breaks up the simpler array so that the 'url' property no longer contains it's full string. When the node is sent to node_save(), link module does not reconstruct the broken up url property.
#3
This appears to be fixed with the newest dev release of Workbench Moderation.
#4
The changes I pushed to Workbench Moderation yesterday aren't related to the small moderation form. I'm still able to reproduce this problem with these steps.
- Enable moderation on the article content type
- Add field_link to the article content type.
- Create an article and set the url value of field_link to http://google.com/?test1=test1&test2=test2
- Save the article node to the state "Draft"
- Verify that the link points to http://google.com/?test1=test1&test2=test2
- Using the small form at the top of the node page, change the node to the "Needs Review" state
- Verify that the link still points to http://google.com/?test1=test1&test2=test2
- Using the small form at the top of the node page, change the node back to the "Draft" state
- Verify that the link still points to http://google.com/?test1=test1&test2=test2
- Using the small form at the top of the node page, change the node to the "Published" state
- Verify that the link now points to http://google.com
#5
#6
Following the steps outlined in #4 I too lose the url parameters.
#7
There is a small hack to fix this.
Add this code:
foreach($node->field_rel_links['und'] as &$link){$link['url'] = $link['display_url'];
}
Replace field_rel_links with the field data name. Add multiple foreach if multiple field data.
Code goes into workbench_moderation/workbench_moderation.module into function workbench_moderation_moderate_form. Add this in beginning of code.
This bug happens due to url key having it's value stripped as mentioned before.
I havn't tested the latest workbench module so I will not look further into a more permanent fix for this at the moment.
#8
Was meant to mark as needs review, but missed it and can't change.
#9
That's helpful Zach, but there's two things here. (And I apologize if I say something werd, but I'm not familiar with workbench yet.)
1) No everyone will have named their link fields 'field_rel_links', so this isn't really a patch. (Well, and it's not a patch file.)
2) If this is something that needs to change in workbench code, then you need to open this ticket over at their issue queue and add the information about this there - otherwise, nothing will get changed because I certainly can't change workflow from over here. :)
I'm not closing it immediately, but it sounds like the issue should be closed over here and opened up over there, with a proper patch that reads from the ... (and I'm going to get this table name wrong because I'm tired) field_instance table and iterates over the link fields in appropriate entity bundle/types.
#10
@stevector described the problem quite well. The problem appears to be that Link module is modifying it's own contents inside of the $node object when the node is being viewed. Workbench Moderation passes in this fully loaded/prepared node into node_save(), which causes the link value to loose its query string.
This can be reproduced much more easily without Workbench Moderation with this simple PHP snippet:
$nid = 81; // Or whatever node you're testing on.$node = node_load($nid); // "http://google.com/?q=example" === $node->field_link[LANGUAGE_NONE][0]['url']
node_view($node); // "http://google.com/" === $node->field_link[LANGUAGE_NONE][0]['url']
node_save($node); // Query string is lost.
One would not expect node_view() to alter the $node object in such a way that the node could no longer be saved, but at the same time Workbench Moderation should probably not be passing in a modified $node to node_save() to begin with. So I'd say this is on the plate of both modules to solve, since both issues are probably bugs in each module that can cause unexpected behavior in other situations.
#11
It looks like this problem has been (inadvertently) solved by #1645640: Since <front> isn't implemented, take it off the project page until it is., which modified the $item['url'] value so that it's changed to a full version of the URL (after sanitization) rather than the cropped off version.
I'd argue that we shouldn't be changing the user-provided data *in any way* during the node_view() operation, since this can lead to the unexpected data manipulation described in #10. As-is, the current code would cause things like tokens to be accidentally saved back into the node in their rendered form. So the immediate problem of loosing the query string is fixed but a new problem remains.
This patch removes all modifications to the $item['url'] property entirely, leaving the user-entered values unchanged.
#12
#13
Hi ,
I am also getting same problem but not in local . It is happening in production where memcache and varnish cache is there
#14
I'm a little worried that not changing $item is a problem as I think that's how the theme functions get the updated data. But I'll look at that soon.
#15
Hmm.... no. I think you're wrong, quicksketch.
The code you're changing is in _link_sanitize(). _link_sanitize() is called from link_field_prepare_view(), which is an implementation of hook_field_prepare_view(). And that documentation clearly says "Make changes or additions to field values by altering the $items parameter by reference. There is no return value."
If this is a problem, the problem exists in Drupal Core, not in this module.