This project has moved and is read-only. For the latest updates, please go here.

$().SPServices.SPRedirectWithID Not Working

Jan 8, 2010 at 10:31 PM


<asp:Content ContentPlaceHolderId="PlaceHolderMain" runat="server">
<script language="javascript" type="text/javascript" src="~/_layouts/1033/jquery-1.3.2.min.js"></script>
<script language="javascript" type="text/javascript" src="~/_layouts/1033/jquery.SPServices-0.4.7.min.js"></script>
<script language="javascript" type="text/javascript">
$(document).ready(function() {
redirectUrl: "EditForm.aspx"

I am having problems with the $().SPServices.SPRedirectWithID function. I have used as documented but it does not redirect, it stays in the NewForm page. (see below my example)

Also, if I save the item, then it reopens the newform.aspx again; if I click Cancel, it does not save...but if I click OK, it goes to an endless loop.


<asp:Content ContentPlaceHolderId="PlaceHolderMain" runat="server">

<script language="javascript" type="text/javascript" src="~/_layouts/1033/jquery-1.3.2.min.js"></script>

<script language="javascript" type="text/javascript" src="~/_layouts/1033/jquery.SPServices-0.4.7.min.js"></script>

<script language="javascript" type="text/javascript">

$(document).ready(function() {



redirectUrl: "EditForm.aspx"




Please let me know if you find anything wrong, I have tried it in different sites and lists and I get the same issue
Thanks in advance


Jan 8, 2010 at 10:37 PM
Edited Jan 9, 2010 at 2:11 AM

UPDATE: I didn't see it when I first answered from my iPhone, but you're missing the closing semicolon on the function call:

<script language="javascript" type="text/javascript" src="~/_layouts/1033/jquery-1.3.2.min.js"></script>
<script language="javascript" type="text/javascript" src="~/_layouts/1033/jquery.SPServices-0.4.7.min.js"></script>
<script language="javascript" type="text/javascript">
  $(document).ready(function() {
      redirectUrl: "EditForm.aspx"
    }); // <-- Missing this semicolon

Sorry you're having trouble. Could you please post the URL for the
page where you are calling the function both before and after you save
the item?


Jan 9, 2010 at 2:24 PM

Thanks for your response!

I added the semicolon but that the problem still persists.

This is a quick demo video of my test

In my demo, as soon as I click on wont forward

then I enter some title... click ok and it opens the new again

then it will go to a loop

after all that... it will save the new item... but the forward did not happen...

hope these details help to describe my issue... it is very strange... as I haven't seen many people having problems with this...

Very handy code and thanks in advance


Jan 9, 2010 at 4:51 PM

The video is helpful. Have you done any customizations to NewFormCust.aspx other than adding in the jQuery calls?  Also, can you paste the full URL here both from when you first get to NewFormCust.aspx and when you are returned there?

The only other difference I can see in what you are doing from my testing is that you have the js files in _layouts rather than in a Document Library.  (One of the goals of this library is to require no touching of the server whatsoever.) However, as long as they are loading into the page, that shouldn't make any difference.

The initial behavior looks right.  The way this works is this:

  • On the initial load of NewFormCust.aspx, the form action is changed to point back to the same page, with ?Source=NewFormCust.aspx?ID=[the last ID created by the current user]%26RealSource=[the actual Source for the page]
  • When the form reloads, because the ID is present on the Query String, the jQuery function then waits until [the last ID created by the current user] is not equal to the value on the Query String. This ensures that the commit has completed.
  • The user should then be redirected to EditForm.aspx?ID=[the last ID created by the current user]


Jan 10, 2010 at 12:00 AM

Hi M

Thanks for the reply. I am only customizing the jQuery calls in the form.

I also used the js files with other functions in other sites so I think that where the .js files are located should not make any difference (although I agree...I rather have them in the library than in the server).

This is the url as soon as I click New


This is the url as I click Ok for the first time


This is the url when it goes to the endless loop and returns with the browser warning message


I will try to trobleshoot later on a bit more but thanks for your help !


Jan 10, 2010 at 3:45 AM


If I were to hazard a guess, I'd say that the SPGetCurrentUser function isn't working for some reason.  Can you try to call it and see if you get back the current user correctly? If that looks OK, then try calling SPGetLastItemId to see if that works.  (Both functions are in the dopcumentation.)  One of them is probably the problem.  Once we understand which, we can do some further debugging together.

Out of curiousity, are you running an English version of SharePoint? MOSS or WSS?


Jan 10, 2010 at 4:31 AM

Hi M

Yes, running English MOSS 07 ... the only particularity is that I am using Forms Based Authentication (LDAP) instead of windows auth... I wonder if that has something to do with it... I will run these tests as soon as I get a chance... might need to do it on Monday..




Jan 10, 2010 at 2:24 PM

OK, FBA is going to be the issue.  The Web Services don't seem to allow FBA instead of Windows Authentication.  Any debugging you do would be of interest, in case it's possible to get around this.

In this specific case, SPGetCurrentUser is looking at /_layouts/userdisp.aspx to get the current user. Since, with FBA, the current user won't be available there, the house of cards falls down.


Jan 10, 2010 at 2:24 PM

Hi M

I got the chance to test and found out that the SPGetCurrentUser function returns blank. 

By looking at the function... I see that it is using the usrdisp.aspx I checked that and I discovered that the fieldInternalName/Type are commented. 

<TD valign="top" class="ms-formbody" width="450px" ID="SPFieldText">

<!-- FieldName="Name"




Luciano Arias/IT



 I think this is related to the fact that we are using LDAP for user authentication and for some reason sharepoint commented those fields?.

Not sure if something else can be done at this point; rather than override that function. (?)



Jan 10, 2010 at 2:26 PM

Funny, we both send the same response at the same time ! LOL


Jan 11, 2010 at 6:15 PM

Sorry; I thought I had replied yesterday, but just noticed that I must not have clicked the Post button after I wrote it.

You might be able to get things running by coming up with your own SPGetCurrentUser function, but I think you may have other problems with FBA.  Let me know what you end up doing.


Jan 11, 2010 at 6:28 PM

Hi Marc,

Yes I am facing a few other problems and surely they are all because of the FBA which really makes things more challenging.

This has been taking me more time than I anticipated and I need to move on with other tasks but I will keep you posted about the progress on this,

Thanks a lot ! 


Jan 11, 2010 at 6:29 PM

Sorry it's not working for you.  This is a limitation of the SharePoint Web Services, I'm afraid.


Jan 11, 2010 at 6:35 PM

no problem! yes I am used to the limitation of sharepoint and FBA :(  so not surprises here 


Jan 11, 2010 at 8:51 PM

Hi Marc

hmm I think I kind of got it working ... unfortunately I had to avoid using the current user as it brings problems from the FBA.

So I get the last Id without using the current user... I know it might not be the best but I can get the last ID used. 


The only thing is that for some reason I had to click the OK button twice before jumping to the Edit form...  

I think something is up when getting the query string values (from getQS) ... This is what I did to reproduce the behaviour:

1) This is the first url I get when I click New (which is ID)


2) This is the url when I click OK 


but no redirect happens

3) So I click OK again and then it gets redirected to Editform.


I think the problem is at thye step 2) that the getQS get the nameVal[1] based on the url  and it gets http://aurmsspdev/sites/luciano/devtest/Lists/Travel%20Request/NewFormCust.aspx?ID instead of the ID... for some reason when I click OK the second time the id is return ID = xx.

Anyways if you think I am doing anything wrong or have any ideas as to why this could happen let me know; if not, that's ok... I think I will find a workaround somehow.. it's almost there... :) 

Thanks again for your promptly responses !


Jan 11, 2010 at 9:25 PM

Not using the current user is a little dangerous becuase it's possible that someone else's commit may happen and you'll end up with their item.  However, it sounds like you are comfortable with that.

What changes have you made to the function(s)? It looks like the URLs you show above are what would be expected, except that I would expect to see an ampersand (&) before RealSource rather than %26.


Jan 11, 2010 at 9:42 PM

Hi M,

Yes I agree... it is dangerous, and I dont really like it...but I think chances that people will create New forms concurrently will not happen that often or will not happen at all (in this case)  I dont think have any other choice :)

yes, I dont know about the ampersand vs. & ... it is very weird.


I updated the SPGetLastITemId function removing the CAMLQuery that filters the author.

CAMLQuery: "<Query><OrderBy><FieldRef Name='Created_x0020_Date' Ascending='FALSE'/></OrderBy></Query>",


and in the RedirectWithID function, after the } else {  

I had to remove the RealSource because it was conflicting the EditForm (again... very weird stuff) 

var thisRedirectUrl = (typeof vals["RedirectURL"] == "string") ? vals["RedirectURL"] : opt.redirectUrl;

location.href = thisRedirectUrl + "?ID=" + lastID


So I think all is ok now... but this has been a good learning case for the current environment .

Thanks again for all your help


Jan 12, 2010 at 1:48 PM

Well, if you got it working for your situation, then that's the good thing.  Let me know if you need more help.


Jan 18, 2010 at 12:16 PM

Luciano, which versions of SPServices and jQuery are you using?

I seem to have the same problem of the item insert / redirecting not happening on the first submit.. and I've tried modifying all of the URLs (newAction, thisRedirectUrl, ..) but nothing seems to help.

sympmarc, do you have any ideas? Are you able to reproduce this bug(/feature :)?

Jan 18, 2010 at 3:01 PM


If you read through all of the above, it turned out that the root cause of  the issue was Forms Based Authentication (FBA) making the SPGetCurrentUser not work.  SharePoint's Web Services don't play well with FBA in general.  Any chance you are using FBA?


Jan 19, 2010 at 8:44 AM

Hi, thanks for replying.

I was thinking the "I had to remove the RealSource" had something to do with the solution and I was able to "solve" the problem by removing the RootFolder from the parameters of the NewForm page (by an ugly extra redirect).

Unfortunately (fortunately?) I am not using FBA.

The process of adding an item starting from the AllItems page goes something like this:

[Click on New]
User lands on: https://SHAREPOINT/Lists/LIST/NewForm.aspx?Source=https%3A%2F%2FSHAREPOINT%2FLists%2FLIST%2FAllItems%2Easpx&RootFolder=%2FLists%2FLIST&ContentTypeId=0xXXX
[Insert data and click OK]
User lands on: https://SHAREPOINT/Lists/LIST/NewForm.aspx?Source=https://SHAREPOINT/Lists/LIST/NewForm.aspx%3FID=PREVIOUS_ID
[Data is still there, but insert didn't happen. Click OK]
[Data is inserted]
User lands on: https://SHAREPOINT/Lists/LIST/NewForm.aspx?ID=PREVIOUS_ID
[Automatic redirect]
User ends up in: https://SHAREPOINT/Lists/LIST/DispForm.aspx?ID=NEW_ID

If I set the RootFolder to blank or remove it from the first page, the first submit works (submit, insert, redirect).

As a temporary fix I am redirecting the user if they open the NewForm page with the RootFolder parameter set. I redirect them to back to the NewForm page without the RootFolder...

Jan 19, 2010 at 1:42 PM

Hi lasseee ... good you found a workaround... ya you fortunate that you are not using fba... ;) 



Jan 19, 2010 at 2:33 PM


Sounds like it may be a bug in your case.  The only difference that I can spot in your example is the presence of the ContentTypeId Query String variable.  On the first click of OK, is the PREVIOUS_ID correct? i.e., does it show the ID for the last item previously saved by the current user?


Jan 20, 2010 at 11:21 AM

luciano, a workaround yes .. but I'm really not happy with it at all :/ I'm hoping to get it working properly before production use.


The PREVIOUS_ID is correct in both URLs.

The ContentTypeId parameter is not in the second URL because of the form action rewriting by SPRedirectWithID, but it doesn't seem to make a difference whether it is present or not. (Probably would make a difference if the List allowed for more than one ContentType?)

This doesn't make any sense..

Jan 20, 2010 at 12:36 PM

Can you post your full script block here? Maybe it's some little syntax thing.


Jan 21, 2010 at 10:25 AM

<script language="javascript" type="text/javascript" src=".../jquery.min.js"></script>
<script language="javascript" type="text/javascript" src=".../jquery.SPServices-0.4.7.js"></script>
<script language="javascript" type="text/javascript">
$(document).ready(function() {
redirectUrl: "DispForm.aspx" }); }); </script>

There's that, I'll probably look at this problem again tomorrow. Today didn't/won't have any time.

Oh and btw, I've tried with different versions of SPServices and jQuery (I think 1.4 didn't work at all, could have been a typo or something, didn't test too thoroughly).

Jan 21, 2010 at 12:36 PM

It's a pretty simple call, and I don't see anything that could be wrong with it. Oh, well, it was worth a glance.

BTW, jQuery 1.4 will *not* work due to a little bit of strictness I found. I've got it fixed on my working version, but take a look at this blog post if you're interested. Hopefully that will be the only issue I run across.


Jan 21, 2010 at 4:02 PM

Can you send me the View Source from the browser for me to take a look?  Maybe I'm not handling something.


Jan 27, 2010 at 1:57 PM

Thanks for sending the page code.  Could you try removing the ContentTypeId from the URL and see if that works?  That seems to be the one clear difference.



Mar 25, 2010 at 10:52 PM

Ok, good news (of sorts).  I can reproduce this in MOSS.  I'll be working on a fix.


Mar 28, 2010 at 5:43 AM

v0.5.4ALPHA1 posted which (hopefully) fixes the bug in SPRedirectWithID.

I'd appreciate any testing you could do.  Let me know whether it works for you.


Mar 28, 2010 at 6:07 PM

I'll certainly test the new version. I'm just not sure how soon I'll have time, but at least within the next couple weeks, hopefully before Friday.

Mar 28, 2010 at 6:10 PM

I'll probavbly have released it by then. ;+)

I'm about 98% sure that I've got the right fix in place, but I need to clean it up a bit.  If you do get a chance to try it, let me know regardless when it is.  sorry I didn't get it figured out sooner for you.

BTW, this looks to be an issue only with MOSS.  I'll document more about why in the Release Notes.


Mar 28, 2010 at 8:08 PM

I'll let you know how it works for me. Most likely you've found the same issue as I was expriencing since you were able to reproduce it in a MOSS environment. I might give it a try tomorrow, if I need a break from other projects.

Thanks again :)