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


yom’s picture

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>
yom’s picture

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,

yom’s picture

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; ?>
rooby’s picture

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

I have this problem too.

rooby’s picture

Priority:Critical» Major

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

rooby’s picture

Status:Needs work» Active

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

rooby’s picture

(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.

paulihuhtiniemi’s picture

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

rooby’s picture

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

Countzero’s picture

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.

klokie’s picture

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.

rnyberg’s picture

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

rooby’s picture

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).

Devin Carlson’s picture

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.

bneil’s picture

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.

bneil’s picture

Issue summary:View changes

had html tags in the description - just removed them

bneil’s picture

Issue summary:View changes

Added related issue #2077875

bneil’s picture

Issue summary:View changes

Added related 1892218

rnyberg’s picture

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

RedEight’s picture

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.

amaisano’s picture

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.

TorreyToomajanian’s picture

I stumbled upon this issue myself, and this Stack answer proved to solve the problem:


Answer #2 was the solution for my problem, as I have a template_preprocess_node() implementation that automatically applies the view mode of all nodes to their element within each node.tpl.php file. But I also have custom .tpl files for most of my view modes (such as node--post--flag_dropdown.tpl.php) so in my case, the View I was using was targeting 1 specific node type, and rendering the following as views fields:

1) Content: Path (excluded from display)
2) Content: Rendered Node

The rendered node was being output as a link that references the hidden Path token. My mistake was that I thought that my custom .tpl file for this View Mode was being registered, but it actually was not because I incorrectly named it, so it was falling back onto the original node.tpl.php template which, by default, contains a that prints the node title as a link (unless you are on the node's page). When I fixed the naming of my custom .tpl.php file (which does not have that ), and it began to properly register that template instead of the default, this problem was solved. If you have never overridden/edited the node.tpl.php file and are having this issue, consider using custom node templates for your view modes.

It should be noted that I first saw and tried the solution proposed by reply #3 on that Stack page, and they were correct in saying that if you were to choose "Show Entity Label" and checked the "Link to Entity" checkbox, then switched to "Show Complete Entity", that checkbox stays marked. I didn't dig into Views to see if this could have been the problem, but reply #3 had mentioned it as solving his problem, although someone did comment and say that that was no longer an issue. Nonetheless, try both!

kennethos’s picture

If you want to fix this by overriding the file_entity.tpl.php file (#3) you should also do this in the admin theme.

lunk_rat’s picture

@kennethos #20 thank you for reminding me! I was in a bad place trying to override templates in my frontend theme and wondering why it didn't work ...