Now that we have EntityDisplay objects holding display options for all the components of an entity view, we can start plugging them with the existing core layouts.

This will probably involve some refactoring to see how we can best reuse the logic in the existing Drupal\layout\Plugin\Core\Entity\Display objects.

More importantly, though, the first issue we need to address is the overall impact on the theming layer.
Namely, if a node view is primarily a collection of contents within regions, then node.tpl.php basically becomes something like :

<?php foreach ($regions as $name => $content): ?>
  <div id="<?php print $name; ?>">
    <?php print render $content; ?>
  </div>
<?php endforeach; ?>

Meaning : something that themers can absolutely not work and mess with...

Just looking at the current bartik's node.tpl.php shows that we currently very much rely on custom markup (for example around node title) or custom placement (comments, links...) in there.

So the question is :
Do entity layouts mean that we must forget editing [entity_type].tpl.php files, and that all the stuff we currently do there has to be done in the UI ? (which sounds pretty bad, if not a no-go...)

- Curious to hear about people working with D7's Display Suite layouts and / or Panelizer can say about this
- Dunno if Twig can bring something interesting to the table on this aspect ?

Comments

yched’s picture

Issue summary: View changes

fix code

yched’s picture

Issue summary: View changes

fix code

yched’s picture

Issue summary: View changes

mention node links

swentel’s picture

Do entity layouts mean that we must forget editing [entity_type].tpl.php files

I don't think we should remove that ability, but it would make sense to me to at least to have the ability to control the placement of all (useful - but where to we draw the line here) properties on an object.

Some thoughts:

  • In Display Suite (and I think in the Panels world too), we don't foreach in the template file itself. The template file is immediately the 'right' one. See this example.
  • The 'new' Field API should/could expose those properties: how do we add them to the build array then ? Use the technique like extra fields to add a property on the build array of the entity ? DS exposes it's own 'Field' types which are basically markup fields but with the ability to have formatters, which are more powerful than extra fields.
  • Markup: for instance the title: do we want to introduce 'non-field' formatters. A crazy plan could be to look at the formatters of Views and come up with a plan to make those re-usable for everyone. This is maybe linked to #1875974: Abstract 'component type' specific code out of EntityDisplay ? Moving the formatting into a popup would make it consistent then too with both interfaces.
  • Trick question: Do we want to control the links render array, or every link inside it ? :)
andypost’s picture

Suppose this way should lead to something like entity--view-mode.twig wrapper to allow themers to do their magic/staff on render

andypost’s picture

For core I think a render() #container__entity element is enough

andypost’s picture

Is this still in D8 roadmap? or D9...

andypost’s picture

Issue summary: View changes

formulation

Version: 8.0.x-dev » 8.1.x-dev

Drupal 8.0.6 was released on April 6 and is the final bugfix release for the Drupal 8.0.x series. Drupal 8.0.x will not receive any further development aside from security fixes. Drupal 8.1.0-rc1 is now available and sites should prepare to update to 8.1.0.

Bug reports should be targeted against the 8.1.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.2.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.1.x-dev » 8.2.x-dev

Drupal 8.1.9 was released on September 7 and is the final bugfix release for the Drupal 8.1.x series. Drupal 8.1.x will not receive any further development aside from security fixes. Drupal 8.2.0-rc1 is now available and sites should prepare to upgrade to 8.2.0.

Bug reports should be targeted against the 8.2.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.3.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

tim.plunkett’s picture