Contrib modules can't alter the building of entity form displays

Hmm, interesting. EntityViewDisplay has an calling entity_display_build (looking at it, I even wonder if that hook actually works since $key seems totally wrong there, but that's for another issue) - maybe it could be something like entity_form_display_build then ?

Another option maybe: what if move this alter call into EntityFormBuilder::getForm, in analogy with EntityViewBuilder and name it something like 'entity_form'

e.g.

  $this->moduleHandler()->alter(array('entity_form'), $build_list[$key], $entity, $display);

Definitely needs tests and an entry in entity.api.php

Ha, interesting .. form in a form, always tricky stuff :)

Been looking at how Entity Inline Form deals with this and they are calling an alter themselves on the embedded form (see EntityInlineForm::entityForm()). Maybe in the end, that's the that's a better idea for paragraphs module as well ?

(I'm even wondering whether they shouldn't start depending on IEF, less code to maintain as well, but that's separate issue for them)

Hi,
it is safe to use the patch from #2 at this moment as temporary solution?
Or it is better to wait for some real solution?

Thanks a lot for your work so far.

Would this be the reason why it's currently impossible to use Field Groups to modify the form layout of Contact Forms?

@Petr Illek no, don't use this patch for now. I don't know how @zuuperman tackled it in the end, but we talked in IRC and we were close to setting this to won't fix.

hi,
i am also tested with the field group and paragraph demo modules. image + text are grouped.

thank you

hi,
i am also tested with the field group and the paragraph modules.image and paragraph are grouped and working fine,if it have any further issue kindly post.according to patch it is working fine.

@revathi seems like you are posting about another issue? This issue is about getting field groups to work when editing content and your screenshot is showing a viewed node. I'm setting this back to previous status since I don't believe it is actually fixed.

another at #2691723: Add a hook to alter entity form displays

Closed #2691723: Add a hook to alter entity form displays - moving to needs work for tests.

Copying Comment #4 from dawenher here from the other issue that explains what tests are required:

For hook_entity_display_build_alter() we have core/modules/field/tests/src/Kernel/DisplayApiTest.php:156 currently, so maybe opening up a FormDisplayTest in there would be the right way. ON top of that then add something like \field_test_entity_display_build_alter for your new hook maybe.

Note: We also have to add documentation to entity.api.php

This has been fixed elsewhere it seems. Feel free to re-open if I'm wrong.

@artis

Anything you can point or link to that makes it seem like this is fixed? Thanks.

This doesn't seem to be fixed at all_ there is still no hook allowing to alter the form display building process AFAICT.

Another one rides the bus! This bites in that related issue.

So let's sort it out:
* we have a patch in that dup issue #2691723-2: Add a hook to alter entity form displays that adds a simple hook but needs work for tests
* EDIT: also that patch needs doc (.api.php) for the introduced hook_entity_form_build

Note: I'm not sure if the hook is enough as sometimes modules need to know if they're in the top level entity form or an embedded entity form. But i'd leave this for a followup if needed.

Rerolled and added the api docs, tests still missing. Worth mentioning that I think most of the use cases related to this could maybe solved by hook_field_access or a good old hook_form_alter.

This issue came up in #bugsmash triage.

Myself, @lendude and @larowlan discussed it and agreed that it is not a bug and would be better classified as a feature request. The discussion above indicates that paragraphs and field_group have already worked around this, and there has been little recent interest in fixing this issue. Setting to "maintainer needs more info", if there is no further movement for this feature request in the future then it is likely to be closed as won't fix.

Per #34, since it's been a year without movement going to go ahead and close.

If anyone disagrees please reopen expressing why though.

Thanks!

The code still contains this comment in two places:

// @todo Remove as part of https://www.drupal.org/node/2640056

If this won't be fixed, perhaps this comment should be removed.