There are potentially many entity types that do not use $variables['content']
as their renderable element. The core user module is one, and that is special-cased in field_group module's entity handling as $variables['user_profile']
.
Unfortunately these two content variable keys are hard-coded. It would be useful to provide a hook to allow contrib modules to add their (or others) content key to an array, and use that when manipulating the group structure (or any other task as needed). That would allow entity modules to easily implement field group support, or allow any contrib module to add fieldgroup support for any entity module.
Proposed patch to come.
Comment | File | Size | Author |
---|---|---|---|
#2 | field_group-entity-content-variable-support-1.patch | 4.65 KB | John Pitcairn |
Comments
Comment #2
John Pitcairn CreditAttribution: John Pitcairn commentedHere is a first stab at it. This patch adds a new function:
And uses that to get the default content variable keys - 'content' or 'user_profile' - in
field_group_build_entity_groups()
andfield_group_fields_nest()
. The latter adds a third optional parameter,$context
, to allow passing in the display context. Wherever$context
is mentioned in existing code comments, those are updated to indicate $context may be the entity type, and it is this that is used to provide a corresponding content element key infield_group_get_content_element_key()
.Finally,
hook_field_group_content_element_keys_alter()
provides a way for other modules to add entity-type to content-element-key mappings. This means that entity modules can easily add fieldgroup support themselves, or crucially, any other module or theme may add fieldgroup support on behalf of any entity module.For example, to add fieldgroup support for commerce product variation entities:
Comment #3
John Pitcairn CreditAttribution: John Pitcairn commentedComment #4
John Pitcairn CreditAttribution: John Pitcairn commentedComment #5
John Pitcairn CreditAttribution: John Pitcairn commentedWe could modify this to allow modules to specify the
$element
variable as well.Comment #6
John Pitcairn CreditAttribution: John Pitcairn commentedI also think the
$variables['user_profile']
key is no longer correct for user module in Drupal 8. That would be a followup issue.Comment #7
John Pitcairn CreditAttribution: John Pitcairn commentedComment #8
nils.destoop CreditAttribution: nils.destoop as a volunteer and at Wunder commentedGood addon. I committed it to dev.
Comment #10
nils.destoop CreditAttribution: nils.destoop as a volunteer and at Wunder commentedThe user_profile is idd not correct anymore. I removed it.
Comment #12
kmajzlik CreditAttribution: kmajzlik at Ciklum Western Europe for BurdaForward commentedThis should be re-opened and ported to 8.x-3.x because it does not work with Commerce (products, variations etc.)
Comment #13
John Pitcairn CreditAttribution: John Pitcairn commented@karlos007: message the maintainer directly and ask him to reopen this and assign to 8.x-3.x. It's unlikely @zuuperman pays attention to closed/fixed issues.
Comment #14
John Pitcairn CreditAttribution: John Pitcairn commented@karlos007: This patch is already in 8.x-3.x. You need to implement the appropriate hook to specify the correct Commerce element keys, as per the example in #2.
Ideally, Commerce itself would implement this hook. The discussion is #2906502: Compatibility with Field group module
Comment #15
PFEnriquez CreditAttribution: PFEnriquez commentedHi,
I tried to implement the hook this way (changing obviously "hook" with my module
but the field groups are still not rendered on Commerce products. The error seems to be on field_group side (commerce feedbacks) and I wonder it should be solved as it is a very important features for contrib modules in general, including Commerce.
Comment #16
PFEnriquez CreditAttribution: PFEnriquez commented