Allow absolute url in node and comments links

the plain path...of what?

You can add the 'nid' field and set it to exclude from display. Then you can refer to it with a token in the 'make this a link' field, or look for it in the result array if creating the link through theming. Then you can form the url like this: node/[nid]

node/NID will be automatically converted to the alias for you.

If got the same thing now, and ok when you use node/nid it redirects you to the right url. But i want my seo right so i want the paths to be as they are supposed to be.

I agree, it would be good from an SEO point of view to get this working a little more cleanly.

I've used views to make an accessible nodes listing page. See http://vacdirectory.illuminateweb.org.uk/index

The node title in the list points to the URL alias (/org/org-name) and the 'more' link points to the node using the technique in #4 (/node/xxx). I've changed the link text (to be more accessible) using the same technique. However, it frustrates me that the 'more' link does not use the aliased path.

Would it be possible to expose a Node: Url field, along with the Node: Nid, Node: Link, Node: Title, etc?

Marked this closed again.

I tried with a more recent version of views and was able to customise the link stuff a bit more. See attached image. The way I did it before output a link (like /node/123) that didn't get translated to an aliased path by Drupal. This works perfectly now.

Really nice to be able to create properly accessible links like this!

Many thanks!

Here is how to do this.

Download and install:
http://drupal.org/project/views_customfield

In your view field ad the:
Customfield: PHP code

Paste this in the textarea:

<?
$path = 'node/' . $data->nid;
print drupal_get_path_alias($path);
?>

ps: or you can use the post above this one.

Now you can use this for advanced themeing or just as a text link.

Not sure why this is reactivated. From what I can read this is effectively fixed and working, right?

Yes, I had it working a treat! :)

I see that there is no "URL to the node" field in Node module of Views. And I see that there are cases when one needs to display a plain URL to the node instead of a link to the node. (I personally need it for a custom Views RSS plugin which maps fields to appropriate RSS tags where permalink to the node is a must.)

I think that URL is pretty standard piece of data that one expects to display along with the node nid, title, body, etc.

Here is the patch against Views 6.x-2.7 which adds new field "URL" under Node group in fields. Feedback is welcome.

+++ views/modules/node/views_handler_field_node_url.inc	2009-12-01 16:02:22.000000000 +0200
@@ -0,0 +1,47 @@
+      ),
+      '#default_value' => (!empty($this->options['url_type']) ? $this->options['url_type'] : 'absolute'),
+	);

Some minor codestyle problems. Just have a look at the documents: no tabs etc.

+++ views/modules/node/views_handler_field_node_url.inc	2009-12-01 16:02:22.000000000 +0200
@@ -0,0 +1,47 @@
+    if ($url_type == 'absolute') {
+      $options['absolute'] = TRUE;
+    } else if ($url_type == 'relative') {
+      $options['absolute'] = FALSE;
+    }

You can do this in a single line with ? :
I guess than this would be somehow easier to read

Wouldn't it better to name it URL of the node, for me this does make more sense.

@dereine: Thanks for the comments. I've modefied the patch, fixed codestyle problems and made code more readable, changed description to "The URL of the node." as you suggested. Also, I've diffed it against -dev version.

I tested this patch, but this error is coming
"
$ patch -p0 < views-node-url-field-470018-17.patch
(Stripping trailing CRs from patch.)
patching file views/modules/node/views_handler_field_node_url.inc
(Stripping trailing CRs from patch.)
patching file views/modules/node.views.inc
patch unexpectedly ends in middle of line
Hunk #2 succeeded at 669 with fuzz 1.
"

figover, are you patching against current -dev version and within the directory where views reside?

Try:
download current -dev version to ./modules
move patch file to ./modules
$ cd ./modules
$ patch -p0 < views-node-url-field-470018-17.patch

Works for me, just double checked.

Cheers

maijs, I have downloaded views-6.x-2.x-dev . and i placed patch at sites/all/modules location.
But still i am watching the same error.
"
$ patch -p0 < views-node-url-field-470018-17.patch
(Stripping trailing CRs from patch.)
patching file views/modules/node/views_handler_field_node_url.inc
(Stripping trailing CRs from patch.)
patching file views/modules/node.views.inc
patch unexpectedly ends in middle of line
Hunk #2 succeeded at 669 with fuzz 1.
"

I am using cygwin for patch commands.

Patch is working fine. But i am worry about the error which is coming when i import patch.

It is very good patch according to SEO point.

Please do some more work to eliminate the error.

Thanks

maijs, here is another error.

When i reverse the patch, node url option is still coming in view.

It should not come, when i reverse this patch.

Thanks

This error run away when i clear cache

figover, glad you have resolved your issue.

@maijs: I have reviewed your patch and I think that is not correct.

In first place, there is an existent node link field into views/modules/node I don't know if it correct create another handler to manage this feature.

In second place, maybe is better a single checkbox than a select box with two options.

I have modified your patch to make it work with views/modules/node/views_handler_field_node_link.inc the current handler for node links.

And since views_handler_field_node_link_edit and views_handler_field_node_link_delete inherit from views_handler_field_node_link, I have also modified this handlers to support this new feature.

This patch is incompatible with this #648484: Node Links: rewrite output doesn't respect node access levels so, if one gets committed, we have to reroll the other.

@dagmar, I tested your patch and for what it does, it works fine.

However you have misunderstood the purpose of my patch. It was not created to generate absolute URL for the link to the node rather than it was made to output the URL of the node. Currently there is no way Views can output a plain URL of the node (I repeat, not a link with title "view" or "read more", just an URL) without creating a template which also has to scrub the anchor to fetch the URL.

It seems unintuitive to use Node Link handler to output an URL therefore I created an extra handler.

As for #648484: Node Links: rewrite output doesn't respect node access levels, should user be validated against content access permission before displaying an URL? I don't see any validation upon outputing Nid or Title of the node. How URL is different?

Yes, sorry, I didn't interpreted your problem.

It was not created to generate absolute URL for the link to the node rather than it was made to output the URL of the node. Currently there is no way Views can output a plain URL of the node

You can use Views Custom Field with this code:

return url("node/{$data->nid}", array('absolute' => TRUE)); 

Ok, I don't know if this is really usefull, since you can use the above code to display your link. Also I'm not really sure if my patch should be added to views. By now I'm changing the name of the issue, and changing the status.

@dagmar, using Views Custom Field is certainly an option although an ugly one. The URL of a node is pretty standard stuff you would expect to retrieve about the node, along with Nid, Title, etc. In my opinion it would be much better to have views_handler_field_node_url as a parent class for views_handler_field_node_link, views_handler_field_node_link_edit and views_handler_field_node_link_delete as they all have everything to do with the URL in the end. Providing an option to turn URL to a link is a much simpler workflow rather than way around.

Given you see my point and initial problem, do you still think that patch in #17 is not correct (as you stated in #17) and is incompatible with #648484: Node Links: rewrite output doesn't respect node access levels? To the technical point, I made it inherit from views_handler_field rather than from views_handler_field_node_link on purpose as views_handler_field_node_url has nothing to do with "links".

Cheers

Marking #465986: "Output this field as a link" doesn't work with "Node:Link" token as a duplicate.

@mais, can you review this patch http://drupal.org/node/465986#comment-1780982 for this issue. I think is a better approach than create a new handler. Maybe we can provide a merge between #25 and #465986-7: "Output this field as a link" doesn't work with "Node:Link" token

@dagmar, will look into it. Avoiding new handlers is certainly a good thing.

@dagmar, I've looked into both patches and merged them both:

1. Added two option definitions to views_handler_field_node_link: absolute_url and raw_link (the same that was made in #25 and in #465986-7: "Output this field as a link" doesn't work with "Node:Link" token);
2. Added if statement in render() to check for both options (absolute_url and raw_link);
3. In these files changes were made:

views_handler_field_node_link.inc, 
views_handler_field_node_link_delete.inc, 
views_handler_field_node_link_edit.inc, 
views_handler_field_node_revision_link_delete.inc, 
views_handler_field_node_revision_link_revert.inc

diff -urpN views-dev/modules/node/views_handler_field_node_link.inc views/modules/node/views_handler_field_node_link.inc

@maijs looks good, however the patch doesn't apply, you should create the path inside the views module directory.

From: http://drupal.org/patch/create

Contributed module/theme patches:
Run the diff command in the module or theme's root directory. (Example: /sites/all/modules/foobar).

This review is powered by Dreditor.

It is a very good feature. We should add this feature in Views modules.

@dagmar, thanks for the note regarding the diff command. Point taken.

I've created another patch with guidelines followed.

Cheers

I've checked the grammar in option form element description and added this at the end of raw_link description line: '"Text to display" field value will be ignored.'.

Use this patch.

Nice job!, ok, I tested it and it seems to be working fine. However probably raw options for edit and delete links are not very useful. See attached image.

I think this patch should provide:

Link view: Node (absolute, raw)
Link edit: Node (absolute)
Link delete: Node (absolute)

Unless you have a valid use case for this options....

@dagmar, you have a point. I don't really see an use case for raw links for administrative links (delete, edit, revert) just like I don't see the need for absolute URL for these links either. But, as absolute and relative attributes are essential to links in gerenal, I agreee those should be included.

Removed raw link option from link delete, link edit, revision delete, revision revert.

I wonder whether that would be the case with comments links also...

@maijs Yes, absolute and raw url comments would be useful too. Can you include it into your patch?

@dagmar, I will look into it.

@dagmar, as I'm currently not using comments on my site, I will postpone patching comments handlers until I have some spare time. Sorry.

Ok, I wasn't too hard. Here is a new patch including absolute url for comment links and only raw url for view comment links.

@dagmar, it's allright although you've forgotten to alter views_handler_field_comment_link_delete.inc therefore delete links were not affected. I've added absolute_url option to comment link delete handler. I've also changed the order of functions in comment_link_reply handler as options_form() traditionally comes before render(). It's wise to keep consistency. Otherwise the patch is the same.

Lines 247 and 277 contains a few whites spaces. But this works fine.

Nice work!.

Hmm. This uses l() rather than converting it to the advanced_render() form of using link rewriting. Maybe this should be a global flag in link rewriting?

Subscribe.

Moving to needs work based upon my l() comments.

With the jump menu an url alias field would be nice because the node/[nid] is not aliased when jumping in from the jump menu (from ctools)

Lets remove this issue from the alpha 2 blocker, and fix it in this issue #669636: Re-structure all links handlers to support advanced rendering of links

This is called fixed. Because of the issue linked by dagmar