01-30-2018 10:42 AM
01-30-2018 10:42 AM
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.
01-30-2018 01:40 PM
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).
01-31-2018 09:17 AM
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.
01-31-2018 10:08 AM
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.
01-31-2018 12:17 PM
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.
01-31-2018 01:18 PM
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.
01-31-2018 03:54 PMSolution
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
02-02-2018 02:27 PM
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:
04-26-2018 11:32 PM
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.
04-27-2018 04:20 AM
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).
04-16-2019 07:11 AM
07-22-2019 06:21 AM - edited 07-22-2019 06:21 AM
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.
09-02-2020 11:46 PM
@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?