Drupal 6.x allows the creation of custom user profile fields. It would be excellent to be able to access these in Custom Breadcrumbs as this would, for instance, allow the username of bloggers to be replaced with their blog name (defined as a custom user profile field) in breadcrumbs.

Doesn't seem possible at present?

CommentFileSizeAuthor
#3 custom_breadcrumbs_module-user_tokens_1095348.diff1.19 KBMGN
#3 custom_breadcrumbs_admin-user_tokens_1095348.diff451 bytesMGN

Comments

thepanz’s picture

thepanz commented

Custom Breadcrumbs can use Tokens to render user-data into breadcrumbs.
Search if Token can provide user profile fields as tokens.

Regards

MGN’s picture

MGN commented

Found an untested patch for the token module to add profile support at http://drupal.org/node/125640#comment-1070066. I am not sure if this is what you are looking for, but it might be. When I get a chance I'll test the patch myself, and see what new tokens become available.

MGN’s picture

MGN commented
Assigned: Unassigned » MGN
StatusFileSize
new custom_breadcrumbs_admin-user_tokens_1095348.diff451 bytes
new custom_breadcrumbs_module-user_tokens_1095348.diff1.19 KB

The profile support patch (link in #2) works fine for me. To make the custom user profile fields available for custom breadcrumbs 6.x-1.4, 'user' type token replacement needed to be added (current version only supports 'node' tokens). This just took a minor addition.

If you apply the profile support patch and the custom_breadcrumbs_module...diff file, you should be able to use custom user profile fields in custom breadcrumbs via token replacement. Note that on the cb add breadcrumb form, under placeholder tokens it will only list node type tokens. I thought about making it list 'all' token types, but that is misleading because the patch doesn't support all token types. I really wanted to display just the user and node tokens, but the theme_token_help function takes only a single token type. The optional step below fixes that problem....

[Optional - two additional patches to display both user and node tokens in the placeholder tokens section of the add breadcrumb form.

Patch to the token module to process multiple token types in theme_token_help: http://drupal.org/node/127072#comment-1098174.

Once that has been applied, the custom_breadcrumbs_admin....diff file can be applied to also display the user tokens on the add custom breadcrumb form....again this is optional, so don't bother if you don't care about whats shown under the token help.]

babbage’s picture

babbage commented

Great—I've got all this working... except, it displays the custom profile field value for the *currently logged in* user in the breadcrumb, rather than the custom profile field for the author of the page in question. In other words, it doesn't show the name of the blog author, it shows the name of the user viewing the page. D'oh.

Any leads on how to correct this?

ETA: Found another problem with this. Subsequently found the realname project which actually did all I was trying to achieve with the current modifications anyway. Discovered that the two modules conflict with each other, because the realname module makes the custom profile fields for the real name visible as a Token for the node, but the current modifications then also make the realname token visible for the user account, and that one takes precedence. Reverting the changes from here to the original and using just the realname module ended up achieving what I was looking for. Just in case this helps anyone else figure out this odd interaction...

MGN’s picture

MGN commented

Ah, I see what you are trying to do and I don't know how to do this through a user token. One way to make that work would be to have $node->name set to the blogger's name contained in the custom profile field and then use the [author-name] token in the custom breadcrumb. This is a node-based token and doesn't require any of the patches above. I use the RealName module to do this http://drupal.org/project/realname , but I think you could also do it at the theme layer?

babbage’s picture

babbage commented

I hadn't refreshed this tab after last loading my post above so made my edit well after your post, but before I'd read it! I think I have things working in this regard now. Thank you!

MGN’s picture

MGN commented

I am trying to understand the conflict reported in #4. As I understand it, realname doesn't provide a token, just a custom profile field and it sets $node->name to that value after the node is loaded (in hook_nodeapi: ($node->realname = $node->name = realname_make_name($account)). This way, the [author-name] token is replaced with the value of the custom profile field.

The patch modifications in #3 provide the [custom-profile-field] user token. Just not seeing where the conflict is coming in....

babbage’s picture

babbage commented

Ah... realname does provide a token—[realname]—and that is what I was using. When the patch modifications are applied it exposes the version of this token that applies to the current user, as well as the version of this token that realname already makes available that applies to the node.

However, if I can simply use [author-name] then the problem is probably solved. Actually, that solves two problems because it turns out [realname] is not much good for a link in custom breadcrumbs because it does not do the automatic reformatting that pathauto does so you end up with both capitals and %20s in your link if you have the realname set to "Firstname Lastname".

Will post an update when I have re-installed this patch and tried the alternative (probably standard) approach. :)

babbage’s picture

babbage commented

Hmm... in some contexts (e.g. the user profile page itself) using realname replaces the login username with the real name. However, the token [author-name] in Custom Breadcrumbs is unaffected by these changes, with [author-name] continuing to give the login username. This is probably why realname provides the [realname] token.

With the patches described in this thread, I was able to construct most of what I wanted in Custom Breadcrumbs by using [profile_first_name] and [profile_last_name], the two custom profile fields I had created to make the realname. However, I still have the problem that when I construct the path to my columnists for their views listing (/columnist/firstname-lastname/) the link has capitals whereas the actual URL alias that has been constructed with the token [realname] is converted to lowercase.

I know this isn't a general support thread, but if anyone has any suggestions they would be appreciated. :)

MGN’s picture

MGN commented

I see now. I am still using an old version of realname 6.x.1-0 and token support wasn't added until 6.x-1-rc1. Looks like an upgrade is in order!

Any chance you are using the 'special identifiers' patch for custom breadcrumbs #296516: Clean path using pathauto function, (and its also include in the patched version at http://drupal.org/node/323816#comment-1082064) ? With this patch, when you use the special identifier <pathauto>| in front of your path, the path is cleaned using pathauto rules. This has taken care of capitalization and whitespace inconsistencies for me. You might want to give that a try. If it works for you, please leave some feedback on that issue - perhaps some of these patches might make it into the next release of custom breadcrumbs.

babbage’s picture

babbage commented

OK. Well I have installed that version of the module and it partially works—it is correctly converting spaces to hyphens in the [realname], but it is failing to convert capitals to lowercase, even though pathauto is set to do so, and even though pathauto is indeed doing so on the [realname] tag when it is creating the actual URLs. Seems a bit odd. Hmm...

ETA: It is certainly passing the path through some sort of pathauto filtering, because if I remove the <pathauto>| it then inserts %20s instead of hyphens... so I know it is operational.

Further edit: Interesting. The issue is that pathauto_cleanstring cleans the string but the change to lowercase that is made in pathauto_create_alias is not included in pathauto_cleanstring, the version made available to other modules. That doesn't make sense to me—and modifying that single line of code from pathauto_create_alias for pathauto_cleanstring seems to work just fine. I'll try and submit a patch to pathauto and will link to it here when I've got it sorted.

Final edit: Patch submitted: http://drupal.org/node/343851

MGN’s picture

MGN commented
Category: feature » support
Status: Active » Fixed

No longer a custom_breadcrumbs issue. Still waiting on patches in the token and pathauto issue queues to fully implement these ideas.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.