imho, $data['entity_type']['translation_link'] definitions should be moved to Content translation module.
Comment | File | Size | Author |
---|---|---|---|
#22 | translation_link-2035587-22.patch | 4.32 KB | vasike |
#20 | translation_link-2035587-20.patch | 4.13 KB | vasike |
#16 | translation_link-2035587-16.patch | 4.12 KB | vasike |
#14 | translation_link-2035587-14.patch | 4.12 KB | vasike |
#8 | translation_link-2035587-8.patch | 4.13 KB | vasike |
Comments
Comment #1
vasikehere is patch for this.
i think this field needs a solution for the broken handler case, maybe #1825896: Add module owner to plugin data on handlers.
Comment #2
vasikeforgot the status change.
Comment #3
vasikeand some tags
Comment #5
vasikeindeed the patch won't fit for user entities: they have "users" table name instead of "user".
i think it requires a fix for #140860: Consistent table names and database handling of table names.
but till then here is a new patch that deals with this issue.
p.s. other issue about the same users table #330983: Rename user module tables to singular.
probably there could be others issues, but the queue it's quite big.
Comment #6
vasikenew patch
Comment #8
vasikeindeed. old code
new patch
Comment #10
plachI strongly disagree: the Content Translation module knows nothing about nodes, comments or any other entities. It's up to the single entity-defining modules to provide the integration code, exactly as they do for Views-related stuff. Aside from an architectural perspective, this won't scale as this way CT would be "responsible" to provide such code for any entity type out there.Comment #11
plachSorry, if this can be done in a generic way I agree it should be in the CT module.
Comment #12
vasike#8: translation_link-2035587-8.patch queued for re-testing.
Comment #13
plachOverall this looks good to me, thanks. I am not sure whether the current approach is the best way to detect entities, so I asked @timplunkett's feedback. Hope we'll hear from him soon :)
Meanwhile:
there is a missing capital letter (or an entire word?) here.
Comment #14
vasikeupdate the help code.
Comment #15
plachMissing capital still there.
Comment #16
vasikei hope you meant the first letter from comment.
Comment #17
plachYep, thanks. Still waiting for @timplunkett's feedback.
Comment #18
dawehner+1
I would skip that comment as it doesn't seem to add valuable information
I guess the entity type label should better be taken directly from the entity type.
Comment #19
dawehnerComment #20
vasike@dawehner : imho the solution below should be just a temporary solution.
and the real solution should be a generic Views approach for Entities, where Views should know and use all the entities definitions for building the Views data, except too specific entities types data - no more hook_views_data() if possible, or in this case hook_views_data_alter() implementation.
p.s. : update the comment
Comment #21
dawehnerRight (see #1740492: Implement a default entity views data handler), but the API freeze was like a while ago. Back to needs work based on my previous comment.
Comment #22
vasikei see and i'm sure that entity views data controller it will be implemented eventually.
here is a new patch that uses entity info data for entity type label.
Comment #23
dawehnerThank you very much! It seems to make sense to add a test to ensure that this code actually works.
Comment #24
plachLooks good to me too but we are still missing tests.
Comment #37
quietone CreditAttribution: quietone at PreviousNext commentedThis was fixed in #2322949: Implement generic entity link view field handlers