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.
| Comment | File | Size | Author |
|---|---|---|---|
| #20 | file_entity-remove_h2_link_from_rendered_file_template-1245266-20.patch | 591 bytes | byronveale |
| #17 | file_entity-rendered_file_template-1245266-17.patch | 737 bytes | joseph.olstad |
| #14 | disable_file_entity_label-1245266-14.patch | 520 bytes | briand44 |
Comments
Comment #1
dddave commentedDo 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?] ?
Comment #2
dave reidI 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().
Comment #3
dave reidComment #4
dave reidComment #5
RobW commentedIn 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:I'm working around this by adding templates based on view modes and editing markup there.
Comment #6
klokie commentedHi, 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.
Comment #7
TripleEmcoder commentedThis 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.
Comment #8
misc commentedI 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?
Comment #9
dsnopekHiding 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!
Comment #10
arebacollins commentedThis 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.
Comment #11
ksenzeeThe 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.)
Comment #13
mingsongThere 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.
Comment #14
briand44 commentedThis 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.Comment #15
ramlev commented#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();
Comment #16
brightbold+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:
Comment #17
joseph.olstadBrightBold, something like this? but needs a config option
maybe you can finish this off.
Comment #18
dsnopekWhy 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 :-)
Comment #19
rooby commentedYeah, in fact I think removing it all together would be the preferable solution.
Comment #20
byronveale commentedI agree with the notion of removing completely, can't see how it is ever needed, although I might be missing something…
Patch attached.