Sharepoint 2007 Customization Ramp Up – Part 2: Initial Concepts

In Part 2 of this series I wanted to cover some of the initial concepts involved in customizing SharePoint 2007. I will try to cover a few of the highest level ideas that you need to understand through some descriptions and links to some of the blog posts that cover the concepts in more detail.

Initial Concepts:

  • Wss vs. Moss
  • 2003 vs. 2007
  • Publishing Site vs. Team Site
  • Site Collections vs. Sites
  • Using SharePoint Designer
  • Ghosting and UnGhosting
  • The 12 Hive

 

Wss vs. Moss
An obvious first place to start, is the differences between Windows SharePoint Service Version 3 (WSS V3) and Microsoft Office SharePoint Server 2007 (Moss 2007). I’m not sure what team at Microsoft is involved with coming up with the official names of their products, but I’m quite certain they need to be disbanded and reinvented. No marketing company in their right mind would name these products so similarly. To put it quite simply WSS is the free framework that runs the underlying objects that make up “SharePoint”. MOSS is a commercial enterprise collaboration and portal application that runs on top of this WSS framework. If you were so inclined you could take the absolutely free WSS underpinnings and build your own content management or portal solution… but before doing so, you should investigate everything that the MOSS product brings to the table (along with its price). Also note that the old product known as Microsoft Content Management Server has been rolled into MOSS 2007. This is sometimes referred to as ECM (Enterprise Content Management) or WCM (Web Content Management).

 

Note: For this series I am focusing on the actual MOSS 2007 product.

2003 vs. 2007
When we started this project my team had no experience with SharePoint 2003 or WSS V2 so we weren’t concerned with the differences with the old products. That being said, I’m sure some of you would like to know what’s different in the new stuff. From what I can tell from a customization standpoint A LOT has changed for the better.

 

Publishing Site vs. Team Site
When you first start using SharePoint you most likely will first have a SharePoint Team Site. This is a template that enables various Features of SharePoint that are intended for team collaboration. If you are like me, this is not an appropriate setup for a public facing internet site. For this, you should be using the Publishing Site template. Here is some verbiage from Microsoft regarding some differences:

Publishing Site
Select this site template if you want to create a blank Web site and quickly publish Web pages. This template includes document and image libraries for storing Web publishing assets. Contributors can work on draft versions of pages and publish them to make them visible to readers. The site includes document and image libraries for storing Web publishing assets.

Team Site
Select this site template when you want to create a site that teams can use to create, organize, and share information. The template includes a document library, an announcements list, a calendar, a contacts list, and a links list.

One last word of warning on the topic of templates: Many times you will find articles that describe how to do things specifically (sometimes xml examples or clicks you need to make in the administrator) that are based on a Team Site. If you are running a Publishing Site (like me), these instructions may not be 100% the same. If something is not working exactly as described, make sure the author isn’t describing a Team Site.

Site Collections vs. Sites
Once you get going with SharePoint you will quickly want to know the difference between creating a Site Collection and a Site. In case you were wondering, this is another area I think Microsoft dropped the ball with their naming. Site Collections can be thought of as root level web applications, while Sites can be thought of as sections of a Site Collection. I have found that the decision of how many Site Collections versus how many Sites you should have, is one of great thought and debate. To understand how to make this decision you should consider some of the pro’s and con’s between the two. The following links go into some specifics, but to put it simply, you get a certain amount of separation when you use site collections which may be valuable from an organization, security, or design point of view… but you also add significant complexity from a management and administrative point of view. I think the bottom line is you will need a few Site Collections and many Sites in most large sized department based internet facing sites.

 

Using SharePoint Designer
Once you get started actually customizing SharePoint applications you will want to check out what SharePoint Designer brings to the table. It’s worth mentioning at this point that SharePoint Designer (based on Microsoft Expression Web) is basically FrontPage 2007… though I think they made a good call by not naming it this, as it’s really come a long, long, way. In my book, nothing is faster at customizing the look and feel in SharePoint, than using SharePoint Designer. A quick warning here, you need to be very careful of SharePoint Designer unghosting your files (more on that in a bit). To start using SharePoint Designer you need only install it on a computer that has rights to the SharePoint Server on the network. From there you select “File | Open Site” and enter the complete url of the SharePoint Server (including the port and subdirectories in the case of specific Sites and Site Collections). If you have appropriate access it will open a view of the SharePoint server that can be very confusing at first. One way I think of this view is, as what the webserver sees when SharePoint merges its content database and the various IIS virtual and physical directories together (in reality I’m sure it does something different than this). One thing is for sure, what you are looking at ma
y or may not exist in various physical directories on your server or in the SharePoint content database. Go ahead and click around and check out some of the source code… but be careful, I have seen times when the “undo” feature does not actually undo your changes. As you make changes you should be able to see your results by refreshing your browser’s view of the SharePoint Site.

 

Ghosting vs. UnGhosting
I made reference to this warning in the previous section. This concept can be confusing and hard to remember, another case of poor naming conventions (though I’ve heard that Microsoft has changed this term to Customized and Un-Customized… even though I see references throughout the web to the concept of ghosting and unghosting). In basic terms a ghosted file exists on the physical file system of your SharePoint site, typically in the 12 Hive (more on that later). On the flip side unghosted files have been customized (typically with SharePoint Designer) and as such, SharePoint stores them not on the file system, but instead in the content database. To the end user (and maybe even you the developer, thanks to how SharePoint Designer shows things) this may not be readily obvious as SharePoint takes care of displaying the file whether it’s in the content database or the file system seamlessly. The downside to this is two fold, firstly unghosted pages may have a performance impact and secondly you may have issues propagating your custom design throughout Sites and Site Collections if they are unghosted. The way I get around this is I proof all of my changes via SharePoint Designer and then when I like what I see, I have my customizations turned into Site Definitions or Features (more on that in another part of this series).

 

The 12 Hive
I promised earlier a little more information on the 12 Hive. This is an important location in SharePoint land and in fact it’s the location on your server where SharePoint stores most of the physical files and configurations that it uses. It’s typically located at “C:\Program Files\Common Files\Microsoft Shared\web server extensions\12” on your server. Many people make a shortcut to this on their server quick launch desktop toolbar so they don’t have to remember it. At this point, unless you know what you are doing I don’t recommend messing with the files in this directory. For now though, check them out and see how they are setup. I will get into actually changing the files in a future part of the series.

 

Well, I think that might be enough for now! I’m planning the next part of this series will get into actual visual customization techniques in SharePoint… stay tuned for more. As usual if I have confused any of the topics, please let me know in the comments (hey I’m still learning too!).