You are viewing limited content. For full access, please sign in.

Question

Question

Weblink 9 - unknown file types

asked on August 14, 2015

Last year I asked the following question: https://answers.laserfiche.com/questions/52207/Weblink--How-to-better-display-unknown-file-extension-types

 

The customer just recently upgraded to weblink 9 and they are having the same issue. They added the same images to C:\Program Files\Laserfiche\WebLink\Web Files\images\edocs and then did a IISRESET but they are not displaying for users and are still showing the unknown symbol.

 

Is there anything else that needs to be done in Weblink 9? I couldn't find anything in the help files for 9 on it either. 

 

Thanks!

1 0

Replies

replied on August 21, 2015 Show version history

Hi Chris,

Thanks for notifying us of this problem!  Wes is right - we have a list of extensions on our server side for which we have images.  We assign each <img> element a class, e.g. EDocPDF, which has a background-image specified in WebLinkStyles.css.  If we don't have an icon for the extension, we give it the EDocGeneric class, which points to a generic edoc icon.  

We've filed this as a bug (SCR 131734).  In the future we'll generate a class for any extension, even  if we don't recognize it, and then users will be able to go into the CSS (as Brian showed) to customize the icons with the class EDoc[ArbitraryExtension].

For now, here's a hacky JavaScript solution adapted from Devin's reply here that will be helpful if you expect the documents to have the extensions in their names.  Suppose you want to assign a custom image to extension EXT.  Add the following to your Browse.aspx page inside of the <body>:

<script type="text/javascript">
    $(function() {
        $('a.DocumentBrowserNameLink').each(function (index, value) {
            var re = new RegExp('.ext')
            if (re.test(value.textContent.toLowerCase())) {
                var imgEl = $(value).children('nobr').children('img');
                imgEl.attr('class', 'ElectronicFileIcon DocumentBrowserNameImage');
                imgEl.attr('src', 'images/spacer.gif');
                imgEl.css('background-image', 'url("path/to/image")');
            }
        });
    });
</script>


That just checks whether a file name contains ".EXT" and replaces the icon if so.  It isn't a perfect solution, but it may work for your purposes!  Keep in mind that this (1) will fail to replace icons for items with the actual extension EXT if the extension isn't in the file name, and (2) will replace icons for items that contain .EXT in their names, even if those items have a different extension (or no extension).

 

3 0
replied on August 18, 2015

Chris,

 The good news is that you are doing everything correctly and that this should work just like it did in the previous version. The bad news though is that it's not going to work no matter what you do as it appears that Laserfiche didn't thoroughly test this updated routine in their latest 9 release. I suspect that they have decided to hard code the extensions (bad practice) into the application and therefore it will not accept, nor look for new ones in the "EDOCS" directory.  Until this oversight is corrected you will not be able use your own custom extension icons.

You can test this theory out now by actually going into a folder with entries that have custom extension icons and viewing the "RSS" feed for it as they will show in the feed.

1 0
replied on August 18, 2015

Thanks Wes for verifying this through the RSS functionality!

 

Laserfiche, is there anyone who can address this and put this in as a feature request (or bug fix) for a future version? 

1 0
replied on August 21, 2015

The way this is implemented in WebLink 9 is a little different, and it offers a lot more flexibility.  If you look at the HTML that's produced in the folder listing, you'll see that there's a css class applied based on the extension, e.g. "ElectronicFileIcon EdocDOC".  Then, there's this definition in the css file:

.EdocDOC {
    background-image: url("images/edocs/DOC.gif");
}
 
To add support for your new extension, you can add a style definition similar to this one, referencing your image.
0 0
replied on August 21, 2015

Thanks Brian for clearing this up but what brilliant mind thought that this would be a better way of doing this rather than before? I really do hope they put it back to the original code as it's way more simple than the new method.

0 0
replied on August 21, 2015

Thanks for this reply. Can you do me a favor and put a note in the SCR 131734 request to have them update this thread when there is a patch? That way it'll be easy to see when this changes if you've subscribed to the thread.

In my customer's case there are multiple file types that need this and they tend to use something.something.ext in their names so I wouldn't want to confuse them more if there was an weirdly named doc. 

Thanks!

0 0
replied on April 28, 2016

Our customer has asked again if this bug, SCR 131734 has been addressed. Is there somewhere on the support site that we can track open and closed bugs? I find no update on this one. 

0 0
replied on April 28, 2016

Hi Glen,

There is no change on this bug. If you want to track status, I'd suggest opening up a case with Support linked to this bug, they'll notify you when a bug fix is released. 

0 0
You are not allowed to follow up in this post.

Sign in to reply to this post.