Allow hook_field_extra_fields() label to be displayed Above/Inline/Hidden, the same way fields and groups are

+1 for this feature. It would be useful for EVA: Entity Views Attachment to implement.

+1 for this feature; additionally, it would be great if one could select different formatters for extra fields as well.

I'm also looking for this.

We have to look into \Drupal\field_ui\DisplayOverview::buildExtraFieldRow

I've replaced:

    // Insert an empty placeholder for the label column.
    $label = array(
      'empty_cell' => array(
        '#markup' => ' '
      )
    );

with

    $display_options = $entity_display->getComponent($field_id);

    // Insert the label column.
    $label = array(
      'label' => array(
        '#type' => 'select',
        '#title' => $this->t('Label display for @title', array('@title' => $extra_field['label'])),
        '#title_display' => 'invisible',
        '#options' => $this->getFieldLabelOptions(),
        '#default_value' => $display_options ? $display_options['label'] : 'above',
      ),
    );

But I'm not able to 'save' the configuration of it.

I've looked in the Overview Form here: \Drupal\field_ui\DisplayOverviewBase::submitForm

Modifying the loop for extra fields like this:

    // Collect data for 'extra' fields.
    foreach ($form['#extra'] as $name) {
      if ($form_values['fields'][$name]['type'] == 'hidden') {
        $display->removeComponent($name);
      }
      else {
        $display->setComponent($name, array(
          'weight' => $form_values['fields'][$name]['weight'],
          'label' => $form_values['fields'][$name]['label'],
        ));
      }
    }

Allows me to save the 'label' property correctly.

We could also save the whole array, like that:

    // Collect data for 'extra' fields.
    foreach ($form['#extra'] as $name) {
      if ($form_values['fields'][$name]['type'] == 'hidden') {
        $display->removeComponent($name);
      }
      else {
        $display->setComponent($name, $form_values['fields'][$name]);
      }
    }

What do you think ?

Also, don't forget to change: \Drupal\entity\EntityDisplayBase::getComponent:

  public function getComponent($name) {
    // We always store 'extra fields', whether they are visible or hidden.
    $extra_fields = field_info_extra_fields($this->targetEntityType, $this->bundle, $this->displayContext);
    if (isset($extra_fields[$name])) {
      // If we have explicit settings, return an array or NULL depending on
      // visibility.
      if (isset($this->content[$name])) {
        if ($this->content[$name]['visible']) {
          return $this->content[$name];
        }
        else {
          return NULL;
        }
      }

      // If no explicit settings for the extra field, look at the default
      // visibility in its definition.
      $definition = $extra_fields[$name];
      if (!isset($definition['visible']) || $definition['visible'] == TRUE) {
        return $definition;
      }
      else {
        return NULL;
      }
    }

    if (isset($this->content[$name])) {
      return $this->content[$name];
    }
  }

Instead of returning the array containing the weight, I return the whole element/definition.

Now, to render that extra field correctly, it's here \Drupal\node\NodeRenderController::buildContent:

      // Add Language field text element to node render array.
      if ($display->getComponent('language')) {
        $entity->content['language'] = array(
          '#type' => 'item',
          '#title' => t('Language'),
          '#markup' => language_name($langcode),
          '#prefix' => '<div id="field-language-display">',
          '#suffix' => '</div>'
        );
      }

$display->getComponent('language') returns an array with the 'label' and the 'weight' as key and their respective values, so it's cool, we can retrieve the values we saved in the manage form display screen.

Now, we need to find a way to use the field template, I'm still digging...

BTW, what happend when I render multiple node on a page, does the language field has always the same ID ?

Attaching a patch, it's easier to see the changes.

I guess the best place is probably going to be EntityFormController::processForm()

- edit - at least for the forms side - should check where we assign/change the weights on the display side

- edit - I just realized that on the forms side there's no label, so that doesn't matter at all, scrap my comment ...

If you're interested in easily making extra fields look like real fields, check out Pseudo field contrib module.

I tried to investigate how the title of extra_field is displayed on a view mode, using the Bartik theme on D8-rc2. I did not succeed :-(
I compared my own field from Field UI with the core 'Language' property (which is the only one exposed for view_modes).

In the display settings fo the Node type, you can set the label placing.

When viewing a node, Core/Field/FormatterBase.php::view() collects all info for each field. Both field and property are the same:

view Drupal\Core\Field\Plugin\Field
'#theme' => string(5) "field"
'#title' => object Drupal\Core\StringTranslation\TranslatableMarkup(5) 
'#label_display' => string(6) "inline"  // <== This is the settings we are looking for.
'#field_name' => string(8) "langcode" // <== vs. MY_FIELD_NAME
'#field_type' => string(8) "language" // <== vs. 'list_default'

So the hook_field_extra_fields (title display and weight) are recollected correctly.
(Apparently, '#title_display' is for forms, '#label_display' is for view_modes.)

Core/Entity/EntityViewBuilder::buildMultiple() collects all info from hooks.
There, the '#label_display' has vanished for Language! (Why, where?) I added a hardcoded
$build_list[$key]['langcode']['#label_display'] = "inline";

I investigated the differences between the both formatters:
- Drupal\options\Plugin\Field\FieldFormatter\OptionsDefaultFormatter
- Drupal\Core\Field\Plugin\Field\FieldFormatter\LanguageFormatter
There are no diffences in handling the title/label.

This is all passed through Drupal\Core\Render\Renderer->doRender(), also with no apparent differences.
In modules/system/templates/field.html.twig, a variable 'label_display' is passed, but not used.

So, two questions remain:
- Why/where is the settings '#label_display' removed?
- When restored, why/where is it not used? Somewhere, there is a difference between fields and basefields/properties.

@Pol, the first part of your search is already fulfilled: Core stores the title settings corectly in the Entity Configuration.

BTW. I'm interested in this issue for diaplsy properties of custom entities, not the language property per se.

Hi, I rebased the patch to 8.3.x just to see the effect, It looks like it allows to set the label behavior, but obviously this is not enough or render the label.

@Pol did you look into the rendering part?

I am going to look at the "Pseudo field" plugin next, but I was also wondering if in the long run having pseudo fields as a new FieldType and adding them using the Plugin API would make sense. Not an experiment I can do myself I am afraid.

Hi All, I like this feature. I have initiated the testing with Drupal 8.9. Also this will fix the other issue - Implement visibility options for "Real name" field label.

Thanks

I don't know if we really need something more than the following:

/**
 * Implements hook_ENTITY_TYPE_view().
 */
function MYMODULE_node_view(array &$build, EntityInterface $entity, EntityViewDisplayInterface $display, $view_mode) {
  if ($display->getComponent('MYFIELD')) {
    $node->content['MYFIELD'] = array(
      '#theme' => 'field',
      '#label_display' => 'inline',
      '#view_mode' => '_custom',
      '#title' => t('MY LABEL'),
      '#field_type' => 'text',
      '#field_name' => 'MYFIELD',
      '#bundle' => $entity->bundle(),
      '#entity_type' => $entity->getEntityTypeId(),
      '#object' => $entity,
      '#is_multiple' => FALSE,
      '#items' => array(array()),
      0 => array(
        '#markup' => 'YOUR CONTENT HERE',
      ),
    );
  }
}

I also have it as a snippet for D7 and for D8+ in https://gitlab.com/-/snippets/1749165.

This issue can be solved by using extra_field_plus module. See the example module within it.