"Links" field not displaying on custom view modes

Hmm, it is kind of confusing. The thing is that the links field calls out to methods/modules and asks if there are any links. Problem is that most links in core right now are only displayed on full or teaser view mode because it makes sense in that context only.

e.g. a 'Read more' link makes sense on 'teaser', not on 'full', but it doesn't know if it's relevant for other view modes. See #1837100: Provide a generic Read more field for that.

Maybe the formatter of the links should have the ability to collect all potential links, present a form and then you can configure which ones to show.

Belongs more to the entity system than the render system.

The entity system doesn't know about links, that's node/comment specific :)

Yeah, links are a mess and mostly hardcoded. The only reason we made it an extra field is to be able to hide them when you don't want them.

Not really sure what to do, maybe the display component issue would provide an approach to explicitly define link link components and control their visibility without making each of them a separate extra field?

Yeah, belongs to the node system indeed.

The same problem occurs when one tries to display the tags field of the default article content type in a custom view mode.

The only reason we made it an extra field is to be able to hide them when you don't want them.

So instead of show links only for the the teaser view mode we could show link for every view mode (excluding the full and the default view mode).. isn't it? Not sure if for comment links this has sense but for node read more link it does fore sure

I think this aspect is the good aspect.

The latest patch does not pass tests, so it certainly cannot be committed.

Old patch does not apply, so re-rolling based on latest code base 8.4.x.

Forgot to upload file.

Works as expected, thanks !

This can't be committed without tests, it might also need to be configurable, because not everyone wants those links and now with the update, they might suddenly show up, likely breaking designs.

New patch with test.

I can confirm that patch #21 works with Drupal core 8.6.4

#21 works with 8.7.x

As per #17 I think we need to consider BC here. If we suddenly add links to people's custom view modes there is a good chance we'll break there designs / have unintended impacts.

I just read #823380 which contains a lot of discussion on whether it's a bug or not. Fact is that the title in this issue describes the real bug: it's not possible to show the links field on view modes other than teaser.

@alexpott, I agree with @Maffoo in #20. I hope we can make this happen for 8.7.

I can also confirm that patch #21 works with Drupal core 8.6.4

Patch #21 works with Drupal core 8.6.13.

Not sure how this change could be BC issue because "Links" field can be removed from output by simple config change.

So, IMHO, RTBC.

Patch #21 works as expected with Drupal 8.6.1, thanks.

The regression concern relates to step #4 in the original issue summary: Configure the new custom view mode to display the "Links" field.

The problem is: you don't have to configure the new custom view mode to display the Links field. The configuration is "enabled" by default. You have to explicitly "disable" the Links field from Manage Display, and many users may not have disabled it because it doesn't display regardless (except on the Teaser).

If you apply the patch, but have not explicitly disabled the Links field (in all of your custom view modes for all of your entities), then the Links field will display, which could be very disruptive for existing sites.

#17 suggested a config option, but what’s the best way to approach that? Sitewide, per node type, per view mode? There would need to be something at the View Mode level that tells users that the Links field is, by design, only enabled for the Teaser display (no matter what the config says), and that if you want it to display on custom view modes, you need to enable this other new configuration. And then you would need a Warning so users know that the Links field is going to display unless they’ve disabled it.

IMO, the issue is more general (and maybe there's already a ticket about this). There’s a configuration presented to the user, but it’s not really configurable. There’s a Links field that’s “enabled” by default, but it’s only configurable for the Teaser display. The purpose of this functionality is to prevent users from adding a Read more link on the full content because it wouldn’t be logical to add a link back to itself. It’s a good safety measure, but it creates a confusing UX.

1. Will Drupal 9 release notes be enough? There are many view modes, e.g. "Search index" in which we can break design.

2. The big problem is that the configuration is "enabled" by default. See #33. We also cannot change config globally and hide Links in hook post update. Many projects uses the previous patch...

See also Drupal 8 backwards compatibility and internal API policy (backend).

Does this only affect the read more link, what about the counter from the statistics module, or the comment module links?

This kind of links used in comment entity as well, would be great to unify them in follow-up

Even if we hide all links that are not displayed by default it can also have a negative impact. Many people use the patch (30 followers). If we hide the read more links it will be troublesome for them to re-enable the links again... For example, if they were disabled in one view mode but disabled in another.

Patch #37 is working to display the "Read more" link for me, Drupal 8.8.7.

After using this patch for a while, I've noticed that theming the links per view mode doesn't follow the conventions for other fields.

It would be immensely helpful if the links field used standard theming conventions, such as template suggestions related to the view mode.

Patch #37 is working fine, Drupal 8.8.6.

Patch at #37 applies to 9.1.x and works as expected. Would be RTBC but this needs to be against 9.3.x dev now...

hi,
patch #37 not applicable on drupal 9.3.x-dev.
failed to apply.

patch #37 re-roled.
please review.
Thankyou.

Fixed the #49 test case issue.

Not able to reproduce this issue.

it works! pls move to core soon!

Thanks to everyone for the work here and the confidence that this is working. However, there are more steps needed before this is RTBC, see core gates.

First, this needs an issue summary update, in fact, it needs an issue summary! Add include before and after screen shots in that.

I don't see any evidence of a review of the fix or the new test.

Hi all,
I have not used Drupal for years and have recently installed Drupal 9.4.3. I am seeing this issue. Even though this issue specifies 9.5.x-dev, does this also affect previous versions? Even the "stable" release?

Kindly review patch for version 9.5x,,

I will review the patch.

There was no reason for the 9.5 reroll in #61, the testbot indicates that patch #51 still applies fine to 9.5. #61 is the same patch aside from an additional few bytes of whitespace that fail PHP coding standards. Preemptively removing credit for that.

It also shouldn't have been set to "needs review". It was set to "needs work" in #56 because work was requested, and that work hasn't. been done yet.

Fixed CCF Error
Upload patch against 10.1x

Moved patch to MR.

Believe the issue summary still needs work. "Apply patch" is not a solution, what is the actual proposed solution to address the bug at hand?

The solution as per code to display a read more link in all view modes excluding the full and default view rather than teaser.

Updated summary.

So my concern is if this is going to make a read more link appear for a bunch of view modes now.

@smustgrave I guess so.
We can add hook_update and hide it for all view modes but teaser by default.
Ideas? 🤔

Think that would be best. Maybe even on teaser check if the links is currently hidden, if so leave it alone.

Just thinking a bunch of view modes like cards start having links appear.

We have a hook_node_links_alter that is called via NodeViewBuilder::renderLinks. Modules could use this to add the Read more or any other link to any view mode they like.

This avoids core having to do any work or upgrade path.

What if non teaser view modes were showing links for other purposes? Now they'd need to alter out the read more link.

I think this should probably just be closed as works as designed.

Wanted to give one more bump for any response to #80

Wanted to give 1 more change since this had a lot of early conversation.

This has floated to the top of the Bug Smash Initiatives target - it's current the least recently modified - PMNMI issue.

Reading over the above it looks like a solution was developed and worked on - but no agreement could be reached as to how it could be deployed as doing so would result in breaking changes, and an upgrade path to handle the various possibilities was floated as not being possible.

Without any further feedback and two rounds of bumping without any further feedback I think we follow suggestion in 80 and close as works as designed.

If you have suggestions as to how we could manage the breaking nature of this change and why it shouldn't be handled in a contrib module as suggested in 80 please reopen and include this.