Modern Communication sites - display links issue

[Matt Varney]

Hi all,

We have a modern Communications site on which we are trying to display links for the site visitors, but have run into an issue (possible bug) and wanted to see if anyone is experiencing this.

We have tried to use both the Highlighted Content web part and Library view web part in a modern page to view links (link items) from a document library.  Both web parts are displaying the links as expected, but the experience for visitors is asking them to download a .url file instead of actually redirecting them to the URL as it natively does within the document library. 

For instance, we have a test Communications site that uses both the Highlighted Content and Document Library Viewer (admittedly in preview still) web parts.  The parts are simply meant to display the actionable links from a managed list - like in previous versions that used an actual Links List app and corresponding web part.  The display works fine, but when the visitor clicks on a link item, it prompts them to download and save a .url file.  They don't actually ever get shipped to the destination of the link. 

The links are to areas and pages within the site, as well as to sites outside SharePoint Online entirely.

 Also, to future compound the issue, if you natively view the full document library where the links are defined and stored, the links behave as expected and the user is redirected to those destinations normally when they click on them.  Links are just that - links.

We simply want to display this list of links on a different page with supportive on page content and have them behave as links.

Thanks in advance for any insight.

[#2]

Why arent you using QuickLinks?

[#3]

We require item level permissions on the links, so we wanted to manage them in a managed list.   That does not seem possible using the modern quick links (which looks like just on-page content rather than true managed content).

[#4]

Also, we will have HUNDREDS of links to manage and doing that on page is not optimal.

[#5]

Well, it's perhaps stating what's obvious, but the webparts clearly don't have the code to understand that a .url file should be processed and then the client redirected, rather than downloaded. The document library code does have this.

I imagine you could develop your own, or add a request to uservoice. but it would seem like quite a niche requirement.

Maybe come up with a solution not using .url files.

[#6]

Perhaps I wasn't clear and I apologize if so.  

Yes, it is looking like the modern web parts are in fact missing code and functionality. That is the reason I think this is a bug or missing feature in the current release.   You are right and the native experience directly in a document library will work fine and process the request for the .url object as a redirect.  But, when you use the out of the box delivered web parts to display the contents of that library on a page, the experience is broken as the browser attempts to download the url items, rather than processing them as actual web links.

We've opened  a case with Microsoft, so we'll see what they say.  I'll share what I can when I learn more.

We would love to use a solution that does not force us to use .url files, but that is the delivered functionality from SharePoint.  SharePoint is transforming all web links in document libraries to .url items.  So, in a standard document library, you click on Add and choose "link", you get a short form where you paste in a URL and give it a title.  If you paste in anything (such as https://contoso.sharepoint.com/sites/hr or even http://www.bing.com), it automatically appends .url on the end and transforms it into that kind of object.  That might be part of the issue and where code is missing or wrong (or intentionally doing it for an unknown reason).  Perhaps a solution would be to add a content type (hopefully delivered by Microsoft soon) that will not do the .url transformation and will allow for native treatment of a standard web link.

So, hopefully that is a bit more clear. I wouldn't think that having a list of links on a page and making sure that they actually act as expected when you click on them isn't an unusual request. We need more than what the Quick Links web part provides because we have a large number of centrally managed links that will be secured (or at least audience targeted). We are trying to provide a premier experience to a wide variety of users. Each user would only see the much smaller subset of links that they need.  When that large diverse audience comes to this communications site (a publishing layer of our intranet), we want to guide them quickly to the deeper structures and to other systems as needed. Surely we are not the only customer that has this need.

[#7]

Why not store the links in a custom list, use audiencing, then write a webpart to display them in some pleasing manner.

I'll be interested to see what support say about it.

[#8]

Same issue - because items in lists are just items now. There is no "Links" list app anymore on Modern Communication sites.  This used to be very easy and possible.  We have it all over the place in classic sites (and on prem). Now, not so much.

In order to accomplish this, it looks like we are going to have to either develop custom content types (to replace the ones that they no longer support) or use a 3rd party to dynamically apply XSLT to transform the link item back into a workable link.   

This is either a bug or a an intended deviation from the past, so I'm hoping the ticket with Microsoft will illuminate that.

[#9 · Accepted solution]

Hi - I made a custom list to contain links, including a 'category' choice field

And then displayed it on a modern page using the "List (preview)" web part:

The links are clickable in this web part and open the target page as expected

Thanks

Nigel

[#10]

This suggested solution technically works, but there are additional experience issues that are occurring with the modern web part.  I'm hoping these get addressed soon, but the issues are:

• Column widths in the display are truncated (probably according to screen size?), which causes the values in the fields to be truncated.  Sure, you can move the width of the column, but the experience is truncated and the web part is not configurable enough to get around that.
• The "Add" button appears in the web part, even for users who don't have permission to add items to the list.  When such a user selects the "Add" button on the web part, they get a small blank fly-out menu (similar to the one an authorized contributor would see and use, except it is much smaller and empty).  
• Additionally, with the web part, any user gets the select column (the radio button to the right of the item) that allows them to attempt to share the item with EDIT permissions by default.  I expect this is by design to encourage sharing, but seems a bit aggressive for communications sites which are generally less "collaborative" and more "publishing" oriented. The item owner (not the site owner) does get an email to approve or deny the sharing, which is good I guess. 

[#11]

Hi,

Having the same issue. The URL added to the library can be opened in a new tab from the library.  However, when trying to open URL from the Document library view web part on the modern page it will download the link. But when trying to open URL from the Document library view web part on the classic page it works fine.

Believe this should be fixed, it's critical to be able to do it from the page not just from the library, otherwise, why does such web part exist? Document library view web part has a significant difference from the Highlighted content web part, it displays views, which is quite important. And having URLs in the library oppose to Quick links has its benefits, for instance, you can filter and group items in the library and use this view on a page.

Hope to see some solutions soon.

Thanks in advance.

[#12]

Indeed.  The functionality exists in classic view, but not in modern.  A link is an object to be acted upon (i.e. open the link), not an object to download.  Who does that?  Is there a large customer base doing this now? The thought process in this design is perplexing.  I think the good news might be that this can be corrected easily since the functionality exists (and has existed for decades).

[#13]

Well it's April 2019 (one year later) and I stumbled upon this discussion while I was researching the same issue around links in the document library web part. Surprisingly this still isn't addressed.....

In my case, I'd like to add links in the document library to Microsoft Stream videos. That way tags can be added to those videos no different than other files in the document library (i.e., word, excel, PDF). In addition, all these files can then be found using the search.

[#14]

I'm happy to report that it looks like Microsoft has finally fixed this issue!  In a modern page, URL links will now open up in a new browser tab.  I've tested this in Edge and Chrome.

[#15]

@Steven Collier , @Matt Varney , I'm facing an issue where if I put a modern page link in QuickLinks web part, it would save and show up as usual but would disappear once I refresh the page. The same would happen even if I put it as a hyperlink using Text web part. This doesn't happen with other classic view pages. See attachment. Any suggestions?

[#16]

@Pat Beautz& @Matt Varney  That's correct, but the very important information is, that it works only with the column "Name (linked to document with edit menu)". If you use as example "Name (linked to document)" it doesn't work.