Referencing jQuery, jQueryUI, and SPServices from CDNs

OK, I admit it. Now that SPServices is available on a CDN, I’m coming around to thinking that CDNs might be a good idea in some cases. I had been balking at using them primarily from a control standpoint, and I’m still concerned with that aspect. When you host the script and CSS files you are using yourself, you know exactly what you’re going to get. You control the content, the naming conventions, the storage location, the uptime, everything. With CDNs, many of those things are no longer your problem, but you give up some control. I don’t think that CDNs are perfect in every situation, but they can sure be useful.

When I was working with Dan Antion and his team last week, I needed to quickly get something up and running while they were all staring at me, expecting me to perform. (They are the nicest people, but it’s still unnerving to be on the spot to write great code on demand. It seems that I managed to pull it off.) Rather than trying to go out and download jQuery, jQueryUI, and SPServices right then, I decided to quickly toss together a txt file I could easily point to in a Content Editor Web Part (CEWP).

Here’s what I came up with. Google hosts jQuery, jQueryUI, and all of the standard jQueryUI themes, and SPServices is now on cdnjs.

<!-- Reference the jQueryUI theme's stylesheet on the Google CDN. Here we're using the "Start" theme -->
<link  type="text/css" rel="stylesheet" href="" />

<!-- Reference jQuery on the Google CDN -->
<script type="text/javascript" src=""></script>
<!-- Reference jQueryUI on the Google CDN -->
<script type="text/javascript" src=""></script>
<!-- Reference SPServices on cdnjs (Cloudflare) -->
<script type="text/javascript" src=""></script>

I didn’t realize it at the time, but this txt file has become a standard part of my toolkit already. I’ve added it to three client environments just since last week. It’s the A #1 fastest way to get something up and running, even if you know you’re going to host the files locally later.

You simply add a CEWP to whatever page you want to work on, and then point the Content Link to wherever you’ve stored the txt file above. I usually use a Document Library in the root site of my Site Collection called ScriptCSS or something like that. You can, of course, just paste the contents of the txt file into your master page if your use of these tools is going to be ubiquitous.

Adding a Tabbed View to A Web Part Page Using jQueryUI

Sometimes I work on something and blindly stumble into a neat trick. The other day I was trying to figure out how to reliably add a tabbed view to a SharePoint Web Part Page. I was working in SharePoint Designer, so I had total freedom to try whatever I wanted.

The idea was to show a set of tabs, each of which could contain at least a Content Editor Web Part (CEWP) initially. We wanted it to look something like this:

Tabs Mock UpAside: Wireframes drive me a little batty because they turn into the goal rather than just a useful development tool. Mock ups like this using something like Balsamiq make far more sense to me. The Comic Sans makes it very clear to everyone that this is the basic idea, and we’re not talking about pixel placement.

My first thought was of course to use Christophe Humbert’s most excellent Easy Tabs, but for some reason that wasn’t working in the page. Since we’re already using jQueryUI for some other things – this is a highly customized environment – I figured that it would be a good alternative and would probably give me more control of the display.

If you look at the jQueryUI documentation, you’ll see that there is some specific markup required to get the .tabs() widget to function:

<div id="tabs">
      <li><a href="#tabs-1">Nunc tincidunt</a></li>
      <li><a href="#tabs-2">Proin dolor</a></li>
      <li><a href="#tabs-3">Aenean lacinia</a></li>
   <div id="tabs-1">
      <p>Tab 1 content</p>
   <div id="tabs-2">
      <p>Tab 2 content</p>
   <div id="tabs-3">
      <p>Tab 3 content</p>

Once you have that basic markup in place, you can make this simple call to activate the tabs:


There are multiple options, of course, but that gets you the basics.

I tried a number of things, but the main difficulty I had was that Web Part Zones cannot contain markup; they can only contain Web Parts. SharePoint Designer strips out any markup that you add manually inside a Web Part Zone.

Somehow I thought of trying to wrap the Web Part Zone with the markup I needed to make the tabs work instead. Even better, each tab could have its own Web Part Zone so that we could edit existing Web Parts and add new Web Parts to the tabs at will. That markup ended up like this:

<div id="team-tabs">
    <li><a href="#tabs-how-we-help">How we can help</a></li>
    <li><a href="#tabs-case-studies">Case studies</a></li>
    <li><a href="#tabs-projects">Current projects</a></li>
    <li><a href="#tabs-applications">Applications we support</a></li>
  <div id="tabs-how-we-help">
    <WebPartPages:WebPartZone runat="server" Title="loc:HowWeHelp" ID="HowWeHelp" FrameType="TitleBarOnly"><ZoneTemplate>
  <div id="tabs-case-studies">
    <WebPartPages:WebPartZone runat="server" Title="loc:CaseStudies" ID="CaseStudies" FrameType="TitleBarOnly"><ZoneTemplate>
  <div id="tabs-projects">
    <WebPartPages:WebPartZone runat="server" Title="loc:Projects" ID="Projects" FrameType="TitleBarOnly"><ZoneTemplate>
  <div id="tabs-applications">
    <WebPartPages:WebPartZone runat="server" Title="loc:Applications" ID="Applications" FrameType="TitleBarOnly"><ZoneTemplate>

This markup gives us this nice UI. I’ve blurred out the specific content in the CEWP, but you should get the idea.jQueryUI Tabs Example

The really nifty thing about all of this is that editing the content of each Web Part Zone seems to work just fine in the context of each tab. In other words, not only do we get the user experience (UX) goodness from the tabs for the end user, we also get it for the few people who will be editing the tab content.

Editing Web Part Zone Content

Adding Script into a Content Editor Web Part (CEWP) in SharePoint 2010

This post was cross-posted on on 9 May, 2011.

In my earlier post, I showed how to add script into a page using the CEWP in SharePoint 2007. In this post, I’ll do the same for SharePoint 2010, though in SharePoint 2010 there are other options as well.

It’s worth repeating the intro to the 2007 post:

This one may seem so obvious as to not merit a post or two, but I get questions on it often enough and I realized that if I had posts to refer to, it’d be helpful. I don’t see the CEWP as evil like many people do, though using it can certainly can cause you problems if you use it unwisely. (I generally agree with Andrew about using it on Publishing pages, where script in the CEWP can wreak true havoc.) Assuming you know what you are doing, here are the steps to add script into a CEWP in SharePoint 2007.

The basic idea is the same in SharePoint 2010, however because things have moved into the ribbon the steps are a little different. Christophe Humbert and I have both done posts about this in the past. His was About Scripts, Web Parts and Urban Myths and mine was Script in Content Editor Web Parts (CEWPs) in SharePoint 2010. I’m going to run through the steps here anyway, but you should also take a look at those posts for more info.

Once you’ve added a CEWP to your page, if you open the Tool Pane you’ll see that the “Rich Text Editor…” and the “Source Editor…” buttons are no longer available there.


Instead, we need to turn to the ribbon. First, make sure your cursor is inside the text area for the CEWP.


Next, look up at the ribbon. The important thing to notice is the HTML dropdown at the right of the Editing Tools tab, Format Text sub-tab.


When you drop that down, you’ll see two options. The one we need is “Edit HTML source”.


Yup, there’s our favorite white “editor” box again. One would have thought that Microsoft might have improved this UI in 2010, but clearly it wasn’t on the priority list. I’m adding the simplest JavaScript here: just an alert.


When you click OK, you’ll see (for a fleeting few seconds), this message in the notification area (by default, the upper right of the page, just below the ribbon container):


Read this as “Your HTML source has almost definitely been messed with.” The question is how much, and you’ll just need to check to see. There are undoubtedly some rules around this, but I’m not aware of where they may be documented.

Even with this ridiculously simple JavaScript, the formatting changes a bit:


So, while this approach works some of the time, using the Content Link and pointing to script in a file stored somewhere in the Site Collection is a far better way to go. Trust me, it’ll save you headaches. It’s also a better way to manage your scripts and follow good development practices.

Adding Script into a Content Editor Web Part (CEWP) in SharePoint 2007

This post was cross-posted on on 26 April, 2011.

This one may seem so obvious as to not merit a post or two, but I get questions on it often enough and I realized that if I had posts to refer to, it’d be helpful. I don’t see the CEWP as evil like many people do, though using it can certainly can cause you problems if you use it unwisely. (I generally agree with Andrew about using it on Publishing pages, where script in the CEWP can wreak true havoc.) Assuming you know what you are doing, here are the steps to add script into a CEWP in SharePoint 2007. (My next post will show the analogous method for SharePoint 2010.)

You can simply put your script and any references it is dependent on into the CEWP using the “Source Editor”. There are many references on how to do this out on the Web, but it’s pretty simple. You add the CEWP to the page, open the Tool Pane, and click on the “Source Editor…” button. (Note that it’s NOT the “Rich Text Editor…” button that you want to use.)


This opens a window in which you can paste your script. Calling this “box” an editor is laughable, but there are many occurrences of these white “editor” boxes throughought SharePoint’s UI. Be sure that you are only loading references to other scripts once in the page. For instance, you may already be referencing jQuery in your master page. Here I show references to the latest versions of jQuery and my SPServices library stored in a Document Library. 

CEWP Script Editor

CEWP Script Editor

The other option (which is often preferable) is to use the Content Link to point to a file stored somewhere in the Site Collection. You simply paste in a URL reference to a file you have either in _layouts, or a Document Library, or really anywhere that allows you to reference the file with a URL, and that file will be pulled into the CEWP. The reason this is often preferable is that you can then manage and maintain your code centrally. Yes, you can even apply good SDLC practices to your script by doing this.

CEWP Content Link

CEWP Content Link

Script Error When Editing a Content Editor Web Part (CEWP) in IE8

I’m not a big fan of clunky workarounds, but they do have their place in the world.

This one occurred with a SharePoint 2007 site and IE8. Now I know that by default, this should work fine, but I’m not the first person to run across this issue.

It may happen that if you are running IE8, add a Content Editor Web Part (CEWP) to a page, open the Tool Pane and click on the Rich Text Editor button to edit it, you’ll get a script error. The error will look something like this:

Message: Invalid argument.
Line: 5739
Char: 2
Code: 0
URI: http://[YourWebApplication]/_layouts/1033/HtmlEditor.js

The workaround is to go into Compatibility View. Once the page refreshes in that view, things will function as expected. I don’t know why, and it doesn’t fix the problem, but you can get your work done.  It’ll satisfy my user until we upgrade to SharePoint 2010.