As it turns out, customizing a Wiki Library to do anything isn’t just difficult, it’s not even a chore. It’s a goddamn mission of epically frustrating scale. Let’s start off with some over-all items:

1. I needed to create custom columns, some of which looked at lists.
2. I needed to create a content type that was based off of the Wiki content type.
3. I needed to customize the Wiki library to have said content type.
4. I needed to add custom-made web parts to the various views of the Wiki Library (History, Edit, etc)
5. I needed all of this to work through a feature

Where to start? Lets start from the bottom of the list, because as it turns out this was the easiest and where I started.

You want to edit those page layouts eh? Well have fun because as it turns out all of those files are system files, which means they’re on the hard-drive of the server and therefor shared. That means you can’t mess with one without causing a server-wide change. The solution? Copy those layout pages and rename them. Now add them to your feature. I’m not going to explain how to get the feature to deploy, that’s a different story all together.

That’s sweet! Now how do you make anything use those pages? Well in terms of all the little widgets (Versions tool, History Link, Incoming Link) You will have to build your own versions of those controls. Why? Well the URL of the pages that they point to are hard-coded. Simple enough to get around, though annoying as hell. Just to demonstrate, to the left is a screen shot of what SharePoints’ markup looks like just to recreate some of the controls in HTML. Seriously, that’s messed up. In the end each link was surrounded by two more tables. What the hell man?

Okay so you got all of the default pages redirected. What about when you edit an entry or make a new one? Those pages are tailored specifically for Wiki Pages (CreateWebPage.aspx) and so you’ll have to copy that one. As for redirecting it? Well you should be able to do it via an Event Receiver attached to the Feature that Installs the custom content type that this is all based from. please note my use of the word ‘should’ because I’m still stuck there.

Let’s move onto the library for a moment. Now I have not been able to replicate the Wiki library properly, without making my list type use the basetype of ’119′. As it turns out, this comes with a whole bunch of strings attached, like having hidden name columns and a lot of red-tape. I dare you to try and rename the “Name” column to anything with any sort of graceful code. I’ll leave that one there. For those that are wondering, the default Feature for Wiki Libraries is called “WebPageLib” or something of that nature. Try searching the 12 directory for the content type of Wikis. To find that, go looking for the ctypes Feature and look in there.

Creating the feature to house all of this turned out to be the easiest portion of it all, though all of the problems stemmed from it in some shape, way or form. I can’t bitch too much about the feature markup itself, because all it really lacks is some functionality that should… well really should just be there. I’ve had to rig extra code together just to get what I wanted, but read on and I’ll explain.

I managed to create the content type with little issues, though I had to add Remove references to the WikiPage content type (that does exist by the way, it’s just stored in the ‘_Hidden’ group which is why you can’t touch it via the site). Adding the new content type to the list template was fun too, because you have to do it via the feature, since Wiki libraries do not allow you to edit the Content Types of the list at all. Like I said, Wikis are sealed, and don’t like to play with the other kids.

The problems really started when I created the site columns. Just a note to everyone: if you ever feel like creating columns or content types, then using them, and then trying to remove them via a feature, good luck. SharePoint will not remove anything if it’s being used. Just a helpful tip there. This could be fixed via some EventReceiver code, but I won’t get into that.

Anyways, I had a column. It was a lookup column. It wanted to look at a specific list, so I gave it the list id (though to be honest this is a bad way to do it because what happens when you want to deploy this feature somewhere else?). I deployed the column, and it worked! Then I tried to use that column in a sub-site, which ended up failing miserably. Took me forever to find out that you cannot specify a web property in the feature. webid and scopeid, yes, but nothing generic (refer to my listId comment here). The solution to this was to add more custom EventReceiver code that would do this work for me. Which worked great until I moved the feature to another site.

This is where my night went bollocks.

I installed the feature onto another dev-site and activated it (all through stsadm). Worked fine. Then I tried to deactivate said feature, and it would just sit there. I could uninstall it fine, but when I deactivated it the process would just hang there and I’d be forced to end it via Task Manager. It took me 6 ruined dev-sites to realize that I was missing the lists that my lookups were pointing to. Apparently if you tie a lookup column to a list that doesn’t exist via code, it will cripple the server when you try and remove that column from any content types that it was attached to. When I say cripple, I’m not kidding. stsadm.exe ran up 50 Mb of resident memory, and 100% of the CPU. The best part was that no error would be logged, it would just hang there forever. I admit I toyed with the idea of letting it run all night and going home.

I kid you not, I laughed like a madman when I finally figured it out. I cannot explain why, but that’s just how it is. The lesson I learned from this really was that I shouldn’t have expected SharePoint to have any sort of intelligence sitting behind it, and code for stupidity. Anything you think SharePoint should probably just do probably doesn’t actually happen, or it happens with a hope and some duct tape.

Oh and for the record, I’m still stuck on how to change the Edit/New pages properly.

To be honest: it’s a pain. There is no way around that. I’ve had moments in my still-new career where I’ve wanted to put my fist through the screen in frustration from applying a brand to the system. Now all that aside – I’m getting worked up here – It doesn’t have to be a nightmare. There are ways to cascade changes throughout a site without sacrificing a lamb. This is of course assuming you don’t have to also brand the administrative side of the whole deal. The reason for this is fairly simple: SharePoint’s administrative templates are powered from the file system, and not through their ghosting system.

I’m going to take a moment to clarify “Ghosting”. SharePoint operates on a template basis. That means that when you use what is given by SharePoint, it all points to the same file. The second you go and customize that file, a new copy is created in the database, and so the original is left in tact. This is called ghosting. Whenever you customize a page, you are effectively “unghosting” the page. That is to say that you are no longer living from the predefined, but making your own file in the database. This is a great idea which can help save on server memory (Hard disk-wise) and I totally agree with it.

So why the hell did Microsoft decide that all the administrative pages be fueled by a totally different system? They do indeed say it was purposely designed that way, but I call bull on that. What it sounds like to me is that they either ran out of time, or had the front-end team and the back-end team kept in different buildings, and told never to talk to one another under pain of death. As a result, when you decide you want to brand anything in the back end, you have three options:

1. Stick to manipulating the CSS. I wont get into the agony of explaining this in detail simply because it would take too long. The short of it is that the CORE.CSS that SharePoint uses is over 4000 lines by itself. Never mind the other eight they have for special instances. On top of that, you are limited to all the elements that are on the page. This is severely limiting and at the very least, painful. Finding what classes do what can be akin to pulling teeth out with a 9 iron.
2. Make a theme. I hate themes with a passion. They were obviously tacked on as an afterthought and it shows. Who’s the genius that figured that resetting the server in order for any changes you made to the core theme folder to appear in your applications. further more, why in Gods name would you copy the files to the local site instead of referencing them? That means that if there was a critical error in your theme and you’ve already applied it to 60 sites, you now have to go into each of those sites and apply the default again and then apply the now-fixed theme. I hope whoever did that was fired.
3. Change the file-system items. The short of this: Don’t. You can do that, you really can but I will guarantee that this will eventually end in heartbreak. What happens when the updates roll out – and you know they will- and overwrite your hard work? Now you have to go back and re-work everything on the page. God only knows what’s changed. This is the minor half of the problem though.

The only viable option is the first one. It sucks on levels all unto itself, however since the second sucks when your site has more then one sub-site is even worse, and the third option generally leads to tears and wasted hours (been there, done that) it’s still the best option in the end.

“But Corey! Surely editing the system files allows for the most customization and look/feel!” Absolutely right, and I won’t argue that point. I will argue that I’ll advocate against it whenever possible though. Here’s why:

The big problem is that since you are editing file-system items, they’re shared. That’s right. If you have two totally unique site hosted on the same box, you’re going to notice that one of them is going to the administrative look of the other site. This could be manageable if only administrators saw it. The odds of this are that at some point you are going to go into a list. the master page for viewing all lists is one of those shared items. It’s the same one used for branding administrative panels. See where I’m going with this? Heck, even if its just a collaboration site, that will still come up.

Cameron shows off the website “Hawaiian Airlines” which is a pretty nice site. Simple, to the point, and gets the job done. It’s also had every page customized (it appears to be that way to me, I could be wrong), and custom parts have obviously played a rather large part of the site. I’m not bashing it in any way here, so please don’t misunderstand. What I’m saying is there was a lot of care put into making that site look the way it does, and I can only pray that they didn’t brand the back-end with the same zeal as they did the front. If they did, i weep at their commitment.

What I’m getting at here is that though there are many ways to brand SharePoint, none of them are painless. The best route is trying to convince your client/boss/whoever is paying for the endeavor not to bother branding the back-end. This is a rare treat and you really shouldn’t go expecting it. Failing that, I suggest going with option 1. It’s a pain in the ass but it’s the easiest in the long run. You can also ease the pain by using tools like Firebug and the IE Development Toolbar. If you have to go beyond that (which I have had to do in the past, and I am certain I will be doing so in the future as well) then I wish you luck. You’ll need it.

The last point I’ll touch on is something Mr. Moll covers in the last paragraph. The user experience in Vanilla MOSS 2007 is depressing sometimes. Limitations for no real reason, way too much user effort for minimal gain, and don’t get me started on the many, many useless steps to achieve certain things. Welcome to the other half of my job. I won’t get into this part too much, but despite my boss wanting us to stay away from customization wherever possible, I’ve noticed that to really take advantage of what SharePoint’s core ability can do… well you need to be there to customize a solution to access the power. Don’t get me wrong, SharePoint can do a lot of things, but as I have experienced in the past it generally makes the development team work- and work hard- for it.

And that’s my two cents on it.I like my job, I really do. I’ve learned what I deem to be ‘snoot loads’ but it’s been a hard way getting here. I’m glad for it, but seriously: fist through the screen frustrated sometimes. Good luck people.