Redirect in SharePoint Using Meta vs JavaScript
This morning I was working on a custom list item display form for a “Tags” list that I created in SharePoint (DispFormCustom.aspx
). I replaced the standard display form web part with a data view web part (DVWP). For various reasons that I won’t bother explaining in this post, I needed to create a redirect on this page that included an additional tags
parameter in the query string with the @Title
of the current list item. For example, if a list item has an ID of “1” and a title of “jquery,” I want the page to redirect from http://server/lists/tags/dispformcustom.aspx?ID=1
to http://server/lists/tags/dispformcustom.aspx?ID=1&tags=jquery
.
I didn’t want to use <meta http-equiv="refresh" content="0;url=/{@FileDirRef}/dispformcustom.aspx?ID={@ID}&tags={@Title}" />
because it creates a history entry in the browser. If the user clicks the button from the new page, they’ll go back to the page with the redirect and be immediately redirected to the page they were just on. This is bad for the UX. I could extend the time from 0 seconds to 3 seconds or more to give the user more time to click the button again, but I don’t think this is a good UX either. I want the redirect to be as transparent as possible.
My other option is to use JavaScript. I’ve used window.location.href()
, which works basically the same as window.location.assign()
, more times than I can remember to navigate to other pages as part of a function, but this leaves an entry in the browser’s history (most of the time this is a good thing). So instead I used window.location.replace()
to redirect the user. This method does not create a history entry in the browser, which allows users to click the button without being caught in a redirect loop.
The code I used in the DVWP is pretty straightforward. It checks to see if the tags
parameter in the URL query string has a value (I created the $Tags
parameter for the DVWP using the Common Data View Tasks menu; it uses the value of the tags
parameter from the URL query string). If the $Tags
parameter is blank, the page redirects to itself with the @Title
of the list item populated in the $Tags
parameter.
<xsl:if test="$Tags = ''"> <xsl:variable name="RedirectURL" select="concat('/', @FileDirRef, '/DispFormCustom.aspx?ID=', @ID, '&tags=', ddwrt:UrlEncode(@Title))" /> <script type="text/javascript"> window.location.replace('<xsl:value-of select="$RedirectURL" />'); </script> </xsl:if>
The user sees the original page start to load for a second, but then the JavaScript runs and the page is redirected to the new URL. If the user clicks the
button, they are taken to the page before the redirect, thus avoiding the annoying redirect loop.Although I’m using this conditionally in a DVWP and generating the redirect URL dynamically, you can use this method on any page using a static URL (via a Content Editor Web Part, for example). Just use window.location.replace('http://your-url-goes-here');
.
Method | Creates a history entry? |
---|---|
<meta http-equiv="refresh" content="0;url=http://your-url-goes-here" /> |
Yes |
<script type="text/javascript">window.location.href('http://your-url-goes-here');</script> |
Yes |
<script type="text/javascript">window.location.assign('http://your-url-goes-here');</script> |
Yes |
<script type="text/javascript">window.location.replace('http://your-url-goes-here');</script> |
No |
This is a simple and effective way to redirect users. I generally try to avoid page redirects altogether, but in this instance I didn’t have time to create a more elegant solution, and this did the trick just fine.
Update 2013-12-11: I created a simple JavaScript snippet that can be used in a Content Editor Web Part to redirect a SharePoint 2007 page if not in edit mode. To force edit mode, add ?Mode=Edit
to the end of the page URL.
Comments
Comments are closed