Argument tokens using arg()

$args[0] is just arg(0) right?

So, yeah, we should probably support those.

Well, if the args are special things in Views then the hook_token_list and hook_token_values implementations for them should happen in Views itself.

Uhh. $args is a special variable available in the views arg handling PHP snippet and not even related to token. This issue doesn't even make sense.

Ok.

There is no way to do it now. It would require additional code - probably in token.modules token_token_list and token_token_values.

However, the dynamic nature of arg() (i.e. the fact that you can have an arbitrary number of them) means that this should probably be implemented with the whole "token 2" implementation.

If someone wanted to make a patch for arg0, arg1, arg2, and arg3 that would work for the most common cases up until that point I would be happy to commit that.

Summit:
Please read the API.txt file that comes with token module. it explains how you can expose more valeus to token. one such value ofcourse can be arg(0) or arg(n).

dont open this issue again, if you have questions about how to create a module to expose those values you can ask that on the forum.

good luck.

@litwol - I agree with most of what you said, but I think arg's are at least somewhat reasonable tokens to expose for use and the proper place for such a global token would be in token itself.

Id sure like to see this as a 5.x feature. Or at lease SOME way to point the current uid ($arg(1) to the path of a menu item)... I have been beating my head on this one for days, and the only solution I have heard is the best way is to use token, but how can I use token if it doesn't support arguments.

Kostly

So I've been able to add tokens arg0, arg1, arg2 and arg3 by adding them in the token_node.inc file. What I really wanted to do was add them to a new token_arg.inc file. I did add require_once("$path/token_url.inc"); to token.module, but the new tokens neither show up in a list of available tokens, nor do they work. In the token_node.inc file they show up in the list, and, more importantly, they work.

I'm sure I'm just missing some little step, but even reviewing other modules and how they define tokens hasn't enlightened me.

Any suggestions?

Thanks.

P.S. I'd rather see something like [arg:0] or [arg(0)] or some such thing that would allow an argument to be passed with the token. I gather from one of the comments that such a thing might be coming in a new version of token?

@colin_young - if you post the non-working code as a patch then we can discuss why it isn't working.

And...while [arg:0] are a good idea it's probably not in the timeframe for adding this patch to this module.

@greggles - Sure. Attaching the files here. (Is there some way to create a patch containing multiple files without CVS? I really should install some sort of revision control -- or just start using my subversion installation :) -- but I really hadn't been planning on mucking about in drupal code.)

My comment about a future version supporting arg:0 was prompted by your comment about a "token 2" module, which, I'm guessing, is way off in the future. I assume that arg0, arg1, etc. is a hack that would be retired if/when a token 2 module was released.

In fact, these are probably global tokens that should be added to token.module's hook_token_list and hook_token_values if added anywhere. That should eliminate the include problems.

@Summit - token_arg.inc was a file name I started with before I realized it should be called token_url, or as greggles suggests, put into a more appropriate existing token file. I'm going to make those changes now and submit a new patch.

@greggles - took your suggestion and trying again.

To handle aliases, you can use drupal_get_path_alias($_GET['q']) and then run the returned path through arg to get the components.

This patch provides [argX] and [argX-alias] tokens, where X can be 0, 1, 2, ... up to a defined value (so you can have as many args as you want, but I left the maximum at 4 as in colin_young's patch).

updating status to reflect the new patches in #16 and #18

subscribing

Patch works for me. Thanks for all your work on this, it's an excellent addition!
Jen

Here's a new version against the token starter kit. Otherwise it is copy and paste and untested.

@MGN, @jenlampton - Thanks for your work. Drupal's coding standard is generally not to use inline comments and to make comments full sentences with a capital letter and a period on the end, so not quite RTBC ;)

Thanks greggles. I think the starter kit is a good idea and a good place for these tokens.

It looks like you copied and pasted the code snippets into the wrong functions (swapping token_list and token_values). Here is a new patch that fixes this problem.

This patch is a critical part of a module i'm writing called Custom Reports (http://drupal.org/project/customreports) - subscribing.

@a_c_m, does this mean that you have tested the patch in #23 and can confirm that it is working?

Not quite.

patching file tokenSTARTER.module
Hunk #1 FAILED at 1.
Hunk #2 FAILED at 20.
Hunk #3 succeeded at 68 (offset 16 lines).
2 out of 3 hunks FAILED -- saving rejects to file tokenSTARTER.module.rej

But the code itself worked fine. I would quite like to see it not need TOKEN_NUM_ARG_TOKENS and instead just work out how many args there are in the current request and use them.

Perhaps also allow for named arguments e.g. /node/123?name=frank then being able to use [arg-name] etc etc

I've attached the patch re-rolled to apply cleanly to the latest revision.

I would quite like to see it not need TOKEN_NUM_ARG_TOKENS and instead just work out how many args there are in the current request and use them.

Agreed. Marking needs work for that.

Perhaps also allow for named arguments e.g. /node/123?name=frank then being able to use [arg-name] etc etc

So, [arg-name] would contain "frank" ? That seems like a query string parameter, not an "arg" and therefore a different feature request. I'm also not sure that belongs in the STARTERKIT.

I agree with greggles on the query - its not part of the url...

Here is a leaner patch that doesn't require that constant.

Tested MGN's patch (#28) and it works as expected.

I tested patch in #28 and it worked as expected, tests conduced under E_ALL and no notices/errors were generated. i used automatic node titles module to test this.

token used: [arg0]-[arg1]-[arg2]-[arg3]
node title generated: node-2-edit-[arg3]

Missed to change status.

Would not it better if the code could replace "[arg-3]" with an empty string, if the argument does not exist? If I call arg(3) in such case, I would get a NULL value.

I now agree with Kiam, but I'm unsure how to do this. How far up through args should we go getting null values? To 10?

To do what Kiam suggests would require defining some arbitrary constant to do a null token replacement, which greggles and a_c_m didn't seem to like. There will probably be a slight performance hit, but probably insignificant. Its easy enough to do.

Just tell me what arbitrary number of arg tokens we want to null out, and I can create a new patch.

Also, it seems the default is for tokens to go untranslated if there is no replacement value. Sometimes this results in an annoying [token] popping up where you would prefer to have nothing at all.

So perhaps its worth considering if token_replace (et al.) should be altered to automatically filter out any untranslated tokens?

oops. cross posted with greggles.

So perhaps its worth considering if token_replace (et al.) should be altered to automatically filter out any untranslated tokens?

My feeling here is that hook_token_values modules should default to '' and then put in the value when necessary. The reason being:

1. I don't want to make token replacement any more complex than it has to be for performance reasons.
2. There are legitimate reasons to use text like "[something]" and want it to not be replaced with an empty string.

I am very sorry to have changed my mind on this issue - @MGN - are you up for one final re-roll? Thanks!

I agree. I realized after I made the suggestion that other modules also use square brackets as a signature and nulling out [something] would certainly interfere with those modules. Anyway, I am happy to do as many rerolls as it takes - not a problem. Its better to get it right.

Since its in tokenSTARTER and designed to be modified, the actual value I assign to TOKEN_NUM_ARG_TOKENS doesn't really matter, though it would be best if it worked as expected in most circumstances. I think 10 is a fine number.

Are we settled on nulling out [arg-N] for unset arguments through [arg-10] ?

What I was thinking of is the Drupal core code that passes $arg to hook_help(); if I remember well, that argument is an array with X elements, which by default are empty strings.

The called function executes the following code:

function drupal_help_arg($arg = array()) {
  // Note - the number of empty elements should be > MENU_MAX_PARTS.
  return $arg + array('', '', '', '', '', '', '', '', '', '', '', '');
}

To do what Kiam suggests would require defining some arbitrary constant to do a null token replacement

I think there is already a constant for the maximum number of parts a menu string should be made of; it should be also the maximum value accepted by arg().

EDIT: arg() doesn't set a limit for the $index argument it accepts, but it's more probable that passing a value higher than MENU_MAX_PARTS the function doesn't return a value at all.

Yes, it seems our constant can be based on MENU_MAX_PARTS.

Here is a patch that creates a fixed number of arg tokens, based on the value of MENU_MAX_PARTS. All [argN] and [argN-alias] tokens will return null when arg itself returns null.

Still, I am not completely convinced that basing the number of tokens on MENU_MAX_PARTS make sense.

As Kiam points out, arg() itself doesn't set a limit. And I have verified that you can use arg() to retrieve as many parts of the url as you like (I tested up to 10) for use in a module callback page. Its true that only the first MENU_MAX_PARTS of the path will be used in identifying the menu item in the menu_router table. But that doesn't mean that module developers won't use arg() directly and exceed this limit.

Then again, MENU_MAX_PARTS is defined as 7, and this should cover most cases just fine.

This is a one year old issue. I am happy people are working on this and I would love to see this feature but maybe we have gone about this the wrong way.

Maybe we need to first include the ability to add variables to people who create tokens? For instance, I may want to create a token [comment-42]. I think doing this would ultimately solve a multitude of issues (and ultimately close this ticket).

@MGParisi. I am not sure if I understand what are looking for, but using the tokenSTARTER module, you can create your own custom tokens.

Maybe we need to first include the ability to add variables to people who create tokens?

This doesn't seem to be related to the current issue, so you might think about opening a new issue if you want to develop the idea further.

I am interested in "closing this ticket" however.

A couple of months ago greggles asked for the re-roll in #41. Anyone willing to test it so we can move to RTBC?

I have used the patch in #41 to solve an issue I had with Custom Breadcrumbs, as can be seen here: Taxonomy breadcrumb with the taxonomy view. So I can confirm this works.

Me too. Working fine.

Thank you!

I can work on this again if the maintainers would be interesting in moving this forward.

New tokens need to be put into D7 first, then backported. Still not sure sold on this token.

Why not stick it in the tokenstarterkit or the examples module?

That's the home for things we are unsure of and it seems we are still unsure of it.

I guess it would actually make a lot of sense to add a new 'Current page' grouping in D7 tokens, where we can put stuff like args, query strings, canonical urls, etc.

Yeah, I can see the benefit of that broader group.

#12: token.module.patch queued for re-testing.

Does anyone know if this same idea could be used with a taxonomy tags list?
I'm trying to find a way to use a token in nodewords for an Authors taxonomy entry to use in a meta tag. The field can have a single name, or several. I've been able to edit template.php so to completely theme my taxonomy output, including adding to $vars a new $authors variable so I can output a comma separated list of the names.
I tried to experiment with a modified version of what was tried in #51, but it didn't work. I would love to hear if anyone has any ideas.

Subscribing.

subscribing

Committed #62 to CVS! http://drupal.org/cvs?commit=451680

subscribe.

sub

I am closing this issue since it's for a Drupal version that isn't supported.