Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.Problem/Motivation
There are some cases where a field has it's value computed from another place and should not appear on forms.
A good example of this is a geo_field field which is configured with geocoder to geocode an address field and store it in the geo field. In this case, you don't want the geo_field to appear on forms and be editable.
However, all the current ways to prevent the field being exposed on a form seem either confusing for a site builder or somewhat fragile.
Proposed resolution
Current solutions appear to be:
- Use a widget with no exposed form: This prevents overriding and is clear to the site builder that they are not expecting any visible widget on a form, but is very fragile, as simply selecting an alternative widget will result in it being exposed.
- Use
hook_entity_form_display_alter()to force the field to always be hidden: Although less fragile, this leaves the UI confusing for the site builder, as they are attempting to expose the field but it never appears on a form. - Use
hook_entity_field_access()to deny access to the field in edit mode: This is again less fragile, but has the same drawback ashook_entity_form_display_alter().
The latter two could potentially be worked round with a form alter for the entity display forms, but that feels very messy and potentially error prone...
I would propose a better solution would be one of:
- Make
\Drupal\field\Entity\FieldConfig::isDisplayConfigurablerespond based on the configuration of the field rather than hardcoded toTRUE. - Add a hook into either
\Drupal\field\Entity\FieldConfig::isDisplayConfigurableor\Drupal\field_ui\Form\EntityDisplayFormBase::getFieldDefinitionsto allow other modules to influence whether fields are possible to show on the form/view builders.
Remaining tasks
- Decide what solution, if any, we want to do.
- Implement it...
User interface changes
- Fields which shouldn't be configurable in display modes would no longer show and therefore would also not show on the forms themselves.
API changes
- If solution 2: A new hook to allow preventing fields from showing in entity displays.
Data model changes
- If solution 1: Adding to the field schema to store whether a field can be configured in a given context.
Comments
Comment #2
andrewbelcher commentedJust to say - very happy to do the work of creating the patch once a decision is made on how (and if) to solve this.
Comment #3
steamx commentedI am not entirely sure what you want.
First and foremost you can prevent base fields from being configurable in baseFieldDefinitions()
field['somefield'] =BaseFieldDefinition::create('something')->setDisplayConfigurable('view', FALSE);Just as a fancy example.
Furthermore you could override this behavior e.g. if you use a contrib module which does allow it by default via hook_entity_base_field_info_alter() or hook_entity_bundle_field_info_alter() (although troublesome atm - see issues)
Edit: Oh, and you could always override it in the configuration entity manually
Comment #4
steamx commentedComment #5
andrewbelcher commentedSo base fields are fine, it's regular fields that you can't do this with. With the geofield example, that is a field added through the field UI, not a base field.
Comment #19
smustgrave commentedThank you for sharing your idea for improving Drupal.
We are working to decide if this proposal meets the Criteria for evaluating proposed changes. There hasn't been any discussion here for over 8 years which suggests that this has either been implemented or there is no community support. Your thoughts on this will allow a decision to be made.
Since we need more information to move forward with this issue, the status is now Postponed (maintainer needs more info). If we don't receive additional information to help with the issue, it may be closed after three months.
Thanks!
Comment #20
smustgrave commentedSince there's been no follow up and as a feature request going to close out. Can always be re-opened.
Thanks.