There is a minor style bug in SharePoint 2013 (including SharePoint Online). The error message on a required DateTime field is not displayed in a manner consistent with other control validation errors. No it’s not just you, and no it’s not due to some conflicting CSS – it is a SharePoint bug.
Specifically I am referring to the page layout edit experience. A user fails to provide a value for a required DateTimeField control and the validation message is shown in the default text colour – ‘You must specify a value for this required field.’
For all other validation messages the SharePoint controls add the ms-formvalidation which sets a CSS rule to set the red colour. This is the only rule which the ms-formvalidation class sets and as such this is the only rule that should be applied to fix the issue.
I use the following CSS selector to resolve this issue:
I recently had some trouble trying to update a user’s profile properties via the SharePoint Online Admin console. I would provide values for the fields but when I pressed the save button either the page would refresh, with no validation messages, or I would be redirected as if the save had persisted. However, upon revisiting the user’s profile properties page it was clear that my changes had been discarded.
I was chasing a red herring for a while with the assumption that this issue was related the Kiosk licence of the user I was attempting to update. The issue is not related to licence type but appears to be a validation bug with page.
Although I had provided values for the user profile properties which are marked with a star, the issue persisted. These properties are not required when updated the user profile from the Admin console. The issue in fact lies with the time zone settings.
I found that I could not persist update if the ‘Always use regional settings defined by site administrators‘ radio box was checked.
By changing this to ‘Always use my personal settings‘ I was then able save and persist updates to the user’s profile.
If you have customised the new button order and/or default content type for a list or library, then expect these changes to be lost if that site is moved. SharePoint Bug! You may have done this in order to change the content types that appear under a list’s new button or change the content type that used by default (i.e. when a user just clicks the new document icon rather than selecting a content type from the drop down).
A library with a restricted set of content types
As you can see in the image above, I have a library configured with a restricted set of content types available under the new button. After moving the site (using Site Settings > Content and Structure) these customisations are lost. See the next image.
The same library having been moved to a new location
So that’s the issue but what can you do to fix the situation if moving sites is something that you need to support regularly? Firstly, this isn’t the only issue you may encounter.
With the luxury of a farm solution this can fixed using a web event receiver. Using the WebMoving event you can store list new button order information (e.g. in a web property bag) and then in the WebMoved event, this information can be read and applied. I don’t have a code example of this as in my situation it was suitable to apply a static new button order to lists based on the site definition and list template.
If you are unable to deploy a farm solution (e.g. SharePoint Online) then this issue is more difficult to solve. I assume that you can write remote event receivers for web events and apply the same logic as above (I haven’t tried this). Otherwise I can’t think of another reasonable solution beyond writing a control with client JavaScript that ensures the new button order upon viewing the page. However this would require knowledge of what the new button order needs to be, and hence would be more complex to implement if users are free to change it.
