Frantic User Stories: Relative URLS and the Quick Launch in WSS 3.0

Disclaimer: This article addresses the SharePoint 2007 Standard (WSS 3.0, not MOSS) environment. Some of my comments may not apply to other versions of SharePoint. Also, custom-developed solutions are not an option for any scenarios outlined in this article. I limit my approach to end user/power users who do not have
access to such resources.

Short answer: Nothing. The link was manually added to the Quick Launch. Manually-added links are not dynamically connected to the source list/library; therefore they don’t respond to such changes.

So what does all this mean? It means you have an opportunity to allow SharePoint to do a lot of valuable work for you, which is why much of the time it’s a best practice to allow this to happen.

When you choose “Yes:”

1. Every time you select a new default view for the list/library in question, the QL link will automatically update itself to point to that view.
2. If you delete the list/library, the QL link will also automatically be deleted.
3. If you move the site (or migrate it to SharePoint 2010), the link will not break or point to a wrong target- it will automatically update itself to retain navigation to the target list within the site in its new location.
4. If you choose later to go into the list/library settings (under Advanced Settings) and select the “No” option for “Display link in the Quick Launch”, the link will be removed; if you later choose “Yes,” it will reappear with all the dynamic connectivity retained.

These are some major advantages!

Worth noting- you can only get this result once. If you don’t select “Yes” at the time of creation, you can’t later change your mind and get these advantages back.

If you select “No,” the link won’t get placed on the QL. To put it there, you’ll have to go to Site Settings – Quick Launch to manually add it wherever you want it to go. Even if you point to the default list/library view and format it as a relative link, it will not have that dynamic connection described above:

1. Changes to the default view won’t carry over to the QL.
2. Deletion of the list/library won’t result in deletion of the link.

To reiterate: The dynamic behavior benefit is only available when “Yes” is selected as the “Display on Quick
Launch?” option at the time of list/library creation.

This is why my Frantic User experienced what she did- in her case, when the list in question was created, the creator did NOT choose “Yes.” The link was then manually added to the QL. Therefore, when she deleted her list, the link remained on the QL since the dynamic connection was not present. The link did not “know” to respond to that deletion activity.

She didn’t know this would occur so she perceived it as error behavior. As many Frantic Users do, she jumped to the conclusion that she’d caused it. I explained the reasoning, assured her SharePoint was behaving exactly like it was supposed to, and reminded her how to get rid of the link.

MORE ON DYNAMIC and/or RELATIVE LINKS

How can you identify whether an existing  Quick Launch link is dynamic and/or relative?  

Go to Site Settings – Quick Launch and click the Edit icon for a link. If the URL field is grayed-out and cannot be modified, it’s a dynamic, relative link. You get all the benefits listed above.

If the URL is not grayed-out, and appears something like this: /sitename/listname/viewname.aspx or lists/issues/allitems.aspx  it’s relative but NOT dynamic. The key feature is that in the QL, relative links never start with http.

To increase the portability of a site, I believe in using relative URLS whenever it makes sense and is possible. Correctly formatted relative URLs will automatically continue to work after moving/migrating.

So far we have really only talked about the Quick Launch. How about links elsewhere, like in the Top Link Bar, Content Editor Web Parts, Links Lists, links embedded in documents or links from outside pointing in? Can they be dynamic and/or relative?

These are more complicated areas but I will take a stab at it. (Comments are welcome if I have incorrectly stated anything or left anything out, but keep in mind I am speaking about WSS 3.0):

• Top Links
• Top Links cannot be dynamic.
• If a Top Link points to the default view of a list/library, and you select a new default view, that Top Link will require a manual update.
• Top links can be relative (and should be, IMO) if the URL you are pointing to is in the same site collection.
• If a top link is pointing to a non-SharePoint target, or a SharePoint target in another site collection or farm, it cannot be made relative.
• Links in Content Editor Web Parts or Links Lists
• You can format links in Content Editor Web Parts and links lists as relative links under the same caveats- they must point to targets in the same site collection.
• Just make sure you enter the URL with the leading forward slash (or sometimes …/ or possibly even no forward slash at all, depending on the location ) and test it afterward to make sure it works.
• Links in documents
  • Links in documents are a different situation.
  • Documents wander and move around and you cannot be sure that they will be accessed in the same site collection they were created in, or even inside SharePoint at all.
  • Therefore, I believe embedded links in documents should be absolute (must use full URL path beginning with http:// ) so they will work no matter where the document is or how it’s opened.
• Links from outside pointing in to SharePoint
  • Links pointing in cannot be relative or dynamic.
  • For example, our company intranet is not SharePoint, but often links to SharePoint content. These links are always absolute (hard-coded) and if their targets move or change how the URLs are constructed, the links will fail.

Remember- always test every link to make sure it works as expected!

Image may be NSFW.
Clik here to view.

Image may be NSFW.
Clik here to view.