Expose attributes properly to Views

Having trouble with this as well...

I just looked at the code for the Link module. It looks like it is just using the native Views - Core Field API integration, so that "field" is just the database column... meaning that it has a serialized (or possibly unserialized) data array containing the rel, target, and other attributes of the field item. So I'm pretty sure it wouldn't be possible to access it using Views field rewrites. You would need to write some PHP code to extract values.

Actually, I think we should turn this into a feature request.

Having the same problem. We have the option to chang the target when editing the node directly but in views, i just can't access to the selected target. Suscribing to see what we can do here

Wow, it's surprising this integration wasn't included already. I will subscribe for updates on this, but for now I will have to make a new field for that.

Indeed it's a pity this doesn't work but creating a new field using the following manual will for fill your needs.

- Create a taxonomy Link (target) and create one item _blank in it.
- In your content type create a field Ref to terms named "Link (Target)" and choose the above taxonomy
- Now open your view and add the new field to it, turn display off and set to "text only"
- Arrange the field above your image
- Use this new field ass token in the target field of the rewrite section.

Done..
Succes

Another vote for this attribute to be available via views!

In response to kholloway, it's different than hard coding the target because the user may have select some links to open in a new window and others not to. If I hard code to _blank I'm making ALL links in my view open in a new window.

I agree with the other comments. It would make sense to include this option since the target of a link may be different for each node and our authors want to set the target (same / new window) for each node individually.

#6 is the best answer.

In my case I just created a select list with one value, "_blank|New Window".

The default is "- None -".

Using rewrite in views based on what #6 said works perfectly.

Don't forget to set the Link Target to "Default (no target attribute)" for the Link field type since you are now handling this with a different field type.

However, having this feature included with module would be great. (=

The quickest way to tamper with link field is to use views_php:

In output code just use this snippet and modify for your cause:

<?php 
$link = $data->field_{your link field name}[0]['raw'];
print l($link['title'], $link['url'], array('attributes'=>$link['attributes'], 'html'=>true));
?>

Example:
I'm having field_logo in my view (core image field, styled, hidden in view) and I want it linked (field_link, also hidden in view) I just added views_php field (at the end) :

<?php 
$link = $data->field_field_link[0]['raw'];
$image =  drupal_render($data->field_field_logo[0]['rendered']);
print l($image,$link['url'],array('attributes'=>$link['attributes'],'html'=>true));
?>

#5 Please read Descriptions of the Priority and Status values can be found in the Issue queue handbook. Such "tags" should not be set from an emotional and subjective point of view. Interaction with another module is not a "major" issue. Thanks for understanding. Of course I fully agree with the wish to have that feature available.

Here's a way to alter the link title in your views output with a hook_views_pre_render(). It's tied to a specific view and field but in most cases should be sufficient.
In this case I want the link text to be the node title (the link field named field_event_link only collects url and target from the user).

function mymodule_views_pre_render(&$view) {
  if ($view->name == 'foo') {
    foreach ($view->result as $key => $row) {
      if (isset($row->field_field_event_link) && isset($row->node_title)) {
        foreach ($row->field_field_event_link as $k => $link) {
          $view->result[$key]->field_field_event_link[$k]['rendered']['#element']['title'] = $row->node_title;
        }
      }
    }
  }
}

+1 subscribing upvote for this feature
#11 worked for me as a work-around

This feature would be appreciated.

I will work on this if anyone wants to help.

Add a replacement token for target.

Removing a piece that shouldn't be there.

Hi @lokapujya,

After applying #18 it displays the target token but it removes these tokens [field_link_field-url], [field_link_field-title], [field_link_field-attributes].

I think my code is replacing the handler. It should maybe add the handler. We'll see if it can have an array of handlers.

Cannot add a handler. Needed to copy existing views handler functions and add to them.

Further testing shows that the tokens are only shown when on the link field, not the fields that follow. In some situations, using the token still works, but not always. So, needs work.

Hi,
Using this patch #21 I got the following replacement tokens:

[field_affiliate1-url] ==
[field_affiliate1-title] ==
[field_affiliate1-attributes] ==

And using those tokens like [field_affiliate1-title] == I got as link result site/raw url ... instead of the correct title.
greetings, Martijn

Hi,

For me this worked as ..as a workaround within views Rewrite results and than:

<a href="[field_link-url]" target="_blank">[title]</a>

Greetings,
Martijn

Subscribe.

It looks like patch #21 accidentally copied the contents of views_handler_field_field::document_self_tokens() to LinkfieldHandlerFieldLinkfield::add_self_tokens() and vice versa.

Also, for me the target-attribute was not obtainable from $item['raw']['link']['target'] but from $item['raw']['attributes']['target'].

I revised the code, and with the new code I could use both the new 'xxxx-target' token and the old 'xxx-url' and 'xxx-title' tokens. I'm uploading it as a new patch.

Can you remake the patch relative to the link module (instead of drupal root) directory? I'll test it.

My apologies, I hadn't noticed. I've generated the new patch using 'git diff --relative'.

To make the code cleaner I've rewritten the class methods to invoke the parent-class methods for the old tokens (instead of copying the code from the parent class).
Additionally, I've rewritten the code which fetches the actual target-value to be more like the parent-class code (specifically, handling the case where $item['raw'] or $item['raw']['attributes'] is an object instead of an array, and ensuring that using the user-supplied target value does not create an XSS-vulnerability).

I didn't explain right. What I meant was make a patch from the Link git repository. The patch provided won't apply with git patch; It will only apply to your repository. I was able to get it to apply using gnu patch. But for future patches, it would be better if they are made from the project repo: Making a Drupal patch with Git

When I am in another field and look at replacement tokens, I don't see 'xxxx-target'. However, I am able to use the 'xxxx-target' token in another field. I wonder if there is anyway to get the replacement to show up for other fields.

Rerolled from the Link repo, plus some coding standards changes.

Oops, somehow the interdiff showed up in the patch. Fixed.

Can confirm that the patch in #33 applied cleanly and works properly. The only drawback is that the target attribute is only available as a replacement token on the link field itself.

Many thanks for the patch :)

#33 Worked for me
Thanks!

Hmm #33 breaks the module in my case. Views can no longer deal with a Link field (Title, as link) after applying the patch (does it require some of the previous patches?).

Guess I'll give the approach of #10 a go by providing an extra list (text) field to the content type with these two options:

• _self|Same window
• _blank|New window

… and use their machine names in a rewritten link field in Views.

I tested the patch in #33 and it works fine for me. @knalstaaf did you ran update.php after you patched the module?

I can confirm that this breaks if you use the RC version of Link, you need to use the Dev version.

Also this doesn't provide tokens within the Replacement Patterns in other fields. For instance, I was hoping to be able to have my Image field, which is clickable based on the value in the Link field, and be able to set the Target via the [field_link_1-target] token. But it is not available.

I could however, which I did, rewrite the results of the link field and put my image in there, in this case the token available works.

The handler is corrupted. My patch does not work. #33

I ended up creating a custom formatter for a link field that just extracts the target, as such:

return (!empty($variables['#items'][0]['attributes']['target']) ? $variables['#items'][0]['attributes']['target'] : NULL );

Then, I added a new field in my view, exclude from display, using the new fomatter. So the formatter would return something like the word "_blank" for a new window or nothing a all if there was not a target specified on the link.

That new field could then be used as a token in the rewrite field.