Saving a Wiki site as site template with Content

Recently, we had a Wiki sub site which was residing on one site collection. We wanted to move it from there to another server under another site collection. I thought the easiest way would be to create a site template with content for the Wiki site and then create a wiki site on the target server using the STP file generated.

I then went into Site Actions à Site Settings à Save Site as Template

The first thing odd about this is that I thought Sub Sites do not have the "Save Site as Template" link in site settings. It is an unsupported feature to type in /_layouts/savetmpl.aspx and create the site template. The next strange thing is when savetmpl.aspx page loaded up it did not have the "Include Content".

I found both to odd. So I went to another sub site in the same site collection, and went to Site Settings. The "Save Site as Template" link as missing here as expected. I then typed in /_layouts/savetmpl.aspx and it loaded the page with the "Include Content" link.

I don't understand this but haven't really had the time to investigate this further.

SharePoint Inspector

SharePoint Inspector is free tool for SharePoint developers that's available from the CodePlex website. As the name indicates, it allows you to inspect various objects within the SharePoint farm in an Explorer like view with properties for each object reflected on the right hand site. It allows you to activate and deactivate SharePoint Features or add event receivers and manage your recycle bin. It's a nice way to have a consolidated look at all your SharePoint objects.

How-To: Backup and Restore

Migrating a site collection from one server to another is a common task for me. Often, the development work is done on our local servers and then moved to a staging server and then to the client's production environment. I have found that the command line utility STSADM is by the far the easiest way for me to move my sites from one server to another. STSADM can be found usually under C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\BIN

For backing up my site collection I use

STSADM     -o backup

        -url http://mysitecollection/

        -filename c:\folder\myfile.dat

After copying the file to the destination server, I then run STSADM to restore the site collection on an existing web application.

STSADM    -o restore

        -url http://mydestinationwebapp/

        -filename c:\folder\myfile.dat

        -overwrite

The overwrite parameter is important to use in scenarios where you have an older backup running or you have simply created the web application along with a site collection. The overwrite parameter instructs STSADM to overwrite the site collection if it exists.

Once this operation has completed successfully you should be able to view you site on the new server. There is however a problem if the target server is on another network (as might usually be the case). When browsing on the new site, it gives you an Access Denied error. You will need to add your local credentials on the new network as the site collection administrator from the Central Administration before you will be able to browse and access the contents of your restored site collection.

Another point to note is that if you have custom webparts that you are using in your application, then these must be individually placed on the target server and you will also need to edit the web configuration file and add the details accordingly.

[X] added to webpart having identical titles

Ever had to create a page in a Sharepoint site where the title or the header of webparts are identical. In order to distinguish them, Sharepoint appends [X] to the title. Thus if you add three Content by Query webparts to your page, by default they will be rendered as Content Query Web Part ‭[1]‬, Content Query Web Part ‭[2]‬ and Content Query Web Part ‭[3]‬. Normally you would configure the webpart properties and give them distinct names. Not in this case though since I had to make something of a gateway page to three subs sites. Three images on the page each provide links to the internal sites with the webparts under them. Image on the left would link to the first site and the webpart under it would show a news list on that particular site. Similarly with the other two images and the webparts. I can't provide the screenshot but this is how the page looked.



The requirement was to have all three webpart titles to be "News Update". But adding the webparts to the page predictably resulted in this.



I dont know if there is a better way to solve my problem, but I found that with a little bit of client scripting I could solve it. In a way this solution is similiar to the one I posted on CSS Customization of Webparts. Each webpart title on the page is assigned an internal id by sharepoint which I use to identify the webpart title. Having identified them, I replace the [x] with a blank.

This is how the code would look like.

<script language="JavaScript" type="text/javascript">
//For my first webpart
var content = document.getElementById("WebPartTitleWPQ2").innerHTML;
document.getElementById("WebPartTitleWPQ2").innerHTML = content.replace('[1]','');
//For my second webpart
content = document.getElementById("WebPartTitleWPQ3").innerHTML;
document.getElementById("WebPartTitleWPQ3").innerHTML = content.replace('[2]','');
//For my third webpart
content = document.getElementById("WebPartTitleWPQ4").innerHTML;
document.getElementById("WebPartTitleWPQ4").innerHTML = content.replace('[3]','');
</script>

and my webparts will then look like

Multiple Webpart CSS Customizations on the same page

It is very important for web graphic designers to understanding how Sharepoint works to the extend that they at the very least understand whats straight forward to do in MOSS 2007 and what will entail a heavy amount of customization.

One of my clients decided that since they had their own design team in place they would do the designs themselves and then pass on some PSDs for us so that we could then incorporate the look and feel by customizing the css. So far so good. The designs they gave were also great but I had one problem with it.

One of the PSDs they sent had two webparts with different colour combinations. I found
Heather Solomon's CSS Reference Chart for SharePoint 2007 as a great starting point for overriding the look and feel but if I overode the css classes supplied by MOSS 2007, then it would change the look and feel of both the webparts. That presented a significant problem for me. I created a sample page on my test server and added a couple of Content Editor webparts inside one web zone, saved the page and opened it using Firefox. And I used firebug to see how the HTML was rendered. (Internet Explorer users can use IE Developer Toolbar). This is the default look and feel of the Sharepoint webparts using the default.master.


I then added a css specifically for this page because I did not want to customizations to effect any other part of the system.

<style type="text/css" media="all">
@import "test2.css";
</style>

Inspecting the two webparts in Firefox and you can see that .ms-WPHeader controls the look and feel of the header which come css. I start by overriding the background colour of .ms-WPTitle and place it in my css.

.ms-WPHeader {
   background:silver;
}

The net result is that my two webparts now looks like this.




As you can see from the image above that overriding ms-WPHeader from the core.css changings the background colour for the headers of both the webparts. The next thing to do is override the headers for the webparts individually. Again, inspecting Firefox, you will note that Sharepoint has associated ids to both your webparts. If there are no other webparts on this page then they will be called MSOZoneCell_WebPartWPQ1 and MSOZoneCell_WebPartWPQ2.

I change

.ms-WPHeader {
   background:silver;
}

into

#MSOZoneCell_WebPartWPQ1 .ms-WPHeader {
   background:silver;
}

and

#MSOZoneCell_WebPartWPQ2 .ms-WPHeader {
   background:orange;
}

with the net result being that my webparts will now look like this.



There is one major problem with this approach. We have no control over the ids associated to the webparts. If you were to add another webpart to the page, those ids might also change. Thats something you need to keep in mind. In my case, it was a one of thing for one specific page in the site and it worked fine for me.

Master Pages and Relative Logos

We have one master page that is used through out our site collection containing one top level site and a large number of subsites.

One of the problems we faced was that each of the sub sites had their own logo to display. Infact the subsites needed to show two logos, one from the top level site on the right hand side and one from the sub site itself on the left hand side of the header. The top level site contained only one logo. For obvious reasons we were keen that whatever the solution may be, the site collection should use the same master page through out. We also didnt want to be in a situation where we would have to go to each sub site and make the changes (Site Settings > Title, Description and Icon) to reflect the correct logo.

That's when we discovered how useful the ~Site token could be. ~Site gets the link to the current site-relative path. This helps me determine which site my user is currently navigating, be in the main site or any of the subsites within the collection.

Next step was the logos themselves. All the logos appearing on the left were renamed logoleft.gif and all the logos appearing on the right were renamed to logoright.gif. Also made sure that the logos were all of the same height and width. Created an image folder in each site, and uploaded the appropriate logos.

Replaced

<SharePoint:SiteLogoImage id=”onetidHeadbnnr0″ LogoImageUrl=”/_layouts/images/titlegraphic.gif” runat=”server”/>

with


<asp:Image runat="server" id="imglogoleft" imageurl="<%$SPUrl:~site/images/logoleft.jpg%>" width="250" height="50"/>

to display the logo on the left of the header. Added another <asp:Image> tag for the logo appearing on the right.

Finally, the top site did not require a logo on the right hand side, but this approach forces the use of an image. Not uploaded one will cause Sharepoint to look for a logoright.gif when its not there and render an empty image box. So we uploaded a pixel gif having the same background as the header to solve the problem.

Next time the Sharepoint Administrator decided to create another subsite, all (s)he has to do is upload logos with predefined names to a predefined location on the site.

Using Querystrings in DataForm Webparts

One of the customisations we did for a recent Sharepoint project was to filter a Data Form webpart based on values supplied from the Querystring.

To make your DataForm accept values from the Querystring, try the following:
1. Open your Sharepoint site using Sharepoint Designer.
2. Create a new page and drop in a DataForm webpart.
3. Bind the DataForm webpart to any of the available lists.
4. Now switch to the Code view and locate the HTML code rendering the webpart control. Under the <ParameterBindings> tag, look for
<ParameterBinding Name="filterParam" Location="Postback;Connection"/>
5. Change this to
<ParameterBinding Name="filterParam" Location="Postback;Connection;QueryString(myField)"/> where myField is the name of the Querystring paramater you want to supply.
6. Now, switch back to Design view, select the DataForm webpart, and open the "Data View" menu (Alt+D) and select the Filter.
7. A filter criteria box shows up. Choose the column that needs filtering in "field name" and select [Input Parameter] in Value and close the filter dailog box.

The Dataform webpart will now be ready to accept values from the querystring. To test this, load the page and pass a querystring.
http://mysite/samplepage.aspx?myField=xxxx

MOSS 2007

I had not heard too many good things about Sharepoint 2003, so when a new client approached us and asked if we could create a Sharepoint site for them in the new version, I was a little bit apprehensive to start with.

However since we had never worked on this technology we were also excited about doing this project. We went through a decent learning curve over a 4 week implementation period and I quite enjoyed the experience. For one thing, it looks like MOSS 2007 is a vast improvement over its predecessors. I would'nt rehash the improvements here as there are plenty of links on the internet that delve into exactly that.

In my spare time what I would like to do is try and document some of the interesting customisations that we implemented in Sharepoint. Many of them have already been discussed before at various forums or blogs, nevertheless I hope this blog will serve to be a point of reference and in due course be of some help to others.