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

Office 365 update changes 'Display Name' on required fields- breaks cascades

Jan 23, 2014 at 7:00 PM
FYI - I had left my debug on.
User's were getting errors on there forms that a field could not be found by SPServices.
MSFT has changed the display name of required fields when it lands in the DOM. I had a cascade going from parentColumn 'Division' to childColumn 'SalesCenter' (both required fields) - working last week with the display names as 'Divison' and 'SalesCenter' ... now when the form renders in the DOM the display names are 'Division Required Field' and 'SalesCenter Required Field' - no indication in the UI that this is modified.

Hope this helps someone!
Jan 23, 2014 at 7:10 PM
Edited Jan 23, 2014 at 7:13 PM
That's very weird. Can you send me a snippet of the page source where you're seeing that?

Also, what version of SPServices and jQuery are you using?

Jan 23, 2014 at 7:16 PM
Crap. I can see it in one of my pages, too.
<select id="Region_59566f6f-1c3b-4efb-9b7b-6dbc35fe3b0a_$LookupField" title="Region Required Field">
Jan 23, 2014 at 7:44 PM
I was using 0.7.1a. In the process of fixing by breaks today I changed to 2013.02a. jQuery version 1.7.2

<select title="Division Required Field" id="Division_c3a682d5-d689-4a98-8987-22286c46c742_$LookupField>
Jan 23, 2014 at 7:44 PM
Edited Jan 23, 2014 at 7:47 PM
Keeps ya on your toes!
Jan 23, 2014 at 7:48 PM
I just did a blog post to warn people:
Blog Post: Office 365 Update Changes ‘Display Name’ on Required Fields

Thanks for bringing this to my attention!

Jan 23, 2014 at 8:26 PM

Can you go to /_vti_pvt/buildversion.cnf, to check your build version? I’m on:


Jan 23, 2014 at 8:58 PM
Marc //same as yours
Jan 24, 2014 at 2:03 AM
So your earlier blog post on this.
This type of thing will probably continue, which will be a challenge for you and some of the value added functions. Also, I wonder if the word 'required' is localized; so if the locale/language is Dutch, will that word be different?

How about maybe finding the input by ID instead? The value for it seems to start with the internal column name, have the type at the end of the ID string and although I have not checked, I wonder if that UID looking string is actually the List internal UID? If so, and we can validate this is the convention, you may have a good alternative that will probably survive future UI changes.

(Note: that change by MS was probably one to better support people with special needs - specially those that use screen readers. )


Paul T.

-- Sent from Mobile

Jan 24, 2014 at 2:43 PM
The only thing on the form that M$ can't change is the Display Name of the label of the <h3>. I initially thought of keying off of the ID, but what is stopping them from changing how that is automatically generated. As it stands right now, I only see using the label as a future-proof way of finding elements on SP Forms.

What do you guys think?

Jan 24, 2014 at 2:55 PM

Using the h3 element as a selector works as long as the form hasn't been customized too much. I prefer to use selectors that go straight to the elements themselves (or as close as possible) for wider compatibility.

BTW, I've talked to someone in the PG about this and they are looking into it. I'll post details as I get them on my blog post above.

Jan 24, 2014 at 3:03 PM
I'm starting to believe that too. Christophe on twitter also suggested that is a better approach. That will make the selection of input element a multi-step approach.

Marc: perhaps you should have a generic function to retrieve column controls. That will at least consolidate that activity down to one method that all other value-added utilities can use. I would also suggest caching a pointer (jQuery selection) to the control once it is found the first time - so you don't spend time looking for it again on subsequent calls.

Better yet: maybe we should all contribute some working code????? :-)

Paul T.

-- Sent from Mobile

Jan 24, 2014 at 3:19 PM
I’ve actually got just one line in all of SPServices to find selects like this. It’s in a constructor function called DropdownCtl. I use that constructor to find any type of “dropdown”, meaning a simple select, a “complex” select, or a multi-select. Due to the oddities in SharePoint forms across the versions, I long ago realized that I needed to handle those oddities centrally.

In fact, I’ve written before about how inconsistent the multi-select controls are in Variations in <a href="">Multiselect Controls in Different SharePoint Language Versions</a>. Because of these inconsistencies, I have special logic for Russian, German, and Italian, where the element naming is just different enough to be a problem.

If this recent change is intentional (which I'm hearing it may not have been), then I’ll update that function to handle it. I’m going to guess that it wasn’t intentional, though, because except for a tiny UX improvement – and even that is debatable – there’s no discernable purpose to the change that I can think of. The bigger problem is that it just happened, and there’s no way to see these changes coming.

BTW, the ‘ Required Field’ text only appears in the Title attribute in simple and complex dropdowns (not multi-selects) when the column is required. I have no idea what might appear in sites where other languages are used, but based on my findings with the multi-selects in the past, all bets are off.

Jan 24, 2014 at 3:41 PM
Edited Jan 24, 2014 at 3:42 PM
I'd like to put in a feature request:

Any value added function in SPServices should allow for a DOM/jQuery-ifed element to be passed in instead of just a Display Name. That would allow for our forms to be whatever we'd like and keep your DDL function from growing a whole lot more.

Would this be worth adding?

Jan 24, 2014 at 3:50 PM
Interesting idea. So, for instance, rather than this:
childColumn: "Region"
You might do:
var regionObj = $("select[title='Region']");
childColumn: regionObj
Jan 24, 2014 at 4:12 PM
Word. Or you could pass a regular element:
Then in your code you can check what was passed in: String/DOM Element/jQuery

Something like this should work:

Jan 24, 2014 at 4:19 PM
That could get messy, of course. I'll need to think about it.

I don't want to build in a lot of extra code to handle one off exceptions like this one if I can avoid it.

The current approach has been working for almost 5 years and three SharePoint versions!

Jan 24, 2014 at 5:38 PM
Edited Jan 24, 2014 at 5:42 PM
I also like this idea... It would make the utilities more robust and allow for more use cases... The challenge will be to determine if the input param is a jQuery selector or a DOM Element -vs- a column Title.

You are already dependent on jQuery, so anything passed in by the input param could be given to jQuery as a selector and it would handle it... jQuery accepts many types of selection types - including DOM elements...

The following could work:
var $ele = null;

// Is it a string? could be title or jQuery selector
if (typeof opt.childColumn === "string") {

    // Is it a column title?
    $ele = $("input[Title='" + opt.childColumn + "']");

    // If not, is it a jQuery Selector string?
    if (!$ele.length) {

        $ele = $(opt.childColumn);


// Else: not a string... must be an object which include DOM elements or jQuery selection objects.
} else {

    $ele = $(opt.childColumn);


// $ele should point to an element by this point.
This would handle setting the the childColumn as a Column title, jQuery selector string, jQuery Object and DOM element.

Feb 4, 2014 at 3:08 PM
Can any of you try the latest alpha?

It's not what you outline above, but it's got a fix for Office365.

If anyone here has seen this issue in the wild with SharePoint 2010 and can post the markup, I'd appreciate it.