Using the “Open in Explorer” link on SharePoint 2013

A client recently had the request to add the “Open in Explorer” link for a specific document library on a site. It’s understandable, considering that finding the Open in Explorer link requires understanding of the ribbon and knowing where to look for it; this site would be targeted at users with minimal SharePoint knowledge.

Browser considerations

Microsoft says that IE 7+ is required to use Open in Explorer. However, Microsoft also says that only IE 8+ is supported for SharePoint Online. Your mileage may vary.

I tested it in Chrome, which did not work. I have heard rumors that it works in Firefox, but that sounds unlikely to me, considering it is tapping into Windows functionality.

Troubleshooting Open in Explorer functionality

The functionality seems to be a bit sensitive and the conditions need to be just right for it to work.

Note #1: “Open with Explorer” may not work if you have the  64-bit version  Internet Explorer and/or the  64-bit version of Microsoft Office installed.

Note #2: There are some issues with IE 10 and this functionality; I got it working with IE10 (32-bit) with the “keep me signed in” trick – see below for more information.

Typical error messages:

  • “Your client does not support opening this list with Windows Explorer.”
  • “We’re having a problem opening this location in File Explorer. Add this web site to your Trusted Sites list and try again.”

Solutions:

  • Ensure that the WebClient service is started (this is preconfigured on modern versions of Windows)
  • Ensure that you are using a supported browser (IE 8+)
  • Add “https://*.sharepoint.com” to Local intranet site or trusted zones in your IE settings
  • Sign in to the SharePoint Online site by using your Office 365 credentials, and make sure that you click to select the Keep me signed in check box.

Microsoft: How to use the “Open with Explorer” command and how to troubleshoot issues with this option in SharePoint Online

Creating the link

The Open in Explorer link in the ribbon is nothing more than JavaScript. We can quite easily build our own.

The basic format is as follows, for the URL https://example.sharepoint.com/template/Shared Documents/:

<a onclick="NavigateHttpFolder('https:\u002f\u002example.sharepoint.com\u002ftemplate\u002fShared\u0020Documents', 'blank');" href="#">Open in Explorer</a>

The NavigateHttpFolder function resides in the core.js file and is usually called automatically. It was a non-issue on SharePoint Online with (mostly) default branding.

Note that you need a \u002f for a backslash, and a \u0020 for a space.

In my example further on, I’ve made the link relative – it works both ways.

Making the link dynamic

The thing is, the cilent wanted a link that could be used on a site template for different projects. Each project has its own Shared Documents library, which I want to link to without having to change URL by hand. This is where I started to make it a little bit prettier:

<br /><script type="text/javascript">// <![CDATA[
var CurrentSiteURL = document.location.pathname.split("/").slice(1,2).toString();
var ExplorerViewURL = "\u002f"+CurrentSiteURL+"\u002fShared\u0020Documents";
var LinkText = "Open Shared Documents in Explorer View"
// ]]></script><br /><br /><a onclick="NavigateHttpFolder(ExplorerViewURL, 'blank');" href="#"><br /><script type="text/javascript">// <![CDATA[
document.write(LinkText);
// ]]></script></a> <br /><br />

I knew that the client would never have more than one level of project sites, i.e. a root site with underlying project sites. So, I grabbed the current URL, split it into an array based on where the forward slashes are and then just grabbed the site information, i.e. “template” from my previous example.

I used the CurrentSiteURL variable to build the URL for the document library. It made sense to make it relative, in case the base URL ever changes.

I put the link text into the variable LinkText, just to make it look nice when building the actual HTML link. It would also allow for a potential dynamic link text.

Link placement/usage

The client also wanted this Open in Explorer link in the quick launch navigation. When I tried this on SharePoint Online/SharePoint 2013, I got a nice error:

openinexplorer1

It turns out that there’s new security in the newer versions of SharePoint and you can’t add JavaScript to the menu anymore. At least, not without using real code, features and stuff that was beyond the scope of this project.

So I did the following:

  1. Put the entire script into OpenInExplorer.js in the Style Library, including the HTML
  2. Place a content editor webpart (CEWP) on the page and call the JavaScript via the webpart.
  3. Clean up the webpart settings a bit, i.e. Title = “Open in Explorer”, no visible Chrome, etc.
  4. Export the webpart and then import it via the webpart gallery so that the client can reuse it as often as they want.

openinexplorer2

Full code in OpenInExplorer.js

<script type="text/javascript">
<!--
Created by Hannah Swain, April 2013
https://sharepointhannah.wordpress.com
Using the “Open in Explorer” link on SharePoint 2013
--> var CurrentSiteURL = document.location.pathname.split("/").slice(1,2).toString(); var ExplorerViewURL = "\u002f"+CurrentSiteURL+"\u002fShared\u0020Documents"; var LinkText = "Open Shared Documents in Explorer View" </script> <a onclick="NavigateHttpFolder(ExplorerViewURL, 'blank');" href="#"> <img style="height: 24px; width: 24px; border: 0px; padding-right: 5px;" alt="Open in Explorer" src="/Style Library/client/folder_yellow_explorer.png" /> <script type="text/javascript">document.write(LinkText);</script ></a> <span style="padding-left: 34px; font-style: italic;">Requires Internet Explorer 7.0+ and Active-X controls</span>

Credits

The following articles/forum threads helped me to figure this out:

ItemStyle issues after SharePoint 2013 upgrade (?)

I have a client who is running SharePoint Online, the 2010 version. She sent me an email saying “Help! None of our content query webparts work!” I took a quick look and it was that standard error that the CQWP cannot be displayed. I thought that maybe someone had messed with the ItemStyle.xsl – that’s usually the first place to start troubleshooting.

blogxslt

I tried to log into the environment using SharePoint Designer 2010, considering that’s what I’d always used for this client. She hadn’t gotten the upgrade email from Microsoft yet, but it turned out that I suddenly needed SharePoint Designer 2013 to log in.

That ItemStyle.xsl that I thought had been messed with? It hadn’t been touched in six weeks and the last person to do anything with it was me.

I traced the issue to a section that was being used to aggregate blog posts within the environment. There turned out to be two issues: the strip HTML template I was using was throwing errors and a variable wasn’t working properly.

@Body variable

I saved the template problem for later and tried to figure out why I suddenly wasn’t actually getting any input from the @Body tag.

I made sure “Body” was actually filled into the slot in the CQWP – it was.

I checked to make sure the field really was named “Body” by checking the URL – it was.

I defined it in the XSL so I could call $Body instead of @Body but that didn’t help.

Finally, I used Heather Solomon’s snippet to see which variables were actually being passed to the CQWP:

<xsl:for-each select="@*">
 P:<xsl:value-of select="name()" />
</xsl:for-each>

It turned out that it suddenly Body was called body. That makes a difference in XSLT. I replaced @Body with @body and suddenly I had data to work with again.

Remove HTML template

I finally traced the issue to a template I was using to strip the HTML from the Body field. I had used Ben Prins’ Remove HTML markup in Content Query Web Part, which had worked fine – until it suddenly didn’t.

I replaced the “removeMarkup” template with the one from Maulik Dhorajia’s Removing HTML tags using XSLT. And suddenly it all worked.

I went through the code of the two templates and I can’t really see much of a difference – it seems to come down to the order and structure of how things are called in the code. Then again, I’m not really a developer.

Lessons learned

  • I think Microsoft has done some underwater upgrades to some SharePoint Online environments which suddenly require the use of SharePoint Designer 2013
  • There must be some differences in the XSLT rendering between SharePoint 2010 and SharePoint 2013

SharePoint and the disappearing webparts

I have noticed something odd with placing list view webparts: they disappear at odd times. I place them on the page and do something such as editing the webpart, etc. and then they’re just suddenly gone. I’ve seen this on SharePoint 2013 as well as SharePoint 2010/2013 Online, with IE9, IE10 and Chrome.

missing2

When I go to re-add the webpart to the page, I suddenly get “Wiki [2]” as a webpart title, which means that the webparts aren’t completely disappearing – they’re still there, somewhere.

By going to the webpart maintenance page (add ?contents=1) to the end of the URL), I can see that the webparts is open on the page. But… I can’t see it.

missing1

I found Jennifer Mason’s blog on SharePoint 2010, Office365: Why does my web part randomly disappear?!? which also looks at the webpart maintenance page. She has a really good tip: close the webpart via the maintenance page, then re-add it to the page via Add Webpart -> Closed webparts. Voilá – it was back on the page.

However, the webpart disappeared as soon as I tried to save the page. It even disappeared when I hit “Edit Webpart” – I had the edit webpart dialogue but no webpart.

I started checking the HTML source of the zones, to see if the webpart code changed at all to cause this issue. Long story short – the problem doesn’t seem to be there.

At one point, since I was working with simple wiki pages, I edited the webpart without editing the page first. And suddenly it all worked perfectly.

So, when you’re bashing your head against the wall or are just very tired of configuring list webparts that won’t hang around, do the following:

  1. Add the webpart(s) to the page. 
  2. Save the page
  3. Edit the webparts without editing the page first