I get many great questions in the SPServices Discussions (that’s the best place to ask questions about SPServices, IMHO, not the MSDN forums, or StackExchange, or on the Documentation pages on the SPServices site, where I rarely see them). Some of them deserve to get wider exposure by becoming a blog post, and here is one of those.
The question came in today from jshoaf and was titled Migration to SharePoint 2013:
I’m new to SPServices and I’m using it to develop on SharePoint 2010. I’m using SPServices 0.7.2. My organization will be upgrading to SharePoint 2013 sometime in the future. What will I need to do (if anything) when the new SharePoint server is installed to keep using the SPServices library? Primarily I’m using GetListItems and Query operations.
and here is my answer:
Unfortunately, the answer will have to be the dreaded “it depends”.
The SOAP Web Services are still present in SharePoint 2013, though Microsoft has decided to deprecate them. What that will mean in reality is anyone’s guess. There are lots of deprecated pieces of functionality (think sandbox) that would very difficult to remove.
The bigger question is around what you do with the results and such. The DOM in SharePoint 2013 has changed, just as it did from 2007 to 2010. If your code is nice and modular and you are using clean selectors, I would guess that you will have to re-test, perhaps adjust the code, and most likely adjust the CSS.
The upshot of this is that there simply can’t be a simple answer. The core of SPServices will work in 2013. My testing hasn’t been extensive enough to test every single operation, but the SOAP Web Services are there in 2013 and they work the same.
As for the value-added functions, it looks like the list forms in 2013 are essentially the same as in 2010 and even 2007. It’s mind-boggling, isn’t it? One would think – at least I do – that there were so many opportunities for improvement. I was extremely surprised when this was the case going from 2007 to 2010, and I’m incredulous that the forms are the same going from 2010 to 2013. But so it is.
The good news about having those frumpy forms stay the same is that the value-added functions that enhance them will generally work. Again, my testing hasn’t been extensive, but the functions everyone know and love – SPCascadeDropdowns being the primary one – seem to work fine. Of course, the whole iitem creation and editing expereience has been widened so that there are more possible ways to accomplish them.
Another question I often get is “Have you rewritten SPServices for 2013?” The answer for that is “no”, as there isn’t really any need, based on the details above. However, if you decide to use SPServices with SharePoint 2013 and you run into issues, I *definitely* want to hear about them – post to the SPServices Discussions. I think SPServices has a good few years left in it, and I don’t want there to be bugs with 2013 or 2007 or 2010 if I’m able to fix them.
I’m in the midst of working on a new release of SPServices that will return jQuery .Deferred() objects (aka promises) from SPServices calls. (See SPServices 2013.01ALPHA4 Returns a Deferred Object (Promise)) One of the reasons I’m doing this is that it will bring SPServices forward to reflect better coding practices if or when you may decide to move to REST-based calls to SharePoint instead of using SPServices to make SOAP calls. In other words, even if you decide to stick with SPServices, you’ll be using an approach that will make it easier to move forward with SharePoint as it evolves.
Remember that SPServices is open source. I rely on you, the community that uses it, to let me know what works and what doesn’t. There is just not enough time in a day for me to test everything. If I hear about problems, I try to get fixes out as soon as I can, but this is free software, folks. The best situation is one where someone runs into a problem, they devise a fix, and I get the fix to incorporate into future versions. That was my understanding about open source when I got started with SPServices in 2009, but in reality, it just isn’t true most of the time. Wouldn’t it be nice if it were, though?
If you have thoughts or concerns about all this, by all means let me know, preferably in the SPServices Discussions. (Have I mentioned that is the best place to get help with SPServices) Comments here are always welcome as well.
[important]This is what I’m talkin’ about! This afternoon, I got a request for functionality along with the proposed fix. Take a look at the Add support to allow SPUpdateMultipleListItems to use folders item in the Issue Tracker. I’m adding it into the new alpha for the 2013.01 release right away. This is how you can get what you’d like to see in SPServices, for sure.[/important]