I have been creating a website at work in SharePoint recently, that had the layout created by an external agency. So they provided the HTML, CSS, and js for a home page and a second level page. This of course makes my job easier for making the website, as a lot of the work has been done. However, good old SharePoint still likes you to spend a decent amount of time fixing things that you really shouldn’t need to. Basically, there is a lot of CSS courtesy of core15.css that will override the custom stuff at certain points. Sometimes this means you then have to make your selector more specific, sometimes it means you have to reset the selector to its initial state, and sometimes it means you have to work out what the user-agent would have applied and actually set a rule for that! A bit of a pain all around. But one thing in particular really had me stumped for a bit.
As you may know, SharePoint does this weird thing of disabling scrolling (i.e. no vertical scroll bar) and then works out the size of the window, resizes its container elements to that size, and then sticks the scroll bar back on. Obviously it does this, why wouldn’t you? Anyway, the layout I was trying to implement had a parallax background using stellar.js. This (of course) broke, as the container it was in was only the height of the window. So how do you fix this? Fortunately it can just be done with CSS. The first thing is to stop that stupid height setting from constantly happening:
Then, you will want to make sure you can actually scroll:
and finally, you will probably need to be able to see your background, so add this to that body style too:
After doing that, you should find that your parallax works, you see your background, and you don’t have that stupid resizing of the container elements ruining your life!
If you’ve ever used the OOTB publishing approval workflow, you will know that it’s pretty good and easy. But, if you’ve ever had some slightly niche requirements, then you may have had an absolute nightmare trying to figure out how to implement it!
If you want to do some customisation, like route the approval task to different groups for different items, then you will need to make a new workflow. So you can copy the OOTB one and add in a lookup of some kind to set the Approver field. Great, that was easy! Sure was easy, and that shouldn’t really affect anything should it? You give it a test and discover that approving your task didn’t affect the actual list item’s approval status. Huh. Oh well that makes sense, because you normally set that when creating the workflow…but that is on the site. There must be a setting in Designer. Oh. There isn’t. Never fear! We can add in some steps to the workflow to set it. Take that Designer, I have bested you! You test again and it works like a charm. But then you think, what if you just approve the item from within the list, rather than the task you have been assigned? You guessed it, it doesn’t stop the workflow. WHAT?! Argh!
Eventually, you land at the solution. I will have my custom workflow, but I will control it through event receivers. I will start it and end it, I will set the approval status, it will all happen through event receivers. That is kind of annoying to set up, let’s not kid ourselves, but unless someone else can shed some amazing insight onto this, that is the way to do it.
There is one other thing to note about custom workflows. They are necessary when you want to refer to a custom field in a list. So if you thought you could be clever and use the OOTB workflow and have a field on the item that is the Approver group to route to, then you are sadly mistaken. I haven’t tried it, but apparently you can limit a workflow to a content type and so could put the field you want in a content type and then have your list inherit that. In theory that should allow the OOTB workflow.
So here is a gotcha that was discovered at work in the last week…it appears that content types don’t just inherit, they also pass properties back up to their parents! Essentially, I had a content type that was being used for a list. The content type inherited from built-in property types, you know the deal Document from Item type thing. Anyway, there was a request to update the compulsory Title field in the list to be ‘Surname’ instead. Simple enough you would think. Well, it is and it isn’t. If you try to be a good little developer and think that you will update the content type because you might use it again and you will want it to be ‘Surname’ there too, well, you would be wrong. This is what was done, but then ‘Surname’ was popping up all over the place! It turns out that it had sent that edit of the field name back up it’s inheritance and sent them all through the site. The correct way to apply the change is on the List Settings for the specific list where you want to change the Title display name.
I work with Microsoft SharePoint and have come to know it as a system designed for end users first and developers can ‘work it out!’ That is probably a harsh criticism, I’m sure all developers get annoyed at certain elements of the technology they work with. This is one particular thing that came up and drove me insane until I discovered what was happening.
I was writing a CAML query that included passing in the Title of the page as a parameter, but kept getting no results despite being sure that the query was correct. I could see the fields in SharePoint that should return, but alas the empty set kept coming back. After too long searching I was able to finally find the truth. When adding a Term to the Term Store, if it includes an ampersand (&), SharePoint (in its infinite wisdom) decides to convert that to a wide ampersand (＆).
Given my CAML query was taking in a parameter dynamically that included an ampersand on some occasions, I needed to replace these whenever they arose. I had to write a little regex to alter my CAML query before it was executed to substitute in wide ampersands for any regular ampersands. This was essentially:
Regex rgx = new Regex("&");
string text = "My CAML query";
text = rgx.Replace(text, "\uff06");
I find it incredible that the approach taken is to adjust the ampersand in Term Store entries, but not elsewhere on SharePoint (basically begging for this issue to arise), so be aware of the devilish ways of Microsoft and in particular SharePoint!