Provide tokens for node url and path (i.e. absolute and relative alias respectively)

Just making the title a little more descriptive.

I'm also not sure the body or preview are part of the spirit of token module.

only eaton knows for sure, but i do think body and url are valid and useful tokens. not sure what preview is.

I take node-preview to be the teaser. Right?

what is the status on this - seems like a good feature.. maybe there is an existing feature?

Basically the status is that building the node body and teaser is expensive (afaik) and token is already maligned as being a performance hit. So, this is more or less postponed like many other expensive tokens until we have a system and benchmarking tests to

1) Provide a token registry with names and associated callbacks
2) Find tokens within the $original and only call the token-builder callbacks for those specific tokens
3) Proves that this is faster with benchmarks

What about a separate issue just for the node's URL, then? Seems like that's pretty cheap and incredibly useful.

In IRC, Eaton voiced support for [url] == absolute URL to the node, [path] == relative drupal path (both care of url(), just depending on the final $absolute arg). He said he's willing to commit that much now. Here are patches for the end of DRUPAL-5 and DRUPAL-6--1 branches. I tested the D5 version (I don't have a D6 test site w/ token setup ATM), but it seems trivial.

I'd rather see these tokens as node-path and node-url so there is no confusion about what the mean in a situations where tokens from multiple realms are being mixed together.

If you agree with the idea then I can tweak/commit.

Works for me. I was just being consistent with everything else -- none of the other node-realm tokens have a "node" prefix (except in their descriptions). But, if you think it's important to use them for these (and not things like [yyyy]) ;) I certainly have no objection. Maybe eaton should weigh in with his thoughts before this lands one way or another, just to be safe?

Thanks,
-Derek

IMO lack of a prefix on things like yyyy is a bug and we shouldn't let that bug's pattern spread to the rest.

But indeed, as you prefer, let's wait for eaton's review ;)

Cool, sounds good to me. FYI: I'm going to be AFK until Sept 1, so if this needs a re-roll, someone else will have to carry the torch for a little while. Thanks.

imo the patch from #7 is really much missing - how to link to a node with url alias else?

simple and really useful!

The patch from #7 for d5 is fine, however for d6 it was broken. I fixed it, re-rolled and tested it -> patch for d6 attached.

Patch token_url_6.patch works great for me with D6. Thanks!

I applied this patch to 6.x-1.x-dev for December 11, 2008, and when I have an email sent when a file is ready to publish, the email still comes over as

Joey at Hootersville Community College %title is ready to publish at %node_url.

Joey = %username - works fine
Hootersville Community College = %site_name - works fine
%title - not so much
%node_url - not so much

Am I using the patch with the correct version of Token? Thanks.

subscribing

I saw that in the new Mar 25 dev version some of the node-related token issues were fixed for comments. I tried it to see if it fixed it for my not-comment-related issue, but it did not.

Again, my issue is that I wish to trigger an email using Workflow/Actions that includes tokens for %site_name, %username, %title, and %node_url. Only the system tokens, %site_name and $username, work for me.

My resulting email is: Hometown Community College writer Joe Student has written a post called %title which is ready to publish at %node_url.

Thanks.

Sigh...still confused. I have one site running 6.x-1.12 and it expands the token %node_url just fine.

Another, seemingly identical site does not. Just tried upgrading to the latest dev, and still does not expand the node url...although other tokens are expanding just fine.

What's the deal with this issue? In terms of token utility, being able to fire an email with a clickable URL would (to my thinking) be one of the top usecases...but even over at groups/token a search on node_url shows nothing much...

Really would love to see an answer to this one.

Sorry: just checking back to see if there are any further thoughts on what makes the node_url token expand (or not) ?

Attached is a patch for 6.x-1.x-dev which is essentially the same as fago's in #12 with the 2 added token for a rendered URL.

I know a URL could be formed using the [title] and [path] tokens from 12, but that relies on the user inputting them to know HTML. This token provides the output from drupal's link function which has the minor added advantage of a title and an active class (if the same URL).

This patch would greatly enhance the new features I'm working on for Relevant Content which will soon allow users to enter Token's to render the output.

Thanks,
Nick

Subscribing, interest in tokens for this sort of purposes, greetings,
Martijn

@ #19 patch: I might be missing something, but (using latest dev version), I get half a patch:

$ patch < token_node_path.patch
patching file token_node.inc
Hunk #1 FAILED at 30.
Hunk #2 succeeded at 181 (offset -10 lines).
1 out of 2 hunks FAILED -- saving rejects to file token_node.inc.rej

advice?

Hmm... I thought I was using the latest dev... Let me try again.

In upgrading from 1.11 to 1.12 and I've lost the [url] token and some emails are being sent with visible HTML tags as if the Content-Type text/html header is missing.

It's been five weeks since #21/#22 -- Any update on this? Have fixes been rolled into dev?

PS, I use the Action_email_role module which requires a patch to token_actions.module (adds function token_actions_send_email_to_role_action() )

subscribing

Subscribing.

Great addition to the token family!

This would be really useful to also use in analytics programs, where they require a unique identifier for each page - node ID is not descriptive enough + not all pages return a 'title' token. Using the URL path would be ideal, it will also self categorise the pages into their URL 'sections'.

Any outlook to get this into the module?

One wonders why this is not in. #19 worked for me quite well. (Disclaimer: this is just for my brother's website nothing Clarity related.)

Any new tokens will need test coverage for them included with the patch.

I've tested #19 successfully, except for one issue:

Using the [path] token, a slash (/) appears before the alias, causing problems.

I don't know enough to figure out in the patch or module what might be causing this to happen.

As far as I know, a path alias must not contain a leading or trailing slash.

Right. And that is the problem.

I've tried using the [path] token in a number of different places and I get the same results every time on different Drupal installations:

- using [path] in Automatic title generation (with auto_nodetitle module)
- using [path] in Titles for Custom Breadcrumbs (with custom_breadcrumbs module)
- using [path] in File alias (with file_aliases module)

When the URL path settings field contains example-path, the results are that the [path] token in any of the above scenarios gets replaced by /example-path including the slash.

The File Aliases module is the one where I really want to use the [path] token, but when I use a string such as: [path]/[filefield-onlyname-original].[filefield-extension-original], the resulting link to the file becomes http://www.example.com//example-path/filename.ext with the extra slash.

subscribing.

Hi, Thanks for the patch I've applied the patch and now [title-link-url] and [url] is now working, but I had to do it manually I had same problem with @#21 when using patch.

I noticed I haven't seen the content of the node body, anyway I did it myself and it's working. I just added these two lines

$values['body'] = $node->body;
$tokens['node']['body'] = t('Node body content');

node-path (alias of the node) and node-url (absolute URL to node) have been added in CVS (http://drupal.org/cvs?commit=383050). Sorry I should have posted my patch here but I didn't find the issue soon enough.

Adding an node-link token should be a separate issue since it will require us to add it into token.module for D7 first, then backport.

I would love to see ['path'] get into Tokens..

I added the following lines to the module to get it working. Seems fine to me. (sorry no patch!)

function token_token_values($type, $object = NULL) {
..
$values['path'] = drupal_get_path_alias($_GET['q'], $language->language);

function token_token_list($type = 'all') {
..
$tokens['global']['path']    = t('The path of the current Drupal page.');
..

Subscribe!

@andrewsuth, @OFF, it's now it 6.x-1.x as [current-page-path]

Thanks dave!

Thanks!