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.This issue is pretty exciting :)
Patch automatically creates CTools plugins from the metadata info, similar to who CTools auto-creates plugins for fields.
Attached screenshot shows an example. This means that just by defining metadata you are able to use it with Panels!
Next step after getting this issue in is probably to auto-create "access" for the metadata access callbacks.
| Comment | File | Size | Author |
|---|---|---|---|
| #11 | 1138708-token-content-type-11.patch | 3.5 KB | amitaibu |
| #9 | node-tokens.jpg | 22.6 KB | amitaibu |
| #9 | 1138708-token-content-type-9.patch | 3.5 KB | amitaibu |
| #6 | token-plugin.jpg | 97.79 KB | amitaibu |
| #4 | 1138708-token-content-type-4.patch | 3.46 KB | amitaibu |
Comments
Comment #1
amitaibuRelated issue #1061550: Auto create CTools access plugins from entity-metadata based on CRUD permissions
Comment #2
fagoAs said in IRC, I'm not sure about using entity properties which represent plain data for output content. Well, it works for "text" data types, but for that case the token system does a better job.
For everything else, I think we are missing something like a data formatting API based on plain data types. Thus something like field formatters, but suiting for any entity property. Without out that, I don't see much value in that patch for providing content plugins. Of course, I'm fine if you want to roll this in your own contrib.
Another kind of ctools plugin integration that would make sense is for entity relationship, but Ctools has already rather complete support for those based on the db-schema information. An integration based on the entity metadata would work in other no(n)-sql situations too, though.
Comment #3
amitaibu@fago,
> but for that case the token system does a better job
I think this is very true, so moving this to CTools issue queue, and changing patch approach:
Patch auto declares plugins for tokens. Why not just use custom content type with token replacement? Because a plugin has a title, description and it's alterable.
@merlinofchaos,
The patch doesn't use the token context provided by CTools, as I don't think it's really needed - is it legacy code, or am I missing something?
Comment #4
amitaibuPatch adds "sanitize" option, which is enabled by default.
Comment #5
merlinofchaos CreditAttribution: merlinofchaos commentedWow, every token as a content type? That's going to really explode the list content types, won't it? Is this going to be a management hassle when there are lots and lots of tokens?
As for the token context type...I no longer remember exactly what that was for. I think it was meant to be a way to get non-context tokens into the system and never actually got fully implemented.
Comment #6
amitaibuHere's a screenshot from my local, when entity-token is enabled. Since that the plugins have required context" they appear only in their right category.
I myself prefer to have more options rather than less, even if I have to browse more, but maybe a possible solution it to create a new category for each entity -- e.g. "Node (tokens)" -- and have the plugins there?
Comment #7
Shadlington CreditAttribution: Shadlington commentedI think a separate category would be a good idea, though I don't think the number of options in that screenshot is overwhelmingly large.
This is definitely a useful feature.
Comment #8
merlinofchaos CreditAttribution: merlinofchaos commentedAt the very least I think they should have a prefix. That is a lot of data right there, and when users have dozens of fields, that screen is going to get messy. I think a separate category is probably the better choice.
Comment #9
amitaibuChanged category to @entity (token) -- see screenshot.
Comment #10
Shadlington CreditAttribution: Shadlington commentedTypo in the category name.
In "'category' => t('@entity (toknes)', array('@entity' => ucfirst($entity_type)))" toknes should be tokens.
Comment #11
amitaibuFixed typo.
Comment #12
merlinofchaos CreditAttribution: merlinofchaos commentedCommitted. We should keep an eye on this in terms of performance. I'm hping that adding all those tokens as content types doesn't slow things down.