Error Deleting a Content Type – “The content type is in use”

Are you as annoyed by this “The content type is in use” error as I am?

Error Deleting a Content Type

Error messages like this that don’t give you a way to solve the problem are a sign of the devil to me. That Correlation ID does us no good (try to find the administrator in a large organization to help you out in a timely way) and there’s no good way to find out where the Content Type is in use.

In many cases the Content Type may be in use with real content. However, in the instance where you are prototyping something and delete the list where you were using the Content Type, you know that it’s not in use anymore, right?

Well, it’s still in use, actually, but only sort of. When you delete the list, it goes into the Site Recycle Bin, so it actually still exists. It’s a great safety feature, but in this case, it’s getting in our way.

You need to delete that list from the Site Recycle Bin as well as the Site Collection Recycle Bin. The former is easy: you deleted the list so you have permission to delete it from the Site Recycle Bin.

Site Recycle Bin

The latter is only available to you if you are a Site Collection Admniistrator, so you may need to find someone who has that permission to help you out.

Site Collection Recycle BinOnce you’ve deleted the list from both Recycle Bins, you’ll be able to delete that pesky Content Type. Of course, you can also wait the requisite 60 days until the list is deleted from the Site Collection Recycle Bin automatically (by default – your settings may vary), but who will remember that far into the future? And we all know that a clean Site Collection is a good Site Collection.

Generic Error Handling in SPServices

Recently, I got this question in the SPServices Discussions:

I’m new to SPServices, and I was wondering if it is possible to define some kind of out-of-the-box error handling procedure, like this:

$().SPServices ({
operation: "DoSomething",
[option1: value1],
[option2: value2],
    // ...
success: function (xData) {
        alert ("The operation has been completed!");
        // some processing code ...
    },
fail: function (jqXHR) {
        alert ("Something went wrong!");
        // some fallback code ....
    }
});

The only thing I am aware of is that you can do something like this:

completefunc: function (xData, Status) {
    if (Status == "Success") {
        alert ("The operation has been completed!");
    } else {
        alert ("Something went wrong!");
    }
}

However, this solution will also execute the success-branch when the server returns an XML-document containing error messages. Above that, I don’t think it’s that elegant because you would have to check the Status == “Success” every time you define a new request, which looks a little bit like overkill.

Any suggestions?

By the way: really love this project!

I was on vacation with only my iPhone (my first laptop-free vacation in probably 10 years!) so I waited until I returned to answer. The question is similar to many others I’ve received since I started working on SPServices.

Oh, I’d love to add something like this! Unfortunately, it’s not that simple.

There are two main layers where an error can occur:

  1. In the AJAX call itself. This really only occurs if the endpoint (SharePoint) isn’t responding, almost always due to the servers being down. SOAP may be an old, crufty standard, but it’s damn reliable.
  2. In the Web Service itself. Unfortunately there is almost zero consistency in the implementations. No two operations respond in quite the same way, and there’s really very little in common across the Web Services. Some operations return only one error message regardless what you’ve done wrong, and others return 5 or 6, but inconsistently. Some responses contain heavily nested XML while others contain a single element with many attributes. The only real commonality is that they return XML.

In all of my use of SPServices, I’ve found a few truths.

  1. SharePoint always responds if it’s up and running.
  2. The only time a Web Service call fails is if you pass it bad data or poorly formed XML.
  3. If you get a valid response, then the operation succeeded.

Early on I decided that my job in SPServices is to reduce the likelihood of 2. By eliminating the need to construct the SOAP envelopes, SOAP headers, etc., a huge number of errors simply never happen. It’s up to you to test the XML coming back to see if it contains what you expect.

While I could add error handling for some of the core operations, I would have to assume quite a few things about what you are doing. For instance, you might be calling GetListItems specifically to see if you get zero items back, and that might be a success to you.

What I *have* done is to add the debug mode to many of the “value-added” functions. Because I know what ought to be coming back when I make calls to the various Web Services, I can reasonably provide some error messages that are useful for you to use in setting things up. Things like this debug message:

SPCascadeDropdowns Debug Message Example
Which brings me to another important point: what should we do when there is an error? I’ve vowed to myself never to write an error message like “An error has occurred. Please contact your administrator.” (What error? Is it important? Do I need to do something to fix it? Who’s my administrator? How do I contact them? What do I tell them?) Even something with a correlation ID which can only be deciphered by an administrator is too obtuse. It’s the user who needs to know what to do if there’s a problem.

Given the myriad ways people use SPServices, I can’t possibly predict what they are building or how it should behave. It is first a toolkit and second a power user tool. The core of SPServices should give a developer lean tools that can use how they see fit. Generic error handling isn’t going to help them much because some of the edge conditions are good in some cases and bad in others. In the value-added functions, I intend the debug mode to help power users to get things set up, and then things should be humming and they should turn it off.

But what do we tell the user if there’s a problem? “I couldn’t write that item. Please try again”? Remember that the SOAP Web Services are *extremely* reliable. I can’t even recall an instance where I’ve seen a call to an operation fail when it’s passed good data and the servers are awake. We can assume that calls are going to work.

What do you think about all of this? How would you suggest I improve SPServices error handling?

SPServices v0.7.2 Countdown, Updates, and Futures

Inukshuk near Golden, BC, CanadaHello, all! I was away on a fantastic trip to Western Canada.I posted BETA1 before I left and there have already been over 500 downloads. I’m back and ready to push out the v0.7.2 release of SPServices as soon as I work through the feedback I received while I was gone.

I haven’t seen any significant issues except that I heard that SPServices wouldn’t work with jQuery 1.8.x. As usual, the jQuery team made some subtle changes – no doubt improving the library overall – that had an impact on SPServices. Luckily, this one was a pretty easy fix (for those of you interested in details, here’s the issue in the Issue Tracker), and it seems to work just fine with the earlier versions of jQuery I’ve tested as well. Of course, I’m just one guy, so any testing that you can do with the BETA2 that I posted last week would be great for the SPServices community. If there’s one thing I’d ask of anyone who uses SPServices extensively, it’s help in testing new versions.

Another thing I wanted to comment on was a question from Paul Tavares (@paul_tavares) due to a comment I made in the SPServices Discussions.

[notice]By the way, the Discussions is the right place to start any threads on SPServices, NOT the Documentation pages. Codeplex doesn’t give me any good way to track comments on the Documentation, so odds are I’m going to miss your question or comments – there are a lot of documentation pages and I can’t check them all regularly. Also, starting with an item in the Issue Tracker is often not the best thing because code posted there cannot be formatted.[/notice]

Microsoft has officially said that the ASP.NET (SOAP) Web Services have been deprecated in SharePoint 2013 – thanks to Rene Modery (@modery) for the link.

Two API sets are still supported in the SharePoint 2013 Preview framework for backward compatibility, but we recommend that you not use them for new projects: the ASP.NET (asmx) web services, and direct Remote Procedure Calls (RPC) calls to the owssvr.dll file.

So while the SOAP Web Services are deprecated, they still exist in SharePoint 2013, though they will go away sometime in the future. However, that future could be quite a way off (2016? 2019?) because earlier versions of Office rely on the SOAP Web Services to interact with SharePoint. The Microsoft replacement to SOAP is the REST interface, along with the Client Side Object Model (CSOM). In SharePoint 2010, the coverage of functionality in those two options is limited, however. In 2013, they have been significantly extended, but I haven’t yet seen (or done) a side-by-side comparison with SPServices and REST and CSOM in SharePoint 2013. I believe that the SOAP Web Services will still have better coverage in SharePoint 2013.

All that said, I believe there’s still a “long tail” for SPServices, at the very least. People are still using SharePoint 2007 and 2010 and will be for a long time. This is certainly true of my client base, as well as in the wilds, based on my conversations at conferences. Upgrades are very expensive – hardware, licensing, but most importantly time – and many organizations are making damn good use of the existing versions of SharePoint.

This means that SPServices isn’t going to become useless anytime soon. I’m going to continue maintaining it and extending it. I still see it as an extremely viable development tool for SharePoint. One of its best qualities is that it works as you move from SharePoint 2010 to SharePoint 2010 and now SharePoint 2013. You may need to tweak your code, but you won’t need to rewrite it. None of Microsoft’s client side tools can do that for you!

Stay tuned for more updates about the release, and let me know if you have any issues or feedback.

SPServices v0.7.2 is Almost Ready for Beta

It’s been a bit too long since I’ve released a new version of SPServices. It was mid-February when I released v0.7.1, and I’ve been adding new functionality and squashing bugs since then. At this point, I believe that I have a pretty stable beta ready.

If you have the time and the inclination, I’d truly appreciate any testing you could do. If you’re already using SPServices and could pop this new version into your test environment to look for regressions that would be great. Unfortunately a few regressions crept into v0.7.1 and I didn’t catch them until too long after I released it.

I’m going to release the beta in a few days and this time let it stand as a beta for a few weeks. There are some pervasive changes in this release that I think may be really useful for everyone, but since there have been almost 13,000 downloads of v0.7.1, I want to be sure that I take care of anything that might be a problem before general release – or as Microsoft would say, RTM.

The two impressive things in this release – if I do say so myself, and I do – are caching and a new function called SPFindPeoplePicker.

The caching I’ve added into this version of SPServices is somewhat rudimentary, but at the same time it can save a decent amount of traffic back and forth with the server. It uses jQuery’s .data() functions to cache the XML for each request which has the option cacheXML: true. This is basically brute force. If cacheXML: true, then the returned XML is saved as a data object on the body of the page with the request XML as the key. If you make the exact same call again, then the request is fulfilled from that cache. Note that it’s “exactly the same call”. This means that the request XML has to match exactly.

I’ve set the option to true for some of the internal calls to the Web Services operations to speed things up when you use functions multiple times. For instance, quite a few of the value-added functions make a call to GetList to get details about the current list, and there’s no need to make that call more than once during the page life. If you are creating more than one cascade with SPCascadeDropdowns, for example, you’ll see an immediate improvement.

The SPFindPeoplePicker function helps you find and set People Picker columns. (The documentation is rudimentary at the moment. Don’t worry; I’ll improve it before the release.) These little buggers are problem enough as it is, and selecting them and manipulating them with jQuery is something that a lot of people want to do. Add to that the fact that the People Picker is rendered differently in IE than in other browsers, and you have a challenge not unlike simple vs. complex dropdowns.

There are other goodies in this release, and you can see the full list of enhancements and improvements on the download page. Note the link to the Issue Tracker items for this release. (Issue Tracker is a horrible name – some of this stuff is simply new functionality.)

As I’m getting ready for the release, I’ve been looking back at some of the feedback and suggestions I’ve gotten since the release of v0.7.1, of course. Particularly gratifying are the reviews that people have left for that version. I’ve captured them below. If you’re not using SPServices as part of your SharePoint development toolkit, maybe you should be!

image