Generic Link handler

Ok, I am liking what I see so far. This is a long way toward something people really want.

I think we could just list all of the possibly known fields right there, rather than telling the user to check theme: information for the list of fields. It should be easy enough to extract that information from the view. $view->display_handler (or $this->display maybe I forget) ->get_handlers('field') I think. Or 'fields'. (It's late, my memory is fuzzy just now). Then simply print a list of IDs and field names they go to. Likewise we could list arguments and actually state which argument they go to.

Otherwise, this is a very nifty feature!

Some minor stuff:

+      '#description' => t('The text to disaply for this link. You may enter the view arguments, such as %1 or database field names, such as [nid].'),

display

+      '#description' => t('The drupal path or complete URL for this link.  You may enter the view arguments, such as %1 or database field names, such as [nid].'),

Has an extra space after the period. Need proper capitalization on Drupal. Also I'd like a bit clearer distinction made that %1 are Views arguments and [nid] are fields added to the view. Also mention the list found below.

+    // We don't do anything here.  But doing so avoids errors in trying to load a non-existent field.

Extra space.

On a more conceptual level I'd like to see this used to generate the edit/delete node and user links. Meaning that all the values could be passed into the field definition. We'd also need to have the ability to control visibility from a permission check.

Let's make an expansion of this a phase 2 thing.

very nice feature indeed, but after I've tried it, I found out that it doesn't accept html inside the Link text field. For example, I can't make links like

text<em>important text</em>

to appear as my custom link issue
It's a real stopper for me, because that's exactly what i intended to use the patch for (see the link for my case).

Also, the list of valid tokens in Replacement patterns is really nice feature, but it looks like it actually doesn't list all avaliable tokens, only a few of them
Still, a great field to use in different situations, great work

Hello! This is a great issue, i'm very happy to it becouse it was a need for my website. Thanks for this good work! You save my life :)

(sorry for bad EN)

Thank you, will try new patch. One question though

RCS file: /cvs/drupal-contrib/contributions/modules/views/includes/view.inc,v

+    // Store the arguments for later use.
+    $this->build_info['substitutions'] = $substitutions;
+
+    // Store the arguments for later use.
+    $this->build_info['substitutions'] = $substitutions;
+

Is this repetition necessary?

Sorry, but I currently have no CVS installed and work in Windows environment. So I'd pass on revising the patch.

Ups, ocassionally changed the issue title...

This is very slick, and almost what I need to solve point (D) over at #76725-43: Refactor project issue module to use Views. ;) Basically, I need the first column at http://drupal.org/project/issues -- a view column of project titles that link to project/issues/[project_shortname], not to node/[project_nid].

However, there seem to be two problems with this patch, one fundamental, one minor, that prevent me from using it in its current form for project_issue:

A) [fundamental]: There's no way to sort the resulting field. In my case, the link text is using the node title from a relationship in the view. I'd be happy to sort directly on that field, but the generic link field provides no way to specify that. When I first started thinking about my problem over at #76725, I thought what I really wanted was instead of the existing [x] Link this field to its node checkbox, I wanted a Link this field to [_________________] text area that supported the kind of arg/field placeholders you've got here. Then, the field itself would be the underlying field I care about, I could sort on it "natively", etc, but I could link where I need to, instead of just to node/[nid].

B) [minor]: My particular view has 2 title fields, one directly from the project issue nodes, and another from a relationship with the project nodes. However, when I tried to use [title_1] as my link text as per the "Replacement patters" fieldset, I would just see "[title_1]" as my link text, instead of the field that was supposed to represent.

Thanks for working on this, it promises to be a very slick addition to views once it's ready and in...

Ok, I went crazy with #24. This makes it so that any field gets the ability to be rewritten and made into a link. These are controlled with separate checkboxes using dependency to reduce the UI burden. Also, this doesn't use PHP5 only semantics (Sorry Ken, PHP4 is required for Drupal 6 still).

I've tested this lightly and it works brilliantly. My one concern right now is that all of the existing 'link this to ' probably need to become aware of this and be intelligent about what they do.

Right now they need to be tied to a specific field but a Global: Text field should probably make it back into this which allows a field that basically just does this, which gives the same functionality as your patch entirely, plus allowing every field to have it as well.

Ok, will get it in with this (this is why I posted a patch which is unusual for me =)

I'm like a kid in a candy store with this one. This also gained automatic field trimming.

Ok, another reroll. This one allows for alt text and integrates with all the existing render_link facilities; they are backward compatible so it shouldn't *break* people out htere using render_link, though we will need an API note that module authors using render_link style functionality should modify their behavior to use the built in link maker for greater flexibility.

While scanning through the patch:

+++ modules/comment/views_handler_field_node_new_comments.inc
+      $this->options['alter']['fragument'] = 'new';

you guys rock, this issue is developing very rapidly, but I have one thing unclear to me - how does this handler deals url-aliases?
When I use regular "link to node" feature, it does check for aliases and shows human-readable alias instead of node/lots_of_numbers
when I play with this handler (#23), it basicly offers to use [nid] in Replacement patterns, but I might be just missing something.

I'm a bit stuck with my issue, it looks like this patch should have all the functionality I need but it's a bit beyond my grasp to put all the pieces togeter
if I want to print_r an array with all that the view has to offer, what is the name of the array?

Aliasing will happen automatically, as l() is smart and checks.

If you set a link to node/[nid] then it'll just happen.

Thank you. Sorry to bother, but I guess something like
[title] <?php image_display([iid], 'thumbnail'); ?> in the link title field
is too much to ask for?
I can't see non-php solutions right now, I'm not good with this tokens stuff

seems like the latest version of this is breaking the existing link to node functionality. both node.title and node.type no longer link for me after applying this patch.

re-roll with merlin's fix from IRC.

another re-roll that fixes the issue sun spotted.

Committed!

Replacement options in my view show only 2 tokens -
Fields
[title] == Node: Title
[iid] == Image attach: Attached image
that's why I was doubting that it does list everything in #13

Well, I was hoping to use some UI to manage things, but it looks like I'll have to go back to template.php

It only lists other fields prior to your field.

What other tokens were you expecting?

This is a really new cool feature!
I'm really curious to see it in action!
Thanks guys!

Ok, table style is now fixed to work with this, and a documentation note is in the changelog (and will be in the release notes) that order of field rendering matters.

Great feature! I'm using this to link a node title to a file of the node.

What is necessary to add some attributes to the link? I would like to add a target="_blank" to the link. Is this possible?

yeah i've found myself needing to add classes to the links and resorting to custom field formatters.

+1 here!

How can I add a custom attibute (like target, class or rel) to a single link?

Thanks!

Has this feature been integrated into Views 6.x-2.6 or does the patch need applied? If the patch needs applied, can someone explain how to do so? Thanks!

sorry to bump, forgot to change the status