If a file-field is outputted as a link, Drupal autocloses the a-tag to prevent bad html, I suppose (a link inside a link). In result I first have an closed empty a-tag and then the media file. I think the reason is the contexual link inside the views-output. Couldn't the contexual link be rendered before the views-output?

#2077875: Updating makes views rewrite links format incorrectly (images no longer linkable via views)
#1892218: html broken when using links


I have the same problem here, really annoying, here the result with the empty output links (a href):

<div class="views-field views-field-field-image-de-l-uvre">
<div class="field-content"><a href="/drupal7/test" class="views-ajax-processed-processed">
</a><div id="file-129" class="file file-image file-image-jpeg contextual-links-region">
<a href="/drupal7/test" class="views-ajax-processed-processed"></a>
<h2 class="element-invisible">
<a href="/drupal7/test" class="views-ajax-processed-processed"></a>
<a href="http://www.michel-maurice.com/drupal7/sites/default/files/%C5%93uvres/Michel_Maurice-Les_peintures_blanches-suite_1-43%2C5x41%2C5.jpg" class="views-ajax-processed-processed">Michel_Maurice-Les_peintures_blanches-suite_1-43,5x41,5.jpg</a></h2>
<div class="content">
<img src="http://www.michel-maurice.com/drupal7/sites/default/files/styles/series/public/%C5%93uvres/Michel_Maurice-Les_peintures_blanches-suite_1-43%2C5x41%2C5.jpg" width="150" height="150" alt="" title="">
</div>  </div>

Priority:Normal» Critical

Does anyone have the same issue?
The site was almost finished and was working good since the last updates of media and file entity modules.
I can't figure why this happen. The site cannot work properly because of this bug.
Really need help, my customer wait for his site to be functional as soon as possible.
Thanks for help,

Status:Active» Needs work

Found a quick way to resolve the problem by commenting this lines in file_entity.tpl.php

<?php if (!$page): ?>
    <?php print render($title_prefix); ?>
    <h2<?php print $title_attributes; ?>><a href="<?php print $file_url; ?>"><?php print $label; ?></a></h2>
    <?php print render($title_suffix); ?>
  <?php endif; ?>

Title:Contexual link (?) causes problems if field outputted as linkFile entity views fields outputting as a link are broken

I have this problem too.

Priority:Critical» Major

Also, this is not really critical as it doesn't critically break a site.

Status:Needs work» Active

And there is no patch so it is active. For more info see http://drupal.org/node/156119

(Sorry for spamming so many comments)

It is not specifically contextual links.
The problem is that you can't have an a tag in an a tag, so any a tags that print in the rendered file break this.

For me it is the title (which is hidden using element-invisible) and the contextual links that cause a problem.

As mentioned by yom, you can work around it by overriding the file_entity.tpl.php file that this module provides, and removing that section.

However, if you want the title to display in other situations then you might have to add some other conditional statements instead of removing it entirely.

I'm not entirely sure who should fix this or if it has to be fixed.
It's hard for users to know that you can't have a tags in a tags, or even that such a thing is happening and why, but there are also other ways you can use views to generate links within links that will break and it is up to the user not to do so.

It's a hard one to decide on and also pretty hard to fix as there is not one single place that could be the cause of this problem, it could come from anywhere.

I have not the time to actually test this right at this second but I assume if you were to do the same thing with pretty much any entity the same problem would arise.

[EDIT] Also, there are often other ways you can achieve the same thing using views and can workk around it that way.

For example, sometimes it is better to use the "File: Rendered" field instead of the "File: Rendered File" field.

Any idea when this went broken? Did field linking work in 7.x-2.0-unstable6?

Not sure exactly, but the upgrade to unstable7 broke a lot of thingsd on one of my sites.

There was recently a lot of changes to view modes.
See #1051090: Revamp file view modes: migrate media_small to teaser, media_large to full, media_preview to preview; deprecate link & original

Another probably relevant one is #1215712: Add a views field handler for displaying the rendered file

Fix in #3 did the trick for me. Thanks for this.

Also worth noting is that theme suggestions don't seem to work : tried to use my own copy of file_entity.tpl.php in my theme's folder and couldn't make it work.

The whole new system is very powerful, but makes it difficult to track down issues.

Fix in #3 worked for me too. However, the <a/> link (an inline element) is still outside of the contextual-links-region <div/> (a block-level element), so the HTML is syntactically invalid and therefore fails to work in some browsers. I've run into this problem on several sites when trying to create a link around a multi-valued file field using views, so it would be great to find a better solution.

What #11 said basicly. A real fix is still needed.

However, the <a/> link (an inline element) is still outside of the contextual-links-region (a block-level element), so the HTML is syntactically invalid and therefore fails to work in some browsers

If you use HTML5 it is valid to put block elements inside an a tag.

This is not a file entity specific problem, it would affect any entity that has contextual links or a linked title (pretty common).
The problem is if you are going to wrap everything in a link you just have to override the themeing to prevent other links from being inside it.

It might be possible to pass into the template a variable that states that it is in a link so other links can be omitted.
This would also have to remove contextual links.

It would then still be possible to break it if you have an entity that contains a link somewhere in its content.

I'm not convinced this is something to fix in this module (I'm not the maintainer though, just my opinion).

Status:Active» Closed (works as designed)

As mentioned in #13, this is not a File entity specific problem (it also exists in core with contextual links).

Wrapping block level elements in a link is invalid in HTML < 5 and issues can still arise when nesting links.

The solution is to write your own file formatters which wrap only the necessary markup in a link or that output only inline elements which are suitable for wrapping in a link through Views, etc.

Devin, do you think we could/good idea to provide a generic-enough formatter in file entity that would omit contextual links?

I think that would work well enough for 90% of the use cases most people have. Then provide some documentation stating the issue with providing other links inside of it?

I think being able to wrap a link around a file (images in particular) in a view is something that is very common for a site builder and we should try to accommodate that.

Issue summary:View changes

had html tags in the description - just removed them

Issue summary:View changes

Added related issue #2077875

Issue summary:View changes

Added related 1892218

Almost a year later, related issues have been fixed but this still does not work properly, and the fix in #3 is outdated code.

The fix in #3 had been working for about 2 months... sometime during the upgrade to 7.24 this all got borked again...

EDIT: reconfiguring the fields in views to output as links with a path token "fixed" the problem. Still had to have the hack in #3 to get it to work correctly.

Issue summary:View changes

If you are using Views to wrap this field in a link, say, back to the node it belongs to, you can set the following Views field options:

- Rewrite Results > Output as Link (use whatever token you need)
- Strip HTML Tags *PRESERVE CERTAIN TAGS:* <img> <p> <ul> <li> <ol> <h2>
- Remove Whitespace (optional)

This removes all invalid HTML < 5 block elements a well as links inside links. Works OK for me, but w/o Views you'd need to do this via a .tpl override, and perhaps use a PHP strip_tags() style command to the same effect.