SharePoint Portal Server 2003 Experience (Part 1)
I’ve recently started a project implementing SharePoint Portal Server 2003 (SPS) to replace a legacy intranet solution, and while I’ve deployed SharePoint several times in the past, this is by far the most customizations that I have made to the portal. So I figured this would be a good opportunity to talk about some of my experiences thus far…
The requirements for the Portal:
- Design to look somewhat familiar to parent companies site (not SPS).
- Mimic all the functionality from the legacy intranet site.
- Simplify current document sharing scheme.
- Make as self manageable as possible.
- 4 month schedule.
One of the major customizations that needed to be done to the out-of-the-box SPS install was the UI design. I don’t know if it’s just the projects I’ve worked on, but when it comes to UI, it always seems to take longer then it should to make everyone happy… so I fittingly scheduled this part of the project to take the longest (and it has).
All tasks considered, modifying the SPS UI has been pretty easy, but by no means has it been snag free. Almost all of the existing components can be easily modified by changing a CSS value, but for any major change you will most likely have to modify every .aspx page under the *\TEMPLATE directory/sub directories. One of the things that required this level of change was the common Portal header. I was very surprised to find that some of the style values were hard coded in the .aspx page while the rest of the values were in a CSS. SPS does provide an option to supply an “AlternateHeader” that works by replacing the page header with a customized one, and it does… however there are 2 reasons why I didn’t use this:
1) The “AlternateHeader” is not context sensitive. There are certain values that need to be hard coded into header web parts on each page that assist in linking to Help topics, etc.
2) Not all pages implement the “AlternateHeader” option.
I also investigated using the option for a Custom Cascading Style Sheet. This seemed to work ok until I found out that the Portal and the Windows SharePoint Services (WSS) had some common values stored in the same CSS. For example, if I was trying to change the color of one element in the Portal, it might very well change the color of a totally different element in a WSS site, which I suppose is the logic behind offering an option for a custom CSS that ONLY applies to the Portal. Another issue is that you can not change the default theme used for WSS sites, so you MUST modify the common CSS files. I was able to get both the Portal and WSS sites looking the way I wanted by making the modifications in this order:
- I modified all of the *\TEMPLATE\LAYOUTS\1033\STYLES\*.CSS files to make the WSS sites look the way I wanted them. Don’t worry about what this does to the Portal, as you are going to fix that shortly.
- I then made my changes to the common Portal header by writing a program that would first pull context sensitive values from an .aspx page, and then overwrite the existing header with my custom header incorporating the values I gathered earlier. I ran this program against all .aspxs pages in the *\TEMPLATE directory/sub directories.** (I hope to document this more when I have a chance)
- I created a separate CSS and told the Portal to use it as the Custom Cascading Style Sheet. I then modified this CSS to make the Portal look the way I wanted it.
This was the only way I could find to give me all the control I needed. I also designed my custom header to be very flexible and to rely heavily on CSS so that in the future I won’t have to modify every .aspx again to make simple design changes.
I also tried to use FrontPage to assist in this process, but it ended up causing me a major issue with "ghosting", which I will explain in Part 2 of this series. If you are going to use FrontPage with SPS, then I would limit its use to one of two scenarios:
1) You set up a development site where you can make your changes to the design, then manually apply them to the rest of portal.
2) You are editing a page which does not inherit any design elements from a parent page.
Here are a couple of links that really helped:
SharePoint CSS Definitions: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/spptsdk/html/tsovCSSStyles.asp
SharePoint CSS Info: http://blog.hishambaz.com/archive/2005/01/29/196.aspx
The author from the above link provides the following code that will help you figure out what CSS styles are being used. Just plop this in the <body>:
<script language="jscript">
function ClassInfo() {
if (window.event.srcElement.className != null)
{ stsclass.innerText = window.event.srcElement.className; }
else { stsclass.innerText = ""; } }
window.document.body.onmouseover = ClassInfo;
</script>
<div style="border-style:solid;border-width:1px; width: 281px; height: 34px;
position: absolute; left: 286px; top: 41px; z-index:15; padding-left:4px;
padding-right:4px; padding-top:2px; padding-bottom:2px; background-color:#EEEEF4">
<p id="stsclasstitle"><font face="Tahoma" id="stsclasstitle">Classname: </font>
<font face="Tahoma"id="stsclass"> </font>
</p></div>
I know there is not much documentation on this entire process, so hopefully this information will be of some use to you ;)
* = Program Files\Common Files\Microsoft Shared\web server extensions\60
** = When applying changes to the .aspx pages. The *\1033\STS, and the *\TEMPLATE\LAYOUTS\1033 folders contain the WSS files. The rest are SPS files.