Over the last couple of days the html markup of several of my customers completely separated Sharepoint online sites have changed slightly. For example the element with the id Suite_MainLink_ShellDocuments has changed to O365_MainLink_ShellDocuments, breaking my Jquery script! I can't see any other reason than that there has been an update to the Sharepoint Online services. But I can't find any notification about it anywhere. Shouldn't I be able to get some kind of notification about these kinds of updates? Has anyone else seen this?

  • Not a good question in the long run. Should be reformulated to deal with such updates in general. Commented Feb 5, 2014 at 6:23

4 Answers 4


Probably. And you won't get any notification, as it says in their terms of use. As someone supporting a customised solution you need to be aware of what can go wrong and plan it in your support agreement somehow.

Have a read of this blog post I wrote recently on the topic, with some good food for thought from Marc Anderson: http://omicron-llama.com/2014/01/29/supporting-office365-customisations/

  • Oh! That's tough. I guess I have to always take into account that things will break, and try to make the fall as smooth as possible. And then maybe develop a dashboard monitoring version changes on my customers sites. Thanks for the input!
    – sebastian
    Commented Jan 31, 2014 at 15:06

Another change you might face is that you won't find a field by it's title because for required fields they changed that value. This is finding was document by Mark Anderson too: Office 365 update changes display name on required field

A workaround can be found on my blog post: Safer request form fields using JQuery

Sad to hear that other ID fields are affected too by those changes.

  • That's even worse than changing the ID:s. Thanks for the links.
    – sebastian
    Commented Jan 31, 2014 at 15:08
  • 1
    I've released SPServices 2014.01 with fixes for these issues on 2014-02-19. Commented Feb 20, 2014 at 3:24

Interesting. If we look at one of the entire elements where this has occurred:

<a id="O365_MainLink_ShellDocuments" class="o365button o365cs-nav-navItem o365cs-nav-workloadLink o365cs-spo-topnavLink o365cs-topnavLink" role="menuitem" style="" aria-selected="false" aria-label="Go to SkyDrive Pro" aria-disabled="false" href="https://tenant.sharepoint.com/personal/marc_anderson_s…" title="Go to SkyDrive Pro">

we can see that there are classes with the o365cs prefix. This would seem to indicate that there are CSS class differences between Office365 and on premises. This will be a big barrier to migration from on premises to Office365, as much branding and/or functionality will break in testing.


This was really frustrating as we just rolled out our custom branding on Monday, then Tuesday night they pushed the update and broke our new enterprise menu that we injected into the O365 blue header bar.

It was a quick fix to just rename the ID's and Classes appropriately, but I woke up Tuesday morning to a slew of help desk requests and panic attacks from our users in Asia....bleh

For those paying attention, they originally pushed out the changes for some O365 tenants back around December 20th, then reverted them a day or 2 later. I was building our branding then, had to fix it to account for it, only to unfix it after they reverted.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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