Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.It's frustrating to see what happens to the available tokens on the site once the entity_metadata module is enabled because it duplicates of lot of existing tokens that core provides and will just end of confusing the user. Plus, if the user uses these tokens in token strings then the entity_metadata module is disabled, these tokens will stop working because they weren't using the proper core tokens.
Examples:
[comment:pid] duplicates [comment:parent:cid]
[comment:nid] duplicates [comment:node:nid]
[comment:uid] duplicates [comment:author:uid]
[comment:subject] duplicates [comment:title]
[node:uid] duplicates [node:author:uid]
[file:uid] duplicates [file:owner:uid]
[term:vid] duplicates [term:vocabulary:vid]
[user:login] duplicates [user:last-login]
[site:current-user] duplicates [current-user:*]
[site:current-date] duplicates [date:*] (I have an open issue in core to fix this namespace and make it [current-date:*])
| Comment | File | Size | Author |
|---|---|---|---|
| #10 | entity_duplicate.patch | 12.94 KB | fago |
| #7 | entity_duplicate.patch | 9.78 KB | fago |
Comments
Comment #1
Dave ReidPlus another problem is token.module unsets $info['tokens']['node']['tnid'] because it provides [node:source] which is a chained node token (although token module doesn't prevent [node:tnid] from being replaced - it still works. But now entity_metadata will think that it can add that token_info back in, and worse, now we have two modules that are returning a value for $replacements['[node:tnid]'], which gets converted into an array.
I think we need to add some kind of 'token' => FALSE to all existing entity_metadata properties that are already covered by core tokens.
Comment #2
fago>Plus, if the user uses these tokens in token strings then the entity_metadata module is disabled, these tokens will stop working because they weren't using the proper core tokens.
Well, I guess that's what happens as soon as any token provider module is deactivated.
>Plus another problem is token.module unsets $info['tokens']['node']['tnid'] because it provides [node:source].
So then why are you unsetting it? This just creates an inconsistency between what works and what is in the token info.
>[comment:subject] duplicates [comment:title]
It's called comment:subject. The core token is wrong here, I guess we should do a patch.
>[user:login] duplicates [user:last-login]
Last-login makes sense to me as it is more descriptive. Changed it to follow that.
>[node:uid] duplicates [node:author:uid]
>[comment:pid] duplicates [comment:parent:cid]
>...
Indeed, but in the end the comment:pid token is faster than the chained token. And as it comes for free, why bother removing it? Also for devs stuff like node:uid is probably obvious to be there.
Comment #3
Dave ReidSee, but this shouldn't be a problem for core tokens. I think Token module itself can be granted leeway since it's meant to the token provider for missing core tokens.
Drupal's content type UI says "Allow comment title" although then it uses "Subject" in the actual add comment UI, which is presumably to make it easier for end-users.
Because we want to direct people to use the proper chained token of [node:source:nid] (again its about using proper context), just like I think it's wrong that entity_metadata provides [comment:nid].
I just think this is fundamentally flawed. We already have working tokens with the chained ones that make a lot of sense context-wise to end users. And now there's duplicate tokens. Imagine an entity with a ton objects referenced/connected to it in a similar situation like [comment:node]. Are you going to add a shortcut token for every, single chained token? This litters the base token type's namespace with a bunch of unnecessary tokens. It makes the token UI longer and harder to scan, etc. This is why we 'removed' [node:tnid] from the token UI and have people use [token:source:nid] instead.
Comment #4
fago>See, but this shouldn't be a problem for core tokens. I think Token module itself can be granted leeway since it's meant to the token provider for missing core tokens.
Hm, I'd not say the token module has more rights to do so than entity metadata, but I see the point that it isn't so obvious for end-users. Actually, I think a small separate module just for providing tokens might help here - as that way users would have to explicitly enable
entity_metadata_tokens, what makes it obvious for them that it is providing tokens.>Are you going to add a shortcut token for every, single chained token? This litters the base token type's namespace with a bunch of unnecessary tokens. It makes the token UI longer and harder to scan, etc. This is why we 'removed' [node:tnid] from the token UI and have people use [token:source:nid] instead.
That's a point - I guess it applies to entity metadata properties in general and also applies to the bundle property <-> bundle objects. Also, there is no such property for fields containing references of course, thus removing them would be probably more consistent.
Opinions someone?
Comment #5
Crell CreditAttribution: Crell commentedI'd rather have longer, more-standard, more self-documenting tokens than short-circuited ones that I cannot dissect from looking at them. The *last* thing we need is multiple standards for tokens floating about. Core has one, use it.
Comment #6
fagoIndeed, I didn't realize core follows that as I missed #831914: Redundant [node:uid], [comment:uid], and [file:uid] tokens. Anyway, I agree so I'll take a stab on that and fix it generally for entity metadata properties to follow that guideline - including bundle properties.
Anyway, I really think we should focus on a common naming for tokens and metadata properties, so this ends up being consistent for users. Related to that, see #967136-4: Content type tokens.
Comment #7
fagook, here is a first patch (WIP) removing the duplicate id properties. Also $node:tnid is not yet converted as we miss the source node.
Comment #8
fagoComment #9
fagook, finished it - thus attached patch also includes node:source. There is no [node:type:name] or such though, as content types are no entities, thus out-of-scope for entity-metadata.
Comment #10
fagoComment #11
fagoI've gone ahead and committed it, please re-open if you think there are still any duplicates.