The file entity .tpl.php displays the filename, analogous to the use to titles on nodes. I think that the filename is not relevant in most non-administrative contexts unless it is part of the configuration in the "manage file display" settings (ie, a "generic file" download link). Additionally, files shouldn't generally need to link to the file entity page.

I know that you can change the filename display by overriding the file entity template for a particular site, but the default template should attempt to address a majority of use cases--in general, sites should not need to override the file entity template. I don't think that the current template fulfills this goal.

I would be in favor of either just removing the file name from the template, or making the filename configurable through the UI--maybe as a disabled-by-default extra field in the "manage display" tab via hook_field_extra_fields(). With the extra field approach, it would make sense to add the other file properties as extra content as well.

I will write a patch if this task makes sense, and if we can hash out an approach.

Comments

dddave’s picture

Do I understand this issue correctly that it explains my problem here: #1244916: How to not display parts of the url as title of a video? [media 7.2x compatability?] ?

dave reid’s picture

I have temporarily disabled the title from displaying for now with http://drupalcode.org/project/file_entity.git/commit/a6b562b. It can be re-enabled by changing $variables['page'] = FALSE in a hook_preprocess_file_entity().

dave reid’s picture

Version: 7.x-1.x-dev » 7.x-2.x-dev
dave reid’s picture

Title: configuration to hide filename in "rendered file" template » Configuration to show or hide filename in "rendered file" template
Category: task » feature
Priority: Major » Normal
RobW’s picture

In case anyone is wondering the current state of this issue, the header is being hidden from visibility but not assistive technology with .element-invisible. From the code:

  // Hide the file name from being displayed until we can figure out a better
  // way to control this. We cannot simply not output the title since
  // contextual links require $title_suffix to be output in the template.

I'm working around this by adding templates based on view modes and editing markup there.

klokie’s picture

Hi, I've had to remove the title in a custom module as suggested in #2. Having a link within that assistive block, even if it is hidden, breaks an outer link that I've put around my image (as rendered by a View). Thanks for posting - I wish I'd found this thread before spending 5 hours trying other solutions!

For the record, I'm running an image-heavy fashion magazine, so having correct links work cross-platform is much higher priority for me than having filenames embedded in the HTML, which is unnecessary for most use cases IMHO.

TripleEmcoder’s picture

Issue summary: View changes

This seriously cannot remain the way it is. Forcing the HTML to contain hardcoded H2 and A elements totally breaks page structuring and SEO.

In a somewhat similar scenario Panels allows you to specify the header tag and has a checkbox to turn linking on or off.

misc’s picture

I really try to understand why the heading is in the template at all, it does not make sense for me to have a default template outputting a hidden heading with a link to the file as default. I don't see the use case at all, but maybe I am looking in the wrong direction?

dsnopek’s picture

Hiding this with 'element-invisible' creates some interesting accessibility issues for screen reader users or users of other assistive technologies. Basically, they can find themselves on this link which no one is intended to use, and the the creators of the page showing it have no idea that it's there. If we're going to hide this, let's use 'element-hidden' instead so it's hidden for everyone!

arebacollins’s picture

This H2 tag has been the cause of many a nightmare for the past few months. At the very least, getting rid of this HTML formatting in future editions would sort out the problem.

I have a table of contents module that would pick H2 tags from Drupal, Imagine my surprise when all Image names appear in the display, totally messing up the TOC and leaving me groping between the TOC module, Drupal Panels and a host of other fields that could well be interacting with my system.

I have temporarily removed the H2 tag, but need to know what to do to future proof my installation, especially with subsequent module updates.

Regards,
Collins.

ksenzee’s picture

The two approaches becw suggests in the original issue report are

a) remove the filename from the template entirely, or
b) make the filename a disabled-by-default extra field in the "manage display" tab.

Obviously (a) is quicker and easier. Any reason not to just do that?

(BTW, arebacollins, the best way to handle your particular situation is to override the file entity template in your theme. That is, copy file_entity.tpl.php from the file entity module to your site's theme folder, and edit the version in your theme not to have the h2.)

  • Dave Reid committed a6b562b on 8.x-2.x
    Issue #1245266: Disable display of the file title for now as it is...
mingsong’s picture

There is an issue with the Filtered HTML format if the h2 tag is not in the allowed html tag list.

the markup outputted would like this:

<p> <a href="/file/b1bm6wgu9qsjpg">B1Bm6WGU9Qs.jpg</a></p>

The h2 tag will be filtered and the file link will appear unexpectedly.

The workaround is run the 'Convert Media tags to markup' filter after 'Limit allowed HTML tags' by setting the 'Filter processing order' for this format.

briand44’s picture

This is not a long term patch, just a patch to align the 7.x-2.x branch with what Dave Reid committed in #12 until we figure out a better solution. Hiding it with the element-invisible class is not sufficient for us because we have links that are wrapping media markup that are breaking because of the link to the file entity that is wrapping the label in file_entity.tpl.php.

I think displaying the label should be configurable, possible via hook_field_extra_fields(), but I don't have time to work on that patch today.

ramlev’s picture

#14 The i think it would be more suitable to remove the if (!$page) part from the file_entity.tpl.php, since $variables['page'] always will be TRUE in the template_preprocess_file_entity();

brightbold’s picture

+1 to dsnopek's comment on accessibility. When using a keyboard (or screen reader) to navigate a site, you end up on this invisible link. For a screen reader user, it's annoying, and for a sighted keyboard user it's very confusing, as there's no visual indication where the page focus has gone. I'm working on a government site where this got flagged by 508 reviewers. I used the following workaround to add the element-hidden class:

function mytheme_preprocess_file_entity(&$variables) {
  $variables['title_attributes_array']['class'][] = 'element-hidden';
}
joseph.olstad’s picture

BrightBold, something like this? but needs a config option
maybe you can finish this off.

dsnopek’s picture

Why does this need a config option? When would 'element-invisible' ever be helpful? The difference between 'element-invisible' and 'element-hidden' only matters to users of screenreaders, so 99% of the users of this module won't notice the change, but the 1% who do will become slightly happier :-)

rooby’s picture

Why does this need a config option? When would 'element-invisible' ever be helpful?

Yeah, in fact I think removing it all together would be the preferable solution.

byronveale’s picture

I agree with the notion of removing completely, can't see how it is ever needed, although I might be missing something…

Patch attached.