Problem/Motivation

Disabling field layout on an entity display level would be useful since if field layouts are enabled for a display mode, it alters the variables passed to the template. It is a quite common use case to access the variables passed to a template in a template override to achieve entity type / display specific functionality. This is not a problem if a theme can trust that field layout is always enabled. However, this becomes a huge problem if the theme cannot do so (especially given that themes cannot depend on a module).

Proposed resolution

Remove field layout processing from the one column layout.

Remaining tasks

-

User interface changes

-

API changes

-

Data model changes

-

Comments

lauriii created an issue. See original summary.

lauriii’s picture

lauriii
he/him
Primary language Finnish
Location Finland
commented
Related issues: +#2846393: [PP-1] Investigate alternative approaches to moving fields in FieldLayoutBuilder::buildView()
tim.plunkett’s picture

tim.plunkett
he/him
Primary language English
Location Philadelphia
commented

#2844302: Move Field Layout data model and API directly into \Drupal\Core\Entity\EntityDisplayBase will address this by making Field Layout always on, and completely built-in to the entity display system.
Additionally, EntityDisplayInterface::getFieldFromBuild() has been added to help retrieve your fields.
Before:

function mymodule_entity_view_alter(array &$build, EntityInterface $entity, EntityViewDisplayInterface $display) {
  $build['my_field_name']['#title'] = t('New title');
}

After:

function mymodule_entity_view_alter(array &$build, EntityInterface $entity, EntityViewDisplayInterface $display) {
  $my_field = &$display->getFieldFromBuild('my_field_name', $build);
  $my_field['#title'] = t('New title');
}

The issue also adds a "Default" layout that has no markup at all.

tim.plunkett’s picture

tim.plunkett
he/him
Primary language English
Location Philadelphia
commented

And yes, a solution to the issue linked in #2 would completely fix the problem.

Version: 8.4.x-dev » 8.5.x-dev

Drupal 8.4.0-alpha1 will be released the week of July 31, 2017, which means new developments and disruptive changes should now be targeted against the 8.5.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.5.x-dev » 8.6.x-dev

Drupal 8.5.0-alpha1 will be released the week of January 17, 2018, which means new developments and disruptive changes should now be targeted against the 8.6.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.6.x-dev » 8.7.x-dev

Drupal 8.6.0-alpha1 will be released the week of July 16, 2018, which means new developments and disruptive changes should now be targeted against the 8.7.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.7.x-dev » 8.8.x-dev

Drupal 8.7.0-alpha1 will be released the week of March 11, 2019, which means new developments and disruptive changes should now be targeted against the 8.8.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.8.x-dev » 8.9.x-dev

Drupal 8.8.0-alpha1 will be released the week of October 14th, 2019, which means new developments and disruptive changes should now be targeted against the 8.9.x-dev branch. (Any changes to 8.9.x will also be committed to 9.0.x in preparation for Drupal 9’s release, but some changes like significant feature additions will be deferred to 9.1.x.). For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.9.x-dev » 9.1.x-dev

Drupal 8.9.0-beta1 was released on March 20, 2020. 8.9.x is the final, long-term support (LTS) minor release of Drupal 8, which means new developments and disruptive changes should now be targeted against the 9.1.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 9.1.x-dev » 9.2.x-dev

Drupal 9.1.0-alpha1 will be released the week of October 19, 2020, which means new developments and disruptive changes should now be targeted for the 9.2.x-dev branch. For more information see the Drupal 9 minor version schedule and the Allowed changes during the Drupal 9 release cycle.

Version: 9.2.x-dev » 9.3.x-dev

Drupal 9.2.0-alpha1 will be released the week of May 3, 2021, which means new developments and disruptive changes should now be targeted for the 9.3.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.3.x-dev » 9.4.x-dev

Drupal 9.3.0-rc1 was released on November 26, 2021, which means new developments and disruptive changes should now be targeted for the 9.4.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.4.x-dev » 9.5.x-dev

Drupal 9.4.0-alpha1 was released on May 6, 2022, which means new developments and disruptive changes should now be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

quietone’s picture

quietone commented
Status: Active » Closed (duplicate)
Issue tags: +Bug Smash Initiative

According to #4 this issue will be fixed by the related issue from #2, #2846393: [PP-1] Investigate alternative approaches to moving fields in FieldLayoutBuilder::buildView(). That would make this a duplicate.

Therefor closing as a duplicate. If that is wrong, I am sure someone will reopen this.

Thanks