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

SPServices - Differing Web Apps, Differing results

Feb 20, 2014 at 6:20 PM

I'm rebuilding some elements from our Dev environment (SP2013 on-prem) over on our Prod environment (same farm, different Web App). However, in the Prod environment I'm getting different behavior and errors. I've verified that the jquery and SPServices files are referenced correctly and are being read. I've also tried updating the SPServices to 2014.01 - but no change.

Here are the script web parts I'm using and their content:
Header Script
<script language="javascript" type="text/javascript" src="/Resources/jQuery/jquery-min.js"></script>
<script language="javascript" type="text/javascript" src="/Resources/jQuery/SPServices-min.js"></script>
Lookup Script - This script isn't working on Prod, does work on Dev
<script type="text/javascript" language="javascript">

 // Set up the cascade from CT to FA
//  listName: "Declared Items",
  relationshipList: "File Plan",
  relationshipListParentColumn: "FunctionalAreas",
  relationshipListChildColumn: "CTtext",
  relationshipListSortColumn: "CTtext",
  parentColumn: "FunctionalAreas",
  childColumn: "ContentTypes"
//  debug: true
Hide script - This script works correctly in Prod & Dev

jQuery(document).ready(function($) {
jQuery(document).ready(function($) {
jQuery(document).ready(function($) {
jQuery(document).ready(function($) {
jQuery(document).ready(function($) {
jQuery(document).ready(function($) {
jQuery(document).ready(function($) {

I'm also getting an error from the IE9 debugger. Error: Unable to get value of the property 'push': object is null or undefined
SPServices-min.js, line 21 character 30428


Feb 20, 2014 at 6:43 PM
The Hide Script stuff is just jQuery, so it wouldn't be affected by SPServices.

When you say that the Lookup Script doesn't work in prod, what errors do you see? Just the 'push' thing? Also, if debug: true, are you alerted at all?

I also notice that you have listName commented out. Do the lists in both environments have the same name?

Feb 20, 2014 at 7:14 PM

The push error is the only one I see. I have script debugging turned on for browser, so error dialog comes up with error (see previous).

The list names are the same, and I've adjusted the Prod version for slight differences in field names.

Here's the Script menu from debugger showing jQuery and SPServices loaded:
Feb 20, 2014 at 7:28 PM
Can you switch to the non-minified version of 2014.01 and let me know what line the error is on?

Feb 20, 2014 at 7:32 PM

It's Line: 1476


Feb 20, 2014 at 7:50 PM
It's got to be that one of these is incorrect:

parentColumn: "FunctionalAreas",
childColumn: "ContentTypes"

Feb 20, 2014 at 8:34 PM
Edited Feb 20, 2014 at 8:35 PM

Here are the details on the lists and the columns:

File Plan list
"Functional Areas" Field=FunctionalAreas
Multi-Lookup to FunctionalAreas/Functional Area column
"CTtext" Field=CTtext
Text column for the Content Types

Declared Items list
"Functional Areas" Field=FunctionalAreas
Single-Lookup to FunctionalAreas/Functional Area column
"Content Types" Field=ContentTypes
Single-Lookup to FilePlan/CTtext column

Here's a simple script I put on the page to see if any other SPS function would work. I've had this working on the Dev. I don't get the user's department back in the alert dialog - its blank.
<script type="text/javascript" language="javascript">
// Set usrFA to the current user's Department
  var usrFA = $().SPServices.SPGetCurrentUser({fieldName: "Department", debug: false});
  var idFA = "0";
Apr 16, 2014 at 8:02 PM

I've discovered that there appears to be a difference in the way SPServices functions behave (for user information) based on whether the MySites feature is enabled or not. I verified on my dev that with MySites enabled - the function above worked, but on the production system where MySites are diabled - it doesn't work. The user information is still available on the user's User Information page, but it appears that's not sufficient.

Do you have any idea if this would be a factor and would there be away to resolve it?

Apr 17, 2014 at 12:36 AM
Edited Apr 17, 2014 at 12:36 AM
The function should work regardless, but perhaps I'm missing something.

Basically, the function "scrapes" values from this page:
If you can reach that page, then you should get valid values back. Note the Force=True. This ensures that the userdisp.aspx page loads rather than the My Site information.

Apr 17, 2014 at 2:44 PM
Here's a thought to consider. How did you build the new list in the production environment?
  • Did you create it from scratch using the the development environment as a list
    • or -
  • did you save the dev list as a template, then copy the template to the prod environment and create a list from the new template?
If you used the latter method, your lookup fields will likely be jacked. I've run into this before. I saved a list that included lookup fields as a list template. When I created a new list (in the same site collection, different site) using the new template, all of the lookups were somewhat attempting to still reference the site from which the template came. When I put the list in design view and checked the properties of the lookup column, I could see that things weren't right. Bottom line was I had to delete all of the lookup columns in my prod site list and re-create them from scratch. Everything worked fine thereafter.

Apr 17, 2014 at 3:20 PM

Thanks for the insght on the templates. I've run into something similar when building some of the production system objects for reuse. Templates are a useless feature to have if they're not reliable. Fortunately I don't base any of my production system on the dev, but build from scratch.


Here's the page that is displayed when performing a click-thru on a users display name: "/sites/ecm/_layouts/15/userdisp.aspx"
However, what we found when debugging the following code, is that the userProfileProperties would not load. We verified the service was running. We also verfied that the proerties would load on a web app with MySites enabled.
<script type="text/javascript" src="/_layouts/15/sp.runtime.js"></script>
<script type="text/javascript" src="/_layouts/15/sp.js"></script>
<script type="text/javascript" src="/_layouts/15/SP.UserProfiles.js"></script>
<script type="text/javascript">

    var userProfileProperties;
    ExecuteOrDelayUntilScriptLoaded(init, "SP.UserProfiles.js");

    function init() {
        var context = SP.ClientContext.get_current();
        var peopleManager = new SP.UserProfiles.PeopleManager(context);
        userProfileProperties = peopleManager.getMyProperties();
            function() {
                var userName = userProfileProperties.get_userProfileProperties()["AccountName"];
                var departmentName = userProfileProperties.get_userProfileProperties()["Department"];
                alert(userName + ", " + departmentName);
            function() {
                alert('Request for user data failed.');
Apr 17, 2014 at 6:26 PM
User Profiles and the User Information List are two different data stores. Basically, the UIL is what you use in SharePoint Foundation. Every Site Collection has its own UIL which contains every user that has "touched" the Site Collection. If you have the User Profile service running, then you also have the User Profile store. You can enable the User Profile service separately from My Site, though the latter requires the former.

If the Site Collection doesn't have a healthy UIL, then there is something seriously wrong with it.

Apr 19, 2014 at 3:59 PM
Edited Apr 19, 2014 at 4:00 PM

I was finally able to get the SPGetCurrentUser working. After a couple of hours running line-by-line through the debugger, it occurred to me that it wasn't getting to the userdisp.aspx page. The webURL arguement is optional, and in this case I'm working from a single site collection - so it should have picked it up, but wasn't. As soon as I added the webURL arguement it worked.
var usrFA = $().SPServices.SPGetCurrentUser({webURL: "http://this.intranet.ofours", fieldName: "Department", debug: false});
I'll leave that for you to sort out.