Posted by svogel on July 11, 2009 at 6:40am
| Project: | Link |
| Version: | 6.x-2.6 |
| Component: | Code |
| Category: | bug report |
| Priority: | critical |
| Assigned: | dropcube |
| Status: | closed (fixed) |
Issue Summary
Hi there,
I configured the link target as "allow user to choose", but no matter if I check "Open URL in a New Window" or not, the link is always displayed without a target-attribute.
As I see in function theme_link_formatter_default there is no attribute "target" (but maybe I'm looking in the wrong place).
Besides that, this module was exactly what I was looking for. Thanks for the great work.
Best regards
Stefan
Comments
#1
I confirm the issue. Inspecting the code, I can't see where the target attribute is generated. Was this feature dropped in the latest release ?
#2
Just ran into the same problem; not sure, whether this was dropped between versions, but the tiny patch hopefully solves the problem ... attributes weren't being deserialized in the "sanitation" process of the field.
#3
Hi frega,
I just installed your patch, but now when I check "Open URL in a New Window" I get these warnings:
* warning: unserialize() expects parameter 1 to be string, array given in /.../link/link.module on line 366.
* warning: unserialize() expects parameter 1 to be string, array given in /.../link/link.module on line 366.
The line 366 is:
$item['attributes'] = unserialize($item['attributes']);The original code contains the condition
if (!empty($item['attributes']) && is_array($item['attributes'])) ...I'm not sure, in which situations $item['attributes'] is an array.
Sorry for bothering, but I really like to see this work.
By the way: I have the link field as "unlimited" (not restricted to 1 link). Is it possible, that this causes the above warning?
Best regards
Stefan
#4
For anyone who is interested I attach the patch that even works with multiple link-fields.
I simply added the array-check around the "unserialize".
Thanks frega for the initial patch.
Rock on
Stefan
#5
Debugging I found the issue that is causing the problem.
In the implementation of hook_field('load', ...), field modules should return an array of additions to be added to the node object. All the data returned by modules is merged and then cached.
If link_field('load', ...) returns the correct data, it's not required to unserialize or perform any special case processing in _link_sanitize().
The attached patch fixes the issue by returning an array of additions, with the field data.
I have tested it using Views (with fields) and in the Full/Teaser mode of the node.
#6
Note, the cache must be cleared, so that the data get cached again with the correct structure.
#7
Initializing the attributes array correctly, and populating it with default values, will allow us to get rid of zillions of isset/!empty/is_array checks everywhere in the code.
Attached the patch I committed to fix it. It adds a helper function _link_default_attributes() used to populate the attributes array with defaults. This way, it's ensured the item attributes is an array, and all the possible values are set.
I am going to fix hook_field('load', ) in other issue.
#8
Related issue: #580988: Fix hook_field('load', ...)
#9
Automatically closed -- issue fixed for 2 weeks with no activity.