Office 365 Update Changes ‘Display Name’ on Required Fields
Observant SPServices user GregRT noticed something on Office365 today that I figured couldn’t be true. He posted the following in the discussions on the SPServices Codeplex site:
FYI – I had left my debug on.
Users 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!
My first reaction was to question whether this could be right.
For years, we’ve been able to reliably select a regular dropdown (select) easily by using the column’s Title. The markup has looked something like this (depending on SharePoint version):
<select id="Region_59566f6f-1c3b-4efb-9b7b-6dbc35fe3b0a_$LookupField" title="Region">
so we could use a jQuery selector like this:
var regionSelect = $("select[Title='Region']");
However, GregT is right. In one of my demo sites on Office365, when I set a the Region column to required I’m seeing this markup instead:
<select id="Region_59566f6f-1c3b-4efb-9b7b-6dbc35fe3b0a_$LookupField" title="Region Required Field">
I expect this will be a problem not just for everyone using SPServices, but for many custom scripts as well.
Not only does this become a breaking change, it’s just plain bad practice.
If you run into this issue, a quick fix solution would be:
var regionSelect = $("select[Title='Region'], select[Title='Region Required Field']");
It’s not enough for your selector to look for a Title which *starts* with ‘Region’; you might have a column called ‘Region2’ or ‘Regions’ as well, so you’d get false positives.
I’ll see if I can find out any more details on why this may have happened and whether it’s permanent. Ugh.
[notice]2014-01-24 8pm EST – Based on info from Christophe below and several others, the issue seems to arise somewhere between vti_buildversion:SR|16.0.2308.1208 and vti_buildversion:SR|16.0.2510.1204. You can check your version by going to /_vti_pvt/buildversion.cnf in your Offic365 tenant. See: http://corypeters.net/2013/07/getting-the-product-version-for-sharepoint-online/[/notice]
[notice]2014-01-24 11pm EST – The PG reached out to me and they are investigating the issue. I’ll post more info as I get it.[/notice]
[notice]2014-01-31 9am EST – Based on the information I’ve gotten from the PG so far (not a lot), I’m going to assume this is a permanent change. The ostensible reason, as suggested by several people in the comments below, is to improve accessibility using screen readers. It’s hard to argue with that, but it’s still an unfortunate change.
I’ve also checked with a few people running non-English tenants, and the titles are localized, like so:
- Swedish: “Namn Obligatoriskt fält” or “Name Required Field”.
- Russion: “RegSelect Обязательное поле” or “RegSelect Required Field”
- etc.
I’ve also received reports (several below in the comments) that this issue is popping up with SharePoint 2010 after applying the December CU. More on that as I get further details.
Based on this, I’m getting a fix ready in the 2014.01 release and will try to get it out there shortly. Methinks it’s going to become a game of catch up from now on.
[/notice]
[notice]2014-02-03 12:40m EST – SPServices 2014.01ALPHA2 posted with a fix for the issue on Office365. As soon as I can get an example of how the issues arises in SharePoint 2010, I hope to have that fix as well. [/notice]
[notice]2014-02-19 SPServices 2014.01 released with fixes for every implication of these changes of which I am aware. If you’ve run into this issue, please upgrade!
[/notice]
Another quick fix solution would be to use wildcard selection. In case of the “Region” field you can also try:
var regionSelect = $(“select[Title^=’Region’]”) /* ^= is begins with */
All supported wildcards can be found: http://api.jquery.com/category/selectors/
Greetings
Stefan
Stefan:
Yes, as long as you’re sure you don’t have – nor will ever have – any columns with names that start with ‘Region’, like ‘Regions2’ or ‘Regions’, as I mention.
M.
I agree with Marc, I don’t see a wildcard as a safe practice here.
Sorry Mark you are right somehow I read over the last sentence. Even if you add an additional space won’t do the trick.
Why ind the world wold they do this? o.O
Marc, as soon as I saw your post I went to my Office 365 site. I didn’t see the behavior you are reporting, no “required field” in sight…
Christophe:
Since updates roll out in waves (which aren’t visible to any of us), we may not be on the same rev. If you go to /_vti_pvt/buildversion.cnf, you can check your build version. I’m on:
vti_encoding:SR|utf8-nl
vti_buildversion:SR|16.0.2510.1204
See: http://corypeters.net/2013/07/getting-the-product-version-for-sharepoint-online/
M.
Good point Marc. Mine is vti_buildversion:SR|16.0.2308.1208.
I’m getting this too all of a sudden. Christophe, afaik O365 works in a rolling update fashion – you might not have been updated yet. I’m currently at 16.0.0.2510.
Strange that Microsoft did this. You could run this beforehand (perhaps as part of your custom global JS file) rather than touching each existing, working selector.
$( “select[Title$=’ Required Field’]” ).each(function(){
$(this).attr(“Title”, $(this).split(” Required Field”)[0]);
});
Brandon:
Since they made this change, there’s always the possibility that they are using this new Title value somehow. If so, we might break that functionality. But your approach certainly works otherwise.
If this is a change that stays, I’ll probably use GetListItemChangesSinceToken, check whether the column is required, and then adapt my selector accordingly.
M.
Very true, Marc. But my feeling is that they put it in there for user experience purposes only…so that the user is shown it’s a required field when they hover.
Of course, there are other means as you mentioned–there always are with SharePoint, it seems.
Taking a dependency on a field that could change like Title seems like a bad idea to me. What if MS changed the spelling of a word or some other legitimate change?
Also wouldn’t the Title change if a different language was being used? Not 100% on this one, but that would break things too.
There’s actually a typo in the post, Marc meant title (the html attribute) not Title.
Chris:
I’d agree with you except for the fact that we’re talking about the title attribute of the select, which has *always* contained the DisplayName of the column. By adding the text ‘ Required Field’ only when the column is, well, required, it’s a poor practice and doesn’t even especially improve the user experience on the form.
If a different language was used, it would still be the DisplayName of the column, it would just be in that language. Region (en), Region (fr), Regija (hr), Región (es), etc. And it’s fully under user control.
Everyone who writes script in SharePoint forms to make them usable (and there are a *lot* of people doing this because the forms are pretty darn basic) will potentially be affected by this for no discernibly good reason.
M.
Marc, the translation issue would rather be with “Required Field” which will obviously change according to the language.
Not obviously at all. I could point you to a number of inconsistencies around things like this.
M.
oh right, what was I thinking…
My point it programmatically taking a dependency that is subject to change via a variety of scenarios (like a user changing the name via the UI) seems like a bad idea to me. The display name can change if the multilingual features of a site are used (you can have different names for the column in different languages), or if the user changes the name or if its a standard field and you switch the site language etc… the list goes on. Whatever it is, the better way to go would be to take a dependency on something that wont change. ever. Then your code will continue to work :)
Chris:
In my example, I’ve hard-wired the ‘Region’ string, yes, just to keep it simple. In fact, in SPServices my code is more generalized. Whomever is implementing the functions passes in DisplayNames of the columns they with which they want use a function. Unfortunately, the StaticName is even harder to use as it doesn’t show up in a predictable place in the DOM across versions.
Basically, there has never been decent wrapping of field controls in forms in any version of SharePoint to date. Because of the server-side development focus in the past, what ends up in the DOM is basically an afterthought. That afterthought thinking has got to change, as JavaScript is becoming a key piece of the SharePoint development toolkit.
On some level, we need to think of the DOM as part of the API and maintain a decent level of consistency. This is absolutely possible, as others do it daily on other platforms. Adding a new attribute rather than morphing an existing one would be the preferred method here. It’s just like any code; there has to be decent change management. If there were a decent client side API maintained by the PG to do things like disabling an input field, comparing two date column values, or filtering options in a dropdown (among a much longer list of things that people need to implement every day in SharePoint land) then we wouldn’t need to resort to the hocus pocus we do. Try selecting a set of radio buttons or checkboxes on a list form with jQuery in any sort of reasonable way some time; it’s a royal PITA.
M.
Marc,
I like the idea of adding new attributes. It seems like a better design choice would have been to embrace the HTML5 data-* attribute. This would have given us, as developers, a better way to harness fields. Additionally, they could add key information like the static name of the field so JavaScript could be more reliable. Then you are able to be less concerned about the user choosing to change the display name of the field.
This would allow you to change the selector to $(“[data-staticname=’Region’]”) — which is much more predictable!
+1, Chris – I was also thinking something like that – it would be great if the product could better support this kind of thing, especially if it could be more friendly to the current major frameworks in some way.
If and when the forms are truly overhauled (they’ve change little from SharePoint 2007 to 2013), I would hope they would take a client-first approach rather than a server-first approach. This is the way the SharePoint world is going and Microsoft needs to treat the DOM like an API.
M.
Marc, re decent client side API: isn’t it what Client Side Rendering is pushing (JS Link in the form settings)? Just asking, I haven’t tried myself as for my solutions I need compatibility with SP 2007/ SP 2010.
I agree :) To make client dev a 1st class citizen developers need a rock solid way to do this stuff. Adding an attribute that was known and programatically dependable would be what i would be asking for.
Chris, I apologize for my earlier comment, I thought you were referring to the issue uncovered today, not the method itself.
The web has been lately, and will keep doing so, move in a more customizable client-side experience. All the presentation frameworks (AngularJS, Durandal, etc) are building off this concept and are all the rage. Microsoft clearly wants our code off the server (and I buy into that). But if that’s the case, MSFT have to establish a contract with us & stand by it. Changing something in the DOM such as this is akin to changing a server-side OM method returning an enumeration instead of a Boolean. Moving code off the server is not just CSOM, JSOM & REST… it’s also the UX.
Totally agree there needs to be a contract in the client side stuff. My point is the title attribute isn’t that contract that we need. The value of it changes for a bunch of reasons. A nice data attribute or something like that would be the way to go IMHO.
Chris:
I’d ABSOLUTELY prefer that there was a real contract here, but there never has been. I’d design it if I thought anyone would implement it. Using HTML5 data attributes would be the way to go:
* data-static-name
* data-required
etc.
The controls are all over the place the way they are built. Some have titles attributes that are reliable (or were until this), some have reliable ids (and others don’t), some are script driven and others are not, etc. Those of us who have been doing this work for the last 7-8 years have tried and true methods that work, but with no guarantees. If I could switch to more reliable methods, I would.
Keep in mind that for a library like SPServices, though, I’m trying to maintain compatibility with three SharePoint versions now. Six if you factor in the differences between Foundation and Service (and the other incarnations of those names).
M.
Totally agree here. When I read this post yesterday, my thought was the same as CJ’s in that hooking on to Title is not a good idea when there is an ID attribute that could be hooked into too that also shouldn’t change. Although the GUIDs are nasty and not as efficient to select them in JavaScript.
I can see why Microsoft have changed the Title attribute to have “Required Field”. I’m guessing its steps into the accessibility and screen reader worlds to make the forms more useable.
To AC’s point, I’m not sure Microsoft have encouraged developers to move away from Server Side development to Client Side development that encourages hacking at SharePoint pages and expecting the DOM not to change. The nature of Service Side development encouraged this even further with access directly to the pages on the web server, which obviously Office 365 developers can’t get at.
I think Microsoft are encouraging building Apps and presenting them in App Parts and Full Immersive Pages. Hacking at out of the box forms via DOM magic etc. is always going to be a brittle experience, its just that we’ve all got away with it for so long due to update cycles and little change to date in the DOM ;-)
Jeremy:
I’m in agreement with you and Chris in principle, of course. If there was a right way to do it, I’d be doing it. Even the ids are very inconsistent in the forms. Each field type follows its own convention and they are all different. It’s a little better in 2013, but not good enough.
M.
There has always been a way to get the Static Name for a column in the form. There’s an HTML comment in the DOM that gives you all sorts of information about what’s there, including the Display Name. However relying on that HTML comment to *always* be there is like *always* relying on the title attribute. You just never know if it’ll change.
Jeremy, hacks are the result of Microsoft not applying best practices, and not even following HTML specifications (cf. for example accessibility for forms, or non unique ids in a page). Interacting with the DOM is a standard practice, and other, non-Microsoft Web applications offer rock solid ways to do it. Check out AngularJS for example ;-)
Interacting with the DOM isnt what we are talking about. That is all good … go for it. Just dont expect to be able to use title attributes as a key into the DOM.
Chris, the first step for interacting with the DOM is to grab the correct element(s). Using title is not an expectation, it’s a fallback ibecause SharePoint forms don’t follow standard accessibility practices.
Jeremy-
I don’t agree that interacting with the DOM = hacking away at the UX. It’s classic interaction with the UI. If we think otherwise, we should just disable JavaScript across the board – said no one ever. :)
So the question really is, “Do MS consider the DOM an API?” If so then i think its reasonable they wouldnt change the DOM that would break things. If they don’t (which i think is probably the case) then i think its fair game they change things. Other services break their DOM all the time. Greasemoney scripts and chome addins need to be updated because of this regularly. e.g. Buffer.
I see a bunch of comments suggesting the use of data- attributes, and I strongly disagree with that. No need to reinvent the wheel, there are already existing accessibility specs on labels and ARIA attributes, Microsoft just needs to follow them!
The strange thing is that I’m seeing this same behaviour on an on-premise Sharepoint 2010 installation. Did anyone else notice this?
That’s odd, Erik. What version are you on? What was the latest CU you’ve applied?
Can we move this over to the SPServices discussions in a new thread?
M.
I’m not an admin, just a (front-end) developer, so I don’t know the latest CU.
Thanks, Erik. Funny that you two Eriks posted basically the same info within four minutes of each other. I assumed it was the same Erik just wanting to make sure I got the point!
M.