The "Node links" (ie. "Read more", "Add new comment", etc) are normally provided via NodeViewBuilder. However, if we override the node view with Page Manager or Panelizer, we'll need a block to show them!

This issue is to create such a block.

We should look at the CTools "content type" we had in D7 (ctools/plugins/content_types/node_context/node_links.inc) and make sure we support all the same configuration and features (assuming they make sense in D8).

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

dsnopek created an issue. See original summary.

dsnopek’s picture

Issue summary: View changes
dsnopek’s picture

Issue summary: View changes
phenaproxima’s picture

FileSize
3.07 KB

First attempt.

phenaproxima’s picture

Status: Active » Needs review
dsnopek’s picture

Status: Needs review » Needs work

Thanks!

  1. +++ b/src/Plugin/Block/NodeLinks.php
    @@ -0,0 +1,105 @@
    + *   category = @Translation("Node"),
    

    Category should probably be "Content" since that's what we're using for the other blocks that need a node context.

  2. +++ b/src/Plugin/Block/NodeLinks.php
    @@ -0,0 +1,105 @@
    + *     "node" = @ContextDefinition("entity:node", label = @Translation("Node"), required = TRUE)
    

    Here too - we use "Content" in the label of other context that take nodes.

  3. +++ b/src/Plugin/Block/NodeLinks.php
    @@ -0,0 +1,105 @@
    +    $options = $this->viewModeStorage->loadByProperties([
    +        'targetEntityType' => 'node',
    +      ]);
    +    foreach ($options as $option) {
    +      $form['view_mode']['#options'][$option->id()] = $option->label();
    +    }
    

    Hm. So, I don't know which way is better, but I would have used \Drupal::service('entity_type.bundle.info')->getBundleInfo('node') (except properly injected :-)) to get the list of view modes. Directly accessing the config entities seems like we're skipping an abstraction - but maybe it's fine?

    We should get some feedback from someone who knows the Entity Field API better...

  4. +++ b/src/Plugin/Block/NodeLinks.php
    @@ -0,0 +1,105 @@
    +    return NodeViewBuilder::renderLinks($node->id(), $this->configuration['view_mode'], $node->langcode->value, FALSE);
    

    Whoa! Super cool that we don't have to duplicate the code here. :-)

dsnopek’s picture

Actually, thinking about #6.3 some more - I think it's possible for a view mode to exist, but have no config entity for it! This is when the user chooses not to enable custom display settings for a view mode, and the settings for "Default" are re-used. We don't want to have to change block settings depending on if view mode has custom settings or not - we should just set the view mode and the correct display settings get used.

So, I think we should definitely use the 'entity_type.bundle.info' service to get the list of view modes, rather than the config entity.

Sonal.Sangale’s picture

Assigned: Unassigned » Sonal.Sangale
Sonal.Sangale’s picture

Status: Needs work » Active
FileSize
3.07 KB
659 bytes

Added modifications as per comment #6.

Item 1 - Done

Item 2 - Done

Item 3 - I have not changed anything since not much aware of Entity Field API.

Sonal.Sangale’s picture

Assigned: Sonal.Sangale » Unassigned
Status: Active » Needs review
dsnopek’s picture

Thanks! I still think we should switch to the bundle info per #6.3, but I'd like to do some testing to see if the result is different. I suspect that getting the config entities will be missing the view modes that aren't customized, and we want to be able to select all views, not just the customized ones.

thalles’s picture

FileSize
3.09 KB
658 bytes

Follow a new patch, fixing Drupal standards.