I encountered this problem in a WSS 3.0 environment. Hopefully this can help newer versions of SharePoint as well.
My customer has a old WSS 3.0 environment with a huge site collection. It’s a root-site with 200 sub sites with sub sites. This is a free for all SharePoint with no boundaries. Which makes the maintenance a pain in the ass.
Someone (with to high permissions) renamed the built in field “Title” to “DayReportDate” on the root-site and published it over all sites changing all content types that inherit from Object.. which is well, all. And users on sub sites discovered this pretty quickly and changed their child content types title field back to “Title”. This caused a huge problem since when trying to rename the root-site title field back to “Title”, SharePoint would say “The column name that you entered is already in use or reserved.” even if it’s just reserved on one of the sub sites.
Everyone panicked because their title field was changed to “DayReportDate” and more than 200 sites where affected by this mistake. Having this problem for 6 months they decided that someone with SharePoint experience should take a look at the problem so the case landed on my desk. Yippie!
A problem for me was that I had no server access, so I could not create a console application (or likewise) using the SharePoint server API to correct it. And since it was WSS 3.0 there would be no PowerShell either. So I simply had to fix it on the client side.
I found two solutions.
Links are meant to be broken, at least if you move files or change file names of documents in SharePoint.
I had a customer that required links not to be broken when file name was changed or a document was moved. They also wanted to be able to create links to a specific version, current version and latest major version. The idea was by using the document context menu, users would have the option to create these URL’s.
I wrote a post about creating URL handler for document URLs, this time we will focus on how we can reuse that URL handler to create dynamic and static URLs to documents and document-versions directly from the GUI.
Microsoft has implemented a great way to reach documents by the document id, but it seems that they didn’t fully implement it’s potential into SharePoint. Therefor I would like to show you how we implemented a useful way to reach document versions by using the document id.
This implementation requires the document id feature in SharePoint 2010 enabled. It can be found under Site Collection Features.
Creating the context menu feature
Adding a new option to the context menu is quite easy, it’s all XML. Just add a new Module to your project, I called mine CustomContextMenuActions. Then, by editing the Elements.xml, add a new CustomAction like this. By using the query-string IsDlg=1 we tell SharePoint to remove stuff from the master-page that isn’t relevant to the dialog.
Description="Create a dynamic or static document url"
It would create an action like this.
I wrote a post about adding the built in document id to the document file name. Now I will show you another way to use the built in document id when referring to the documents.
Lets say we are in a big project with several baselines . And every baseline requires it’s own version of a document, but the same document. It could be that new requirements have been added along the way or maybe the architecture has changed from one to another. This might cause the document name to change for some reason and that will break the link from a previous baseline.
What if you had a link that:
- Will never break as long as the document or version is not deleted.
- Can point to the current version.
- Can point to a specific version.
- Can point to the latest major version.
Lets say that link would look something like this
Latest version -> Dynamic
Specific version -> Static, kind of
Latest major version -> Dynamic
Microsoft has provided some great functions from the Office API that we can use when we search for the document via the document id.
Creating the application page – URL handler
First of we need to create an application page that can handle the query-strings from the URL. This can be done quite easy, just map the SharePoint layouts folder to you project (I also added a new folder called customapplicationpages) and add an Application Page. In our case I added a page called getdocbyid.aspx. We don’t have to create any markup for this application page, just code behind. So basically, what we need to do is capture the id and the version and find the right document and redirect to the URL. This is how I implemented it, note that the current version of a document is not a part of the document version history.
I love Twitter Bootstrap and it gets even better with LESS. The LESS version of Bootstrap gives you control over a variety of variables to change such as colors, font-sizes and grid-sizes. It also comes with lots of mixins like border-radius, transitions and gradients that you can reuse anywhere.
One thing that I been struggling with is how to keep the Bootstrap source code separated from the customizations I need. You don’t want to go in and make changes to the source since you are likely to update Bootstrap in the future. You want to be able to switch to a newer version with minimum changes.
Here is a step by step guide on how I’ve been settings up Bootstrap for my latest projects. It’s not only about overriding variables but keeping the same file structure of your customizations as the Bootstrap source making it easier to maintain and for other developers to understand.
This is no rocket science but while I was writing the blog post on “Remove a page or site from Google” it came to me that setting IP-restriction on a per file basis in IIS is not that straightforward and I thought I would do short post on how it’s done more in detail.
Ever had content crawled by Google which you didn’t intend to expose? Of course you have, you just don’t want to admit it
I recently had a client getting their entire staging environment indexed by Google all because someone wondered what the robots.txt file was and instead of asking they decided to delete it. So now hundreds of pages from the live environment had a duplicate from the staging environment showing up in the search result and exposing their staging site to the entire world. Now I’m all against exposing the stage server to the public web but since it’s what the client wanted, it’s what they got.
So, what to do in this case?