Hi All,
Thanks for a great module. I'm trying to make pathauto construct hierarchical urls using cck-nodereference fields for the hierarchical relationships. And I have some questions about the tokens that are created for nodereference fields. As far as I can see the only usable token is [fieldname]-nid. Is this correct, or are the *-title and *-link tokens populated in certain circumstances?
<?php
$tokens['nid'] = $item['nid'];
$tokens['title'] = strip_tags($item['view']);
$tokens['link'] = $item['view'];
?>When is the view attribute present? A var dump of item gives me this:
array(2) {
["nid"]=>
string(1) "2"
["error_field"]=>
string(35) "field_related_subject][0][node_name"
}Is it too costly to populate tokens with the path to the referenced node ("node/{$item['nid']}" or drupal_get_path_alias) or other info through node_load? Is this some kind of legacy behaviour?
Would it be possible to add this to nodereference_token_values:
<?php
/*
TODO: Check why this isn't here in the first place, maybe there are huge
performance penalties for doing even the lightest lifting for tokens
*/
if(isset($item['nid']))
$tokens['path'] = drupal_get_path_alias("node/{$item['nid']}");
?>...sans todo.
To take the discussion further than "how do I get the token I want" :) Why is the cck-support hard-coded into the token module? It would be great to be able to alter the way token interacts with cck without meddling with the token module itself. Please tell me if I've missed some great hook or function that allows me to do this.
Cheers
Hugo
Comments
..
Code changes are best discussed in the issue queue. Can you create an issue? (if you haven't already).
The cck support is hard coded into token because when token was first created, the cck folks (among others) weren't so excited about having support for a fledgling module in their module. Now that token is more important/useful the hook_token_* are being moved back into their rightful places.
If you are the maintainer of a cck module and would like to move the code into your module, we can coordinate that process like we did for date module in the 5.x-1.11 release. Otherwise, it's still a matter of a patch to one module or another...so...
--
Open Prediction Markets | Drupal Dashboard
knaddison blog | Morris Animal Foundation
token & others
I understand that the CCK people can't support every promising upstart module. But wouldn't it be nicer to separate all such code (cck, taxonomy, comment) into middle-tier modules?
largely a moot point
This is largely a moot point as it relates to token and cck. Token did what it had to initially and now the code is migrated (or migrating, in some cases) into the cck modules. But it's an interesting topic in the realm of other integration modules.
By middle-tier module I assume you mean either a "token_cck_helper" module where the token+cck code could live or a "cck_helper" module where any cck related code from other modules could live.
I'm opposed to the idea of token_cck_helper because that would mean yet another project page on d.o, yet another cvs directory, yet another file to download, etc. In fact, the code was segmented into the .inc file quite nicely so that it could be copy/pasted and removed from token.module with minimal fuss.
I'm opposed to the idea of a general "cck_helper" module for many of the same reasons (yet another project, yet another thing to download) but also because it would become a dumping ground of low quality code from a variety of upstart projects which often get neglected and dropped quickly, so it would be difficult to manage for anyone that was the primary cvs maintainer.
So...I think it was solved the best way in the start and that it's resolved itself pretty well.
What do you see as the benefits of the middle-tier approach?
--
Open Prediction Markets | Drupal Dashboard
knaddison blog | Morris Animal Foundation
moo point maybe :)
I see what you mean. But couldn't the token project contain multiple modules (just as cck contains fieldgroup and nodereference). So instead of packaging the stuff that adds hooks on behalf of other modules as .inc's, the could be put into .module & .info-files with proper dependencies. No extra downloads and no extra cvs directory.
The reason for this middle-tier crusade of mine is that I hate to make changes in other peoples modules. I cannot change the way tokens are created for any of the modules in the inc-files without modifying your files. As soon as the mainainters releases a new version I or the site maintainer will have to remodify the changed files. Messing with other peoples modules makes upgrading a hassle. I guess that configuration options for token that could be used to disable support for external modules would also fit the ticket.
btw...
Thanks for taking your time to discuss this. Much appreciated :)
ok, but
I agree that "hacking" a module file is never a good idea - but that means the best solution whenever you make a hack is to make it good enough for inclusion in the module and then submitting it as a patch.
If the problem is a collision between the way that token module implements hook_token_values on behalf of some module and the way that you've done it, the solution (IMO) is to contribute your changes to wherever they need to be so that everyone benefits from the improvement.
You said
There are some situations where you really just need your own private hack. And in those cases the ease of "just hacking" the code is offset by the pain of having to re-apply it, which is not a token or module problem, but a general one that all admins deal with.
--
Open Prediction Markets | Drupal Dashboard
knaddison blog | Morris Animal Foundation