SharePoint is used by 78% of Fortune 500 organisations around the world to store, organise, share and access information using any device. However, it’s not without its quirks. Some might say they are “features”, but as a developer sometimes I find myself scratching my head saying; “ummm…….right…..really?”. Here are my top 5 issues with SharePoint, primarily focused on SharePoint site development.
1. Rest API 5000 item limit
Well the default is actually 100 items, which you can work around using $top=5000. This is strange as “top” functions are traditionally about limiting result sets, not expanding them, but that’s just being petty. 5000 is the hard and fast limit. Now I realise that the limit is there to prevent someone from doing an excessive query accidentally that returns billions of items and then boom! But what if we need more than 5000? – which can easily be a valid use case. There are always work arounds. I’ve seen and used a couple, but generally it ends up being a recursive call to get what you need. Use such a method with care though if like everyone, you want it to be responsive. Here’s a stripped-down example. I took the limit down to 1000 per call, the requests go through quicker that way.
var url = _spPageContextInfo.webAbsoluteUrl + “/_api/web/lists/getbytitle(BigList)/items?$top=1000”;
$.ajax({
var items = items || [];
function GetItems(){
url: url,
method: “GET”,
headers: {
“Accept”: “application/json; odata=verbose”
},
success: function(data){
items = items.concat(data.d.results);
if (data.d.__next) {
url = data.d.__next;
GetItems();
}
}
});
}
2. Pagination in SharePoint
In SharePoint you can do paging, but not like everyone would expect. We’ve become accustomed to scrolling through pages of data, skipping ahead two or three pages to try our luck there instead. In SharePoint, you can’t. You can move forward, and you can move backward, but that’s it. Why? No idea. It’s like Microsoft implemented the paging functionality and simply forgot that people may want to skip pages. They added a $skip parameter, but it doesn’t seem to do anything. Microsoft’s answer is to the use the next field returned when passing a $top parameter. This is fine, but then why does it allow $skip when it has no functional impact. Furthermore, this then means we can only move forward/back, and we have no way of determining what page we are currently on.
This rant is based on the REST API, but it’s the same for CAML based queries using the SharePoint Server Object Model. This means, Microsoft had this problem years ago and migrated it into the new REST API. I can’t be alone in finding this a little frustrating, especially since site designers continually stick full pagination into their designs.
3. Internal site column names vs column display names
I’m sure every SharePoint developer has hit this one. In SharePoint if you create a site column and call it “MyColum”, then…. wait, that’s not how you spell column. I’ll just rename that to “MyColumn”….. that’s better. Right on with development. Two days later I’m working on an ajax call to get all items from my list where MyColumn=”Value”. For the life of me I couldn’t get it to work! I keep getting: “Unknown column ‘MyColumn’”. Going into the site column to check its name, your notice it says “Name = MyColumn”. So, what’s the problem? Turns out that SharePoint when creating the site column initially takes the supplied name and assigns it to both the Internal name and the display name. Changing it only updates the display name. Since the REST API works with the internal names, you must make sure you stick with the original names, else it won’t work. There are two work arounds for this:
- Delete the site column and re-create it with the right name (only if you don’t already have production data against it)
- Live with it
Here are some other things to bear in mind when working with internal column names:
- Special characters are replaced with Unicode, i.e. + becomes _x002b_. Probably best to stay away from special characters if you can. It’s just complicating matters
- Never create site columns direct from the list quick editor, stick to the list settings interface. Else the internal column names become randomised by SharePoint to prevent conflict with other site column names.
- Always create site columns first and then add them to your lists, don’t create them directly against your list. Promotes reuse and changes will propagate.
4. Forget the form tag
This one threw me when I first started developing SharePoint sites. Coming from a web development background, I use the form tag all over the place. It binds form elements together and simplifies unobtrusive validation. Want to use a FORM tag in SharePoint…. You can’t. Since SharePoint’s front end is built on Microsoft’s Web Forms, each page is automatically contained within a top-level FORM tag. You can’t have nested form tags and you can’t inject HTML outside of the existing FORM tag. So, no FORM tags. That leads to some pretty quirky validation on forms. It’s remarkable what people produce for validation when left to do it themselves. If you are accustomed to using libraries like jquery validate, etc. Then get unaccustomed if developing in SharePoint. I don’t think there is a library on the market for validation that doesn’t rely on the form tag.
5. Document versioning
SharePoint is great for storing documents, and even better we can assign meta data to those documents to enrich their purpose. But SharePoint’s built in versioning is a bit flaky when it comes to this process. I have built a few forms over the years that start with providing a document, then request a series of supporting data items from the user and finally a comment to assign to the document version. Clients regularly want to see the version information on these documents displayed directly in the site. This is fine and simple to retrieve from SharePoint’s API, but if you have attempted this yourself you would have noticed that uploading a document and assigning meta data pushes the document to version 2 straight off. Yeah go figure. The API provides a means for adding documents and a means for assigning meta data but not the means to do it in one go. This raises eyebrows with clients as from their perspective they have just performed a single process, filling in the form and clicking “Submit”. In the background it’s two processes. I’ve tried to get around it but it’s impossible as once the document is added it automatically checks it in. When assigning the meta data your need to check it out and then back in again to get your versioning comments in place. The first check in will have no comments. Bringing this back will show version 1 with no comments and version 2 with the supplied comments. Workaround? The best one I have seen is to ignore the numbering system provided by SharePoint and to create your own that only increments when there is a comment, hiding the versions with no comments. Which is a hack to say the least. Here is an example of performing a document upload and assigning meta data, this time using the SharePoint Server Object Model in C# for a bit of diversity.
using (var clientContext = spContext.CreateContextForSPHost()) {
if (clientContext != null) {
// get the document library
var documetList = clientContext.Web.Lists.GetByTitle(“MyDocuments”);
// create the file
var fileInfo = new FileCreationInformation {
Url = file.FileName,
Content = input,
Overwrite = false
};
// add the file
var fileObj = documetList.RootFolder.Files.Add(fileInfo);
// get the files list instance
var item = fileObj.ListItemAllFields;
// assign meta data
item[“Title”] = document.DocumentName;
item[“DocDescription”] = document.Description;
item[“DocType”] = document.DocumentType;
item[“DocCategories”] = document.Categories;
item[“DocRegions”] = document.RegionString;
// save it
item.Update();
// check it out so we can get the version comment in
fileObj.CheckOut();
// check it back in with the comments
fileObj.CheckIn(document.Versions.Comments, CheckinType.OverwriteCheckIn);
// bring the item back with Ids etc
clientContext.Load(item);
}
}
There are many other issues, but those are the five that I hit time and time again. When I first started, they had me scratching my head in disbelief. That said, SharePoint is a beast and generally a very good one. The REST API works beautifully in most use cases and is a triumph by Microsoft. So, don’t let my issues put you off. Think of these as more of a heads up so you don’t waste your time working it out like I did. Happy site development!
