Simple Expand/Collapse for the Quick Launch in SharePoint 2013 or SharePoint Online

Yesterday I helped my pal Marcel Meth (@marcelmeth) with a pretty simple little task, but everything’s simple if you know how to do it! We needed to add simple accordion-like expand/collapse functionality to the Quick Launch on the pages in a Site Collection. Because there were going to be a lot of links in the Quick Launch (mostly links to different views of lists), it was getting pretty cumbersome to wade through. By adding this expand/collapse capability, we could improve the user experience (UX). It’s little stuff like this that makes SharePoint usable. Never underestimate the power of a small tweak like this.

This code works on a Team Site on SharePoint Online in Office365 with its Quick Launch exposed in the normal way. Any other customization you have in place may interfere with this working. (Yadda, yadda, disclaimer, YMMV, etc.) I’m sure it will work for you – possibly with some tweaks – in any SharePoint 2013 or SharePoint Online site. You can add this script to a single page or to the master page if you’d like it to work on all pages in the Site Collection.

// Find all the top level links in the Quick Launch that have children
var topLevelLinks = $("div[id$='QuickLaunchMenu'] > ul > li:has('ul') > a");

// Prepend the little "twiddle" icon to each top level link
topLevelLinks.prepend("<span class='ms-commentexpand-iconouter ql-icon'><img alt='expand' src='/Comm/Comms2/_themes/1/spcommon-B35BB0A9.themedpng?ctag=2' class='ms-commentexpand-icon'></span>");

// We're starting with all of the sections collapsed. If you want them expanded, comment this out.
topLevelLinks.closest("li").find("> ul").hide();

// Set up for the click even of on the top level links {

  // We're going to stop the default behavior

  // Find the elements we need to work with
  var childUl = $(this).closest("li").find("> ul");
  var isVisible =":visible")

  // If the section is visible, hide it, and vice versa
  if(isVisible) {  

    // Replace the icon with its antitheses
    $(this).find(".ql-icon").replaceWith("<span class='ms-commentexpand-iconouter ql-icon'><img alt='Expand' src='/Comm/Comms2/_themes/1/spcommon-B35BB0A9.themedpng?ctag=2' class='ms-commentexpand-icon'></span>");
    // Hide the child links by sliding up. Note: You could change the effect here.

  } else {

    // Replace the icon with its antitheses
    $(this).find(".ql-icon").replaceWith("<span class='ms-commentcollapse-iconouter ql-icon'><img alt='Collapse' src='/Comm/Comms2/_themes/1/spcommon-B35BB0A9.themedpng?ctag=2' class='ms-commentcollapse-icon'></span>");
    // Show the child links by sliding down. Note: You could change the effect here.



How to Fix Errors in the Quick Launch Navigation

I was working with a client today to try to figure out an error and we saw a pattern which I wanted to document here in case anyone else ran across it. The first diagnosis was “corrupt permissions”, but that turned out not to be it at all.

The issue was on a site with a URL like this: http://[servername]/rx/sy/cx/la1

Whenever we’d click on the People and Groups link in the Quick Launch


we’d get this error:


As with many SharePoint errors, not so helpful. But there was a clue, which I’ve highlighted above: File Not Found. That didn’t make much sense because the file was _layouts/People.aspx, which comes from the file system on the server and so it *has* to be there. We were certainly able to look at People and Groups in other sites.

After staring at this a bit, we realized that the URL that SharePoint was trying to open was:

See the problem? Well, none of us did at first, either. Finally we realized that the URL SharePoint was trying to load wasn’t even valid. It should have been /rx/sy/cx/la1, not /rx/cambridge/la1. At some point in the past, the link for People and Groups had gone south on us. In fact, *most* of the Quick Launch headers were wrong, pointing to this other site URL which didn’t exist.


The fix was quick, but manual. We went to Site Actions / Site Settings / Navigation and changed the URL for the People and Groups header (and all of the other problematic headers) to have the right path to the site.


Bing, bang, bong, done. We’ll probably never know *why* the links were bad, but we know how to fix ‘em.

Lesson learned: You always have to be careful about your first diagnosis of a problem, as it might well be wrong. Because the People and Groups link was bad, we assumed that it was a problem with permissions, when in fact it was an issue with the Navigation settings, and nothing to do with permissions. Don’t be afraid to rethink that hypothesis!

BTW, rule of thumb: I’ve never seen “corrupt permissions” before.