I've built a large number of forms in SharePoint Online that have jQuery functions built around those fields internal names.

For some reason this morning the internal name of each and every field in my tenant has incremented. For example, a field name of

ctl00_tl33_g_653cd5e9_03e4_440e_b5ea_a78e5899feb6_ff51_ctl00_ctl00_BooleanField

Would now become:

ctl00_ctl34_g_653cd5e9_03e4_440e_b5ea_a78e5899feb6_ff51_ctl00_ctl00_BooleanField

Why on earth has this happened? Can I reasonably expect for this to not happen again and how can I go about getting answers around this issue without logs at my disposal as I believe SharePoint Online doesn't provide these except by support request for correlation events?

  • 2
    I don't think you can stop this from happening. This might have been changed with an update and i think this might happen again. Only thing you can do is give them a unique class name so that they don't change. – Akhoy Oct 26 '15 at 5:05
  • @Akhoy Unfortunately you can't give them a class name given how they're rendered. In the end I ended up encapsulating them in a div and targeting them from that div name. – Michael A Oct 26 '15 at 23:07
up vote 7 down vote accepted

That is not the internal field name of the SharePoint field, it is how ASP.NET (ASPX pages) gives IDs to the fields when it renders them. You should never rely on those as they keep changing based on other controls on the page. In this case MS has probably pushed an update that has brought in one additional control to the page, causing incremented ID to all controls redered after that.

Now I'm not sure what you're exactly doing, but there are few solutions which might help:

  1. Fix your jQuery so that you really look for the actual field. Depending on the field type, the HTML is obviously different, but there is always some node that contains ID that ends with the real SharePoint internal field name of the field. So you search it with $("div[id$='_InternalFieldName']"), which takes you close, and from there you can get to where you want to go by navigation to parents or childs, etc.
  2. Use ClientIDMode="Static" in the controls. I haven't tried this with SharePoint OOB controls, but works nicely in custom Web Parts at least. (Details)
  3. Use some other pointers in the HTML to get you where you need to go, e.g., class names, other IDs, etc.
  • Thanks! After implementing here are my notes for future readers: #1 looks like the best approach, updating to use this now. Although #2 looks viable I think that anybody replicating a form without background on this issue would likely reintroduce the problem if they missed that I had done this. #3 unfortunately isn't easy given how these fields are rendered (you can't give them custom classes) and you might as well go with approach #1 if you were to overcome this by wrapping it in a new div with a class of its own. – Michael A Oct 26 '15 at 23:16

Not sure how related this can be, but we have seen some SharePoint updates changing way internal fields are named and shown in final HTML output.

Here is a case where 'Required Field' is appended to internal display name of mandatory field.

http://code2care.org/2015/sharepoint-update-append-required-field-to-display-name-of-mandatory-columns/

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.