Read more Links field not rendered in Olivero

I'd still be curious to know why these links were omitted by design. Seems like a Drupal core theme should support basic Drupal site building functionality of a teaser with these links.

I agree @Chris Matthews, the "Read more" links are an integral part of Drupal site building.

🐛 The site slogan doesn't show with Olivero Needs work is another case, where an integral part of Drupal was left out. See also 📌 Olivero: Center align content (instead of left align) Needs work .

Moving this issue from the Olivero contrib project to Drupal core > Olivero theme component.

I have added before and after patch screenshot (without read more and with read more button)

Hi @Gauravvvv,
Verified your patch #12 on Drupal 9 and 10 it's working fine. The read more link is rendered now.
Added screenshots for reference, moving to RTBC.

The last submitted patch, 12: 3154517-12.patch, failed testing. View results →

Reroll the patch file.

The Needs Review Queue Bot → tested this issue.

While you are making the above changes, we recommend that you convert this patch to a merge request → . Merge requests are preferred over patches. Be sure to hide the old patch files as well. (Converting an issue to a merge request without other contributions to the issue will not receive credit.)

Already created the MR.

Thanks for working on this

Tagging for issue summary as that appears to be incomplete, recommend using the standard issue template

Tagging for tests as feel a simple assertion could be added to an existing test.

This simply works and cannot be intentional design - at best it was just missed in design screenshots.

Lets get this usability issue resolved, please.

I agree, designs often miss to mockup a feature like Language Switcher et Read more links.

But the actual coding must go beyond mockups.

Yes, aside it is not only the Read more link that is missing here. The number of content "views" is also missing without this change. This is something I show to logged in users on my sites and that is really useful if the statistics module is enabled. I'm sure there are more use cases for the "links", but cannot remember it.

It's really a nightmare that this case is lingering 4 years around. It look me hours to understand why the read more is not shown and comments on other pages point to misconfiguration of teaser display mode and other stuff. Really annoying. Commit this minor line change now, please. Over 4 years is 4 years too much!

The issue was originally created in the Olivero issue queue but moved, so it's not clear now that the issue is about a specific theme, so adding Olivero in title.

I've removed these links from sites before because clicking on the title (or a clickable card) is a well understood pattern for getting to content and the links generally add noise for me.

However if a design decision was taken to do this in Olivero I don't think the figma is sufficient to explain that, there should be a 'why' somewhere to go with the pictures. I also would have no idea where to find this figma, or any way to verify that it's the final designs. So if this goes won't fix again I think it needs d.o. documentation before that happens.

Tagging for both product and subsystem maintainer review.

Also this is another example of node display elements being controllable only via twig templates and not in manage display, layout builder, or content type settings. If these were implemented as an extra field and exposed manage fields/layout builder there'd be no special cases template variable at all.

Still needs an issue summary update which should summarise the disagreement before it goes back to committers too.

I've removed these links from sites before because clicking on the title (or a clickable card) is a well understood pattern for getting to content and the links generally add noise for me.

Each website has its requirements and differences. Although “Read more” is phased out on most [Drupal] sites, here the links can be (and are) used for additional functions, like statistics, for those who have that requirement.

figma

Are we relying too much on Figma? Is Figma too limited?

Mockups

Mockups are mockups, they should never represent the source of truth, but rather they represent what was planned. During development, it’s when we implement features correctly, and sometimes update the mockups accordingly.

Links, Language switcher and Site slogan are all examples of components that need more love and probably implementation updates back to mockups.

Let’s make sure we implement features correctly.

Rewrote the issue summary using the issue summary template.

@catch: It need to possible to show the links. If you decide on your own to remove the read more (and other links), go into content rype > manage display > Teaser and Hide the field Links, please.

This can also be done with an install profile if needed, but do not disallow people to enable the links and waste their time trying to enable it and they do not show up - bringing them into support issues and debugging hours, please. There is functionality like language switcher, statistics and read more and maybe more features behind. This is not a design thing.

If Figma (whatever this is) requires this, you can configure it on your individual website. Nobody will stop you from configuring it this way to comply with your Figma rules. But others who need the links can enable them the common way. Please make this flexible as Drupal normally is.

Added a functional test that runs the same tests from the Node module that checks for the Read more link, but uses the Olivero theme instead of Stark.

Hello,
I have reproduced the issue on Drupal 11.
The MR is applied successfully.

Testing steps-
Verify the teaser display mode of the page content type has the Links field enabled to be displayed.
Create a few test pages.
Enable the archive view.
Visit the /archive page, and verify no "Read more" links are visible in the node teasers.

Test Result:
The read more link is rendered now.
Added screenshots for reference.

I would better rename node--teaser.twig into node--article--teaser.twig

We do this for all content types and not only for articles.

Yes, that's what I mean.
In Olivero theme, the article teaser does not have these links in the design. This is noted in comment #5. And therefore:

1. if someone wants these links in teasers of other content types, then you should leave the article teaser alone and put it in a separate template.
2. otherwise, you need to add a design for links for all teasers(include article). Olivero is a presentation theme and design is very important here, in my opinion.

We need to decide what we want to achieve in this task

I think there is a serious misunderstanding on your side. The mockup has something missing. This is not a design question. If you do not like to see the links in article-content types you can disable the read more links in field settings. Please do not name this design.

Also do not forget about language flags/links and/or statistics counters obly a logged in users can see. So you can have an view counter in logged in state and nothing on public view.

Again, this is nothing about design - it is all about configuration. If you like to hide the read more - disable it in field setzings, but allow others to show it if they have a different opinion.

I understand you and you try to understand me. For a person with a designer's hat, these links in the list look like a flaw. If you want to add them to the main Drupal theme. (By which, among other things, businesses choose one or another CMS).

If you want to add just a list with two basic links, at least add a minimal design.

Thank you

There is no need to hardcode a link removal. Your decission - remove the links in settings and your designer head is happy.

Others have the flexibility to use a setting to show the links.

So both heads have a non-hardcoded and flexible solution. Drupals backend provides the full flexibility for both. Hardcoding is a serious feature regression and we may need to discuss why Drupal has flexible „display“ settings. I guess nobody may argue to remove the display settings…?

Let's sum it up.
For me it looks like this.
We add a basic design to these links and do not break the design of the flagship Drupal theme.

Simply configure the display setting! Do not hardcode stuff, please!

@finnsky This is not a design flow but an open omission based on personal preference. Drupal supports statistics, links, slogan, language switcher. Because you do not like one or the other does not mean you have permission to remove those from the design.

Currently, Olivero suffers from that poor judgement.

If Drupal supports a feature, Olivero must support it.

If you really dislike a feature, instead of hiding it from the theme, you need to remove it from the core.

So instead of breaking features (all those features are optional) because you do not like them, do not block their implementation in the flagship theme.

A flagship theme must show how Drupal is versatile, not hide things one man does not like.

In other words, do not break Drupal.

In other words, do not break Drupal.

Good presentation theme design is also part of Drupal. Let's not break it too. And leave the requirement for designer review of this task. And then everyone will be happy. And those who use Olivero for their tasks. And those who just want a beautiful picture from Olivero.

Good presentation theme design is also part of Drupal. Let's not break it too.

Well, this is already broken:

• Statistics can't be shown.
• Links can't be shown.
• Language switcher display is broken
• Site slogan is broken

Drupal is much more than statics mockups.

A good design will create components for all core features Do not put some components under the rug because you only want a beautiful, not functional, picture.

I just created topic in Olivero slack. probably better to continue discussion there

https://drupal.slack.com/archives/CJT807H7T

You are excluding users from discussion if using slack.

probably better to continue

not a requirement :)

In any case, I expressed my point of view. It may be different, but it exists. And I think that this point of view is not only mine. I am finishing my participation here.

You only talked about your designer hat, but you have not commented on - what stops you from changing the display settings to remove the link on your own, but allow others to show it. You have therefore not provided any argument yet...

The MR looks fine.

I did not test it, though. So leaving at Needs review.

I reported this over 4 years ago [we were a super early adopter of Olivero!]. At the time, I figured these missing links may have been an omission, but Mike @mherchel said it wasn't in the design. His answer made complete sense to me then and it still does. I should have closed the issue :-)

To get this into Olivero: absolutely there needs to be a design for these links. What should they look like: plain linked text, or should they be buttons, what colours, contrast, etc. I'm curious what front end designers / developers will make it look like. That's what they do and they are very good at it.

Discussing in Olivero Slack as suggested by @finnsky is a good step forward. It involves people that can help out with this. And I don't think it excludes people. Anyone can view the Slack projects/discussions. I can and I don't think I have special permissions.

So I'm going to switch this to needs work - needs design.

And hopefully that will break the tie here for now.

Restoring tags

The default link design is fine to me personally and looks simply like every other link in Olivero theme. So already designed by the theme. But well if you like to design them differently… hopefully it does not take longer than a week. Waiting for this stuff - years is not acceptable.

If you like not showing the links them, set this up in display mode. I feel really annoyed that the design advocates never comment on the display mode setting and only try to tell us the mockup does not contain the links… a weak argument.

@smutgrave Please do not add back those tags. Olivero must represent the flexibility of Drupal, not a "use Olivero only like this" approach.

A Drupal theme must respect the configuration made available by Drupal and allow user to add modules that will display more information.

Blocking the links from displaying is blocking the usage of the modules that require links to be visible.

Same things with other Drupal components. Olivero must support those as well.

Okay I too am abandoning this issue since we aren’t going to respect the flow of things and just keep trying to skip steps for no reason.

Best of luck

The tags were added in comment #27 by a core maintainer.

Without review by at least the subsystem maintainer, if not the product manager, this issue has little chance that it will be committed.

You are doing this issue a disservice by removing the tags.

Adding back catch issue tags.

Please do not abandon issues. They will have abandonment issues. (ba-dum ching)

Thank you everyone for your opinions, and contributions to this issue. This issue proves how a small change, or oversight, can be very impactful, and shows both the power and flexibility of Drupal.

It appears there was some confusion and disagreements, but everyone is on the same page now. Hopefully, we can get a review from a maintainer/manager.

I personally care a lot about resolving this issue, and hopefully getting it merged. For those reasons, I engage with this issue and contribute. I realize others are passionate also. However, it is important to...

Be patient. Be kind. Work together.

My 50 cents are the following.

Drupal allows to configure links from view display of the entities (add them or remove from the display view). So obviously it was wrong choice to remove links from the render from twig template. We should allow it (and many other, normally). In that case i totally agree with #45 🐛 Read more Links field not rendered in Olivero Needs review .

At the same time Olivero theme - is a flagship of Drupal user theme. Which means design is important. However design is just a step to implement the feature. In the end - i hope issue will be resolved. For now you can use 8840 merge request and apply it on your projects as a patch.

Many web-sites are using Olivero theme as a main theme of the project, or sub-theme with little customizations (colors, fonts). And many people want these links.

To complete the issue - we need design (already tagged)

I'm not sure what to do here or where this is going. The designs at https://www.figma.com/design/x5zBLbvoW1jsvyAOt4Gp9I/Olivero-Theme---Publ... do not have the "Read more". Just because it was there before doesn't mean we still need to do it or that it's proper UX.

From @catch in #27

However if a design decision was taken to do this in Olivero I don't think the figma is sufficient to explain that, there should be a 'why' somewhere to go with the pictures.

Not sure there's any insight other than, "it's not needed".

Also this is another example of node display elements being controllable only via twig templates and not in manage display, layout builder, or content type settings. If these were implemented as an extra field and exposed manage fields/layout builder there'd be no special cases template variable at all.

💯

@mherchel, Removing the Read more links via the render array in the template breaks other functionality provided by Drupal core. The request here is to include a variation of the design with the Read more link rendered. So, we can remove the overridden template, and instead hide the Read more link via configuration on a per site basis as Drupal core intended.

The field configurations for the Links field (Read more links) still exists. Removing the Links field from rendering in the template results in those configuration being useless, and forces the template to be overridden. So, the argument here is that removing the links from rendering in the template was the wrong approach, as it breaks previous functionality provided by Drupal core. Sites that use the Read More links, or the Statistics module, or any other module that integrates with the Links field will not have those links rendered when using the Olivero theme.

So, if the design decision was to remove the Read more links, there should be documentation and potentially a better implementation for the Links field to not render by default, or have the Read more link configurable within the links field, as examples.

"It is not needed", meaning the Read more link is not needed, is not a sufficient explanation for the breaking change for the other functionality provided by the Links field. The ask is to render the links by default, as it was before, until a better implementation has been provided that does not break the functionality provided the core.

This is plainly an issue about the conflict between nice and flat design, mostly emerging from Photoshop/Figma mindset and the flexibility of a full CMS where plenty of overrides exist in settings.

1. The design (photoshop/figma) does not take into account multilingual sites, whereas Drupal is a multilingual site: hence, there are no designs for the language switcher.
2. The design (photoshop/figma) does not take into node display extensions, mostly going in the $links, for example Statistics (more modules put their information there), whereas Drupal is a multilingual site: hence, there are no designs for $links or setting to show/hide $links in the theme.
3. The design (photoshop/figma) does not take into account site Slogan, whereas Drupal offers site Title and site Slogan: hence, there are no design for site Slogan.
4. The might be other examples.

Fortunately, Olivero can evolve to be more user-friendly. For example, from D10 to D11, Olivero added support to colour change with a setting. We can evolve more Olivero by creating a setting for $links and other enhancements.

However, Drupal still support base themes. So instead of using Olivero as the main theme and using its limited features, we can create a new theme and use Olivero as a base theme.

For some sites, I would prefer using Olivero directly as its setting for colour change is quite good for those sites. But currently, I still need to create a theme to complement the missing features in Olivero, especially the Language Switcher bloc.

The Needs Review Queue Bot → tested this issue. It fails the Drupal core commit checks. Therefore, this issue status is now "Needs work".

This does not mean that the patch necessarily needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.

Consult the Drupal Contributor Guide → to find step-by-step guides for working with issues.

False positive

We discuss this now long enough. What has been coded is wrong, settings need to be used. This is not a design thing.

Submaintainer have been asked, no feedback within a resonable time (4 years). The chance to comment has given, we now fix the defect and commit the bugfix.

Frontend framework manager here.

I agree that removing links forcibly from twig is not ideal, at the same time the design calls for no links in teasers, and that was confirmed several times over the years (#5, #61).

No links in teaser is a constrain we have to work with.

We can find solutions if we reframe the problem. What I got from the issue and all the comments is that this part is the real issue:

the Olivero theme is forcing the links to not be displayed, regardless of the field display configuration

We can totally reconcile the display and configuration:

• Don't explicitly exclude links from the node teaser (this is in the current MR)
• By default disable "Links" on the teaser display (this is not in the current MR)

That way we follow the design while making sure we didn't break expected functionality.

There are a few things to keep in mind:

• If it's disabled by default people might not be aware it's even possible to have when they change theme, making the links even less relevant maybe?
• How do we deal with existing sites? I can't support changing the default homepage of all the Olivero sites out there. There needs to be an automated way to prevent that, or at least copious release note and change record to explain to less technical users how to go back to what they had before (no-links)

We could also go another way and follow Claro/Gin: have Olivero in core and a "Better Olivero" in contrib to try more things out.

Before going further I'd like to have some ideas on how to deal with existing sites, knowing that changing all default homepages should be the very last solution.

Removing subsystem maintainer tag, we had that in #61,
Removing product manager tag, this is a technical issue, not a product issue.
Tagging for release managers for the config update part if it comes down to that.

@nod_ Thank you for joining the discussion, understanding the problem, and streamlining solutions.

Changing the default configuration to hide the "Links" field in teaser display appears to be the simplest compromise, and the implementation that I would have expected given the design requirement.

If you want to automate the config changes for existing sites, then we could use an update hook. The result for existing sites wanting to hide the links would be no change (no links). The result for existing sites wanting to show the links would be more involved, as those sites will likely already have a template override. If that template override considers the links field configuration, then the Links field configuration would need to be changed back after the update. If that template override does not consider the configuration, and forces the links to be rendered, then the theme developer can decide whether or not to remove their override and consider using configuration, or not. Therefore, a change record should be included which describes that scenario.

Personally, I feel the initial design decision to hide the links should have already been documented more obviously, such as in the theme README. Therefore, I think the decision to remove the links by default should added to documentation.

Another option to expose this decision more clearly is to have a theme setting which ultimately drives the Link field display configuration, e.g. "Hide the node 'Read more' link in teasers.", which would be enabled by default.

I like the way the discussion is moving to. But the main question are:

Do we plan to implement the change in Olivero without the need to have a sub-theme?

Or, to display the links, we need to create a new sub-theme based on Olivero?

In short, a single theme (Oiivero) or two themes (Olivero and the sub-theme)?

sites will likely already have a template override

Having template overrides also mean working in another theme based on Olivero. This requires templating or hooks overrides knowledge.

Another option to expose this decision more clearly is to have a theme setting which ultimately drives the Link field display configuration, e.g. "Hide the node 'Read more' link in teasers.", which would be enabled by default.

I think this is the best solutions for Olivero users who do not need to create a sub-theme based on Olivero. With an option (on or off), a user does not need to know about templating or hooks.

However, if the settings is off or hidden by default, when switched on, will it be styled correctly? If switching it to display the the visual is not on par with the rest of Olivero, the user will be forced to create a sub-theme.

But, based on previous conversation, we might not see a styled version of the $links when a user set the setting to “Display the node 'Read more' link in teasers”.

I think the correct plan is:

1. Add a setting in Olivero with “Hide 'Read more' link in teasers.”, which would be enabled by default.
2. Change the teaser template to respect the setting.
3. Style Olivero to support the display of $link when the setting is set to show links.

That way, user do not need to create a sub-theme based on Olivero.

Hide 'Read more' link in teasers

That's not quite it. The design has no links at all, no comment link, no flag link, no statistics link. Being able to toggle "Read more" is not enough to solve the issue.

The problem is that Read more is hardcoded to be added only on the teaser view mode. You cannot create a different view mode that has this Read more link and use that in the views configuration instead of the teaser view mode (which would solve the problem pretty nicely without a sub-theme).

We have 2 problems:

1. Read more is hardcoded to teaser view mode, and can't easily be added to a different view mode (need a configuration at the field formatter level I'd say)
2. The standard install add links to the teaser that Olivero has to remove in twig to match the design

I get the frustration that a seemingly simple solution is not accepted and merged to "solve" the issue. As was said earlier, the Olivero implementation used a workaround to match the design. Sometimes we have to say stop to the duck tape and solve the root cause properly, this is one of those times.

@xmacinfo The template override (subtheme) is only needed currently to solve the issue. I am not suggesting we require a subtheme in the future. That defeats the purpose of this issue. Also, the links are already styled. The existing config just needs to be used.

@nod_ I am not suggesting a different view mode either. The problem here is that Olivero does not render the Links field in the node--teaser.html.twig template. I think you understand that based on your previous message "Don't explicitly exclude links from the node teaser (this is in the current MR)." However, by doing so, it makes the existing Links field display config useless. In order to show those links currently, a subtheme must be created and then the template overridden to actually render the links field. Hopefully, we are on the same page so far.

The code to which you linked is for building the Links field render array. Yes, the "Read more" link is hard-coded during the build phase to exist in that render array only within the teaser view mode. However, there is still a field display config that is (should be) used to show/hide that entire Links field.

I am suggesting that Olivero remove the links via the field display config, e.g. core.entity_view_display.node.page.teaser, after the standard install creates that config. Not via the template, which is the sledge hammer approach, which makes the links field config useless. The theme setting would just be another layer of abstraction that could toggle the visibility of the Links field within any display mode that exists at the time of it being toggled. Olivero would have the Links field hidden by default on all content type display mode configs.

I think I just realized where you are getting hung up. Maybe the theme setting should be named "Hide the node Links field." Since technically, that is the field name. "Read more" is just one of the links in the list within the render array for that field.

I am suggesting we solve the second requirement. Simply hide the link field by default using the teaser display configurations.

By default disable "Links" on the teaser display (this is not in the current MR)

I suggested the theme setting just to make it easier for people to be aware the links are hidden by Olivero. The theme setting would ultimately control the teaser display configurations. The theme setting is not necessarily needed, and I realize now it can become out-of-sync if someone set the teaser display configuration directly.

@xmacinfo suggests using a theme setting to control the logic in the template, which would also work, but that is still bypassing the field display configurations which still makes them useless.

The problem statement here is:

"As a site builder, when I set the node Links field to be visible via the content type teaser configuration, the node links are not visible."

The node links are not visible, because Olivero forcefully excludes the field from being rendered within the Twig template. Therefore, the content type teaser configuration is not considered.

Since the requirement for Olivero is to hide the links, we can simply hide the links using the content type teaser configurations by default. This allows anyone wanting to show the links to change those configurations. Not create a subtheme and override the template. Since this was not the initial solution, we will need to modify those configurations for existing sites using an update hook, and document the change.

@nmangold Thanks for all the clarifications. I try to summarize the issue with assumptions and what needs to be done.

So:

• The node $links are already styled (but not shown to respect design decision).
• There is no need to add a theme settings.
• We currently need to create a sub-theme and we want to avoid this.
• Existing config can be used.
• Make Olivero hide (not exclude) the node Links field by default in the content type teaser
• Support already installed sites with a hook post update to hide by default the node links field

Once fixed the user stories would be:

"As a product manager for Olivero, I want the node Links field to be hidden by defautl."
"As a site builder, I want to set the node Links field to be visible via the content type teaser configuration."

Yes. Everything correct. Thanks!

Also, I think there should be a documentation change, or maybe a note in the theme settings, to explicitly tell developers the node links (including Read more) are hidden by default in the Article and Page teaser configs. Then, it is more clear how to show those links if desired, and people will know how to show/hide those links on new content types.