Field Rendered Entity: Link to entity option not visible

Yep, that is exactly what I did. Giving a more general title so people that have not debugged the problem might not have too :)

Yep, but the dependecy is right. We just have to ensure the value of it is FALSE in case the dependency is not met, i.e. let's implement this logic when the settings form is submitted.

If that is the way you think it should work, that is fine, but I do see some value on being able to wrap the whole entity on a link if desired

#1 works perfectly! This took me HOURS to track down! Thought it was an annoying bug with DS or QuickTabs..... please, please commit this or figure out how you want to implement this per #3!

May I suggest that instead of changing the value of the "Link to Entity" field on submit, we just skip the link rendering in render_entity_link()? Patch attached.

@fago

Yep, but the dependecy is right. We just have to ensure the value of it is FALSE in case the dependency is not met, i.e. let's implement this logic when the settings form is submitted.

Let me not agree with you. IMHO, dependency is not right because in this case we can't make a rendered entity to be a link. Also, we can't rely on what elements rendered entity will include.

For example, Display Suite's 'Reset' layout doesn't include any elements at all and simply concatenates field values, which can be, in their turn - inline elements.

Patch in #1 is just what is needed in this case. Setting it to RTBC. Please submit it.

Patch in #7 fixes it for me. If you're rendering an entity, you should choose how/if to link to it in the display mode.

BUMP.

Please commit the patch from #1

#7 makes sense to me - committed, thanks!

The fix makes it IMPOSSIBLE to make a rendered entity - a link.

The fix makes it IMPOSSIBLE to make a rendered entity - a link.

This should be impossible - the rendered entity most likely contains links itself (as well as quite some block elements...).

This should be impossible - the rendered entity most likely contains links itself (as well as quite some block elements...).

Please read #8 where I explained why this is not true. Entity could be anything, including set of inline concatenated fields. And this is not a theory, I'm talking about real sites and real situations, Wolfgang.

still, it was never intended to work that way and will create troubles in most cases - that is what I want to avoid. I dislike having options that mostly don't work.

I'm sry if that makes your use-case harder, but maybe there is another easy way to do it still, e.g. just link it from the entity's template? Or maybe there is something else we can do for it? Please open a feature request for discussing on how to implement it best.

still, it was never intended to work that way and will create troubles in most cases - that is what I want to avoid. I dislike having options that mostly don't work.

Well I personally didn't have any mentioned troubles and even don't see a reason for them.

I'm sry if that makes your use-case harder, but maybe there is another easy way to do it still, e.g. just link it from the entity's template?

Not a single one I can think about atm.
Even when using Display Suite there is no UI-way (without creating custom fields and typing code) to just combine fields into a link.
While with #1 and Views - this works out of the box: you add rendered entity (as a set of concatenated fields) and make it a link.

Or maybe there is something else we can do for it? Please open a feature request for discussing on how to implement it best.

To my mind, best - is what is done by #1 - i.e. no assumptions about entity.

Yet I don't agree with the resolution and I insist on thinking again about this.
I've got one more website where I have to use patch from #1 to get things working.

Test case:

1. There is a need to link Term entities from several places: from node's page, from several views.
2. The format of printing Term name is not just <a>term_name</a>. Instead it uses fields like <a><span class="name">term_name</span> <span class="icon">term_image_field_1</span> <span class="description">term_text_field_2</span></a> - i.e. to print term with it's associated image for example.
3. Since we are going to use it in multiple places, the Drupal way to achieve this would be to create a template for printing terms like that. And using Display Suite module we can configure this template for terms for a view mode "Teaser" for example or for a custom view mode. So we are creating a Display Suite template of type "Reset" and push all needed fields as inline elements. Now when we defined it we can reuse it in Views, in Panels, or in any other Entity template.
4. Any everything would be just fine if only views allow to make our rendered entity a link!

Another example.

Imagine we need to list entities of different bundles in a view. Let's put that each has it's own way to represent itself. We don't even need to use Entity Label to represent entity. It could be ANYTHING. Let's call it "Inline representation of an entity", ok?
This is achieved by implementing templates for each entity bundle — via Display Suite or not — for a specific view mode.
So a view has no idea about their differences, it just print rendered entities in this view mode.

Now imagine we have two views — one is used by Entity Reference for drop-down list to set references (and we need no links), and another — to print the same list on the entity page, but now — with links.

The idea is straightforwad: in the former — not use links, in the latter — use links. Both using same "rendered entity" in the same view mode.

Need more examples?

Providing a patch which cancels #7 and applies #1. With it you can make inline rendered entity a link in views fields.

Some images for demonstration entities linking.

View configuration (Added Rendered Node field):

Settings of the field (note — Inline view mode and Link checkbox):

Rendered view:

Entity template configuration, using "code field" of DS module (this is just a quick example):