SPServices Compatibility Issues with jQuery 1.9.1

Download jQuery 1.9.1Ouch. Last week, several alert SPServices users reported issues with jQuery 1.9.0. (See: SPServices Compatibility Issues with the Minified Version of jQuery 1.9.0) It turned out that the minified version of 1.9.0 had a comment at the end of it that caused any jQuery library which followed it to throw errors.

Today, I had a report of SPServices not working with jQuery 1.9.1, which was released yesterday.

There’s a bug in the jQuery bug tracker called Ajax request not returning responseXML that sums up the issue well. Not everyone uses the .ajax() function in jQuery, but if you use SPServices, you’re using it constantly whether you realize it or not. Since there is no responseXML object returned by 1.9.1, every call to SharePoint’s SOAP Web Services in SPServices will fail.

Needless to say, don’t update to jQuery 1.9.1.

If there’s a bright side in all of this, it’s that the issues with jQuery 1.9.0 and 1.9.1 aren’t issues in SPServices or in the way I’ve coded anything. As I said in a forum earlier today, before I knew about the 1.9.1 bug:

Don’t ever point to ‘latest’. There are frequently changes in new versions that break perfectly fine old code.

While most of the mainstream CDNs provide ways to point to the current version of script libraries, e.g., jQuery.latest.min.js, don’t be tempted. These latest two versions of jQuery would have broken all of the SPServices-based code in your SharePoint installations. Make that a part of your governance: no pointing to ‘latest’ versions of script libraries.

Herre’s hoping that 1.9.2 is a better release.


  1. First, sorry about the disruption. We have more than 6,000 unit tests but of course there will always be things that we don’t know are broken until the release gets into the field.

    At this point we’re not doing a bunch of betas and release candidates for releases because, to be honest, just about NOBODY uses them and we get no useful feedback. If you’d like to help us test and debug, the up-to-the-second build is at http://code.jquery.com/jquery-git.js. Also, we’ve gone through a lot of trouble to create jQuery Migrate and it’s just about impossible to download 1.9.x without also seeing Migrate, but people continue to do it the hard way and try to upgrade without first using Migrate.

    I absolutely agree with your statement about using jquery-latest.js or the Google CDN URLs that don’t specify a full version ( /1/jquery.js). We’ve tried to make it harder to find those files, and may remove jquery-latest in the distant future if we can figure out a way to do that without breaking a bunch of sites. We had 1.9 in the work for months with blog posts all the way back to last June describing what we would do, yet the day of the release all hell broke loose with people using jquery-latest who had no idea why their code broke.

    Ultimately, the developer is responsible for testing a site with all its dependencies; there’s no way you should let something as important as jQuery be updated without re-testing. Being a version or two behind on jQuery on a production site is not a problem as long as everything works together. It’s scary enough that people let Facebook, Twitter, ad networks, analytics, etc. run arbitrarily updated JavaScript on their site with no testing.

    • Dave:

      I hear you on all counts. It’s a struggle to keep SPServices current with the jQuery releases. I work on it alone, and it’s not my actual job. As your team makes changes, I need to do so as well. I simply don’t have the time to test with all versions or stay ahead of what you’ve already released, as much as I would love to. (There are also at least 6 different versions of SharePoint I’m trying to support, each with dozens of language packs.)

      jQuery is an extremely powerful and well-built library. You guys do yeoman’s work and I think you communicate extremely well about what you are up to and where you are going. All that communication is only successful, of course, if people actually read or listen to it. It’s as if everyone expects jQuery (or SPServices) to work like their telephones: persistent dial tone. However, both jQuery and SPServices are toolkits. As developers, we simply have to test and adjust.

      Keeping an API 100% backward-compatible is also a tremendous challenge. We’re all learning people (at least I can say that I strive to be) and we realize from time to time that we should have done something in a better way. That’s where you guys on the jQuery team are going with 1.9 vs. 2.0, and it makes total sense. It does confuse a lot of people, but they just need to do their homework.

      You and I both know the fun of producing open source software. When it works, we hear virtually nothing from anyone. When it doesn’t, everyone wants it fixed immediately, or else! At least there are the oodles of money. Oh, wait…


      • You are doing a very great job with SPService and I enjoy using it. So ceep up working on… It doesn´t matter whether there is as failure in the current version. I know that you will fix this and those things just take time ;-) THX for the development of SPService :-)

  2. As a die-hard SPServices fan, I often struggle with several library incompatibilities while trying to maintain intranet simple applications. We get a mandated framework from IT which limits what we can do. Legacy opensource that gets utilized (jPoint) is no longer maintained and has several issues with later jQuery. I really appreciate the challenge that both you and the jQuery team face when upgrading features and fixing bugs. I have one page that requires three different versions of jQuery to operate properly :-( The only alternative is to refactor thousands of lines of javascript! Thanks for the contributions and please keep up the good work.

  3. I was in a situation where I was stuck using 1.9.1 and found a workaround. The core problem is that responseXML isn’t coming back. However, responseText DOES come back. So, lets treat it like XML and then go over that instead.

    Instead of:

    $(xData.responseXML).SPFilterNode(“z:row”).each(function() {


    $($.parseXML(xData.responseText)).SPFilterNode(“z:row”).each(function() {


Have a thought or opinion?