Moved to wordpress

Sorry blogger, but wordpress is quite an impressive service. The features like categories, stats, and the comments feature are too good to resist.

So, all my posts and future posts are now at http://sharepoints.wordpress.com/

Macaw Reskinner

Wow, a whole year. More even, 13 months. How can so much time pass without a blog posting? Perhaps I got lazy. There are so many great SharePoint bloggers out there now, I didn't feel the need to post information. I also didn't want to become an "echo" blog, repeating the latest news that so many blogs seem to do. I like to think that as my role became one of project management, I didn't really come across many technical insights to share with the world.

But anyway....

You certainly start to become more attuned to the business challenges, and consequences, of implementing SharePoint, but you feel that you can't really post on work that is internal to a company.

However, there is on thing that I have come across recently that I should definitely mention.

The one thing everybody comments on, and Microsoft assures us is fixed in the next version, is options that people don't have permission to use are presented to every user. The other is the administration headache of making changes to layout. The amount of files you end up having to change is huge, and you can't help feeling that you're almost breaking SharePoint as you make those changes to allitems.aspx etc etc.

A long while ago, I posted on how difficult the problem of customisation is. It received a lot of comments. I guess many people had the same problems. However, one comment offered a solution that had been proposed before, but never implemented until then.

Alas, I didn't take the time to research it as it wouldn't have helped me then. But someone else did, and commented back on the same article, very positively. Recently I faced some challenges in an implementation, and my memory brought those comments to mind.

Essentially, Serge van den Oever created a httpModule that uses regexp to edit html on the server, after it has been generated by SharePoint. This means you can edit the html of SharePoint web pages, on the server, without touching a single SharePoint config file or .aspx page, before they are sent down the wire to the user. While it may add overhead to your processing time, it is a beautifully clean solution, compared to the alternatives I have seen ( and implemented) before.

That text and those links generated by locked down Microsoft dll's can now be search and replaced away by a simple regex. If for example you're one of those people needing to strip away that site settings link across all WSS sites on a server, I would recommend trying this out. The package can be downloaded from gotdotnet.

Data View Web Parts

Although in my last post I mentioned SharePoint from the project management perpective, here's a tip that's purely development.

One thing that winds me up is how SharePoint deals with ghosted pages. As soon as a page is unghosted it's lost to any future template changes. If you unsure to what unghosted pages are in SharePoint let me assure you they are "a bad thing".

Now should you wish to create a data view web part from an existing list, you have to do it in FrontPage, and you have to then hit the save button, unghosting it and casting the page down in to the 7th circle of SharePoint annoyances.

Unless...

You first create a new web part page, and place your list as a web part on that new page. Then in FrontPage convert it into a Data View web part and do all the customisations you wish. Once done, hit save.

Then visit the page in Internet Explorer. Modify the properties of the data view web part and you'll see the three buttons in the toolpane that displays the properties on the data view web part (Source Editor, DataQuery Editor, Parameters Editor). Open each property window and copy and paste the values to 3 local text files.

You can now delete the web part page and the data view web part it contains. (Although I'd recommend waiting until you know this whole process has worked)

Now go to the page you really want to display the data view web part on.

Drop an empty Data View web part in to a zone. Open the toolpane, and for each property button paste in the values from your local text files.

You'll now have your customised Data View web part, and no unghosting will have taken place!

High-five!

What’s that? You don't have an empty Data View web Part? Ah.

Right-click save target as on http://gilesgregg.com/Data%20View%20Web%20Part.dwp.

Copy it in to your wpcatalog folder under the sites’ root iis folder and you'll then find it under the Virtual Server gallery.

Alternativly you could export the web part to a .dwp file off the temporary web part page and then import it to the destination page. This is certainly an easier method in the short term, but I've found having an empty data view web part in the Virtual Server gallery quite useful.

Any feedback gratefully received...

Back from holiday

Ok, so I wasn’t actually on holiday for 3 months, but on my return I started a new job project managing a SharePoint implementation rather than acting as a technical consultant.

A very different way of working.

While tech knowledge helps in that role, you obviously spend much less time dealing with code and .aspx templates and the like, which has left me with not so much to publish.

I have had quite a few circumstances where I’ve had knowledge that would be useful to post, but as a project manager, you’re not in the frame of mind where your instinct is to rush to your blog. Your responsibility is to resolving problems and keeping the project on track.

I’m going to try this method of posting to my blog via email, and perhaps posting SharePoint thoughts from the perspective of a project manager.

Modify Shared Page

Ok, just before I go off on holiday for a week, here is a quick post on something I've been using for a while.

If anyone out there has been wanting to edit the drop-down that decends when the "Modify Shared Page" box is clicked, here is one quick and easy method.

The structure and options of the menu are actually a small xml fragment embedded in the html source of each page. Simply by editing the xml you can edit the menu. Microsoft use this technique on many of their web sites.
Here is an example javascript function that will add the create link to the bottom of the drop-down.

function updateMenu()
{
//get a reference to the XML fragment
//team workspace menu
var oNode = document.getElementById('MSOMenu_SettingsMenu');
if(oNode==null){
//meeting workspace menu
oNode = document.getElementById('MtgMenu_SettingsMenu');
}
//check it exists
if(oNode!=null){
//append an additional node to the xml
oNode.innerHTML = oNode.innerHTML + '<ie:menuitem type="option" onmenuclick="javascript:window.location=\'_layouts/1033/create.aspx\';">Create</ie:menuitem>';
}
}

You can write any javascript functions you like, and have them executed by the onMenuClick property of the menuitem node.

If you want to get ambitious, you can define sub-sections, icons, in fact pretty much re-write the whole menu. Have a look at the xml fragment to understand it's structure and properties. If you have difficulty finding it, search on the text 'MtgMenu_SettingsMenu'.

Now, how do you run this javascript on the page? You can either create your own update.js file, and then edit every .aspx list and web part page template to include a reference to the js file. Or, add your function to the file ows.js as it is already referenced by every page.

Additionally, you have to ensure the updateMenu function does not execute before the xml fragment has been written out in the html. You can either:-

• Use the onload event to fire the command. Alas, some sharepoint pages already use onload, and you risk damaging native functionality with this method.
• Use setTimeout('updateMenu()',500); Here, you are dependant on the end user having downloaded the page completely within your specified time delay.
• Edit each .aspx template and ensure the updateMenu() command is the last processing instruction on the page. Low risk, but a significant amount of work, and vunerable to Microsoft updates to SharePoint.

Considerations

• In either method, you are changing pages that will potentially get over-written by a SharePoint patch or update from Microsoft. Bear this in mind when choosing in which files to place new javascript functions.
• If you do declare a path similar to the one "_layouts/1033/create.aspx", be aware that that it will not always be valid with respect to the page the user is on, particulary in the case of web part pages. I believe I have a solution for this, but I haven't investigated it yet.
• If you edit ows.js, it will effect every site on the server, you may need additional logic in the javascript to ensure additions are only made for certain sites, for example testing the domain name.

I'm sure others out there can think of ways to minimise the risks of running client-side javascript in this way, and perhaps increase the functionality of the updateMenu() command.

Make more posts

A couple of weeks ago I dropped a comment on Maurice Prathers blog about using http compression on sharepoint. This is something I consider almost essential for any sharepoint site, regardless of your connection speed to the server.

It looks like he took it up, and and has written a great post on how to implement it. Which of course made me feel very lazy in not making an effort to post the info myself *note to self, post info*.

He has also published very detailed info on the resulting performance.

my only comment is that he may have set the compression level a bit too high..

UPDATE: Maurice has updated his article showing the performance benefits of using level 9 compression.

great post Maurice.

Portal Alternate Header

I received a comment from Sunil on SharePoint customisation, and I decided to make a post of of my reply. It was great to receive a comment, firstly furthering the sharing of knowledge, secondly it's great to know that someone is reading my blog! Hey all you lurkers out there, drop a comment sometime, it's the sort of thing that motivates us to post more information.. ;-)

anyway, back to the question...

is there any way where I can change the home page of portal server and all following site pages ( not my sites) will have the same. I tried the alternateheader, but I don't know where I made the mistake none of the pages got changed or no changes error happend also. no change.

There are a couple of options available to you with SPS. You can specify an alternate image for the top corner, and an additional CSS stylesheet through the SharePoint administration interface. However it sounds like you want more substantive changes.

WSS sites are created from a single template, either STS or MPS. However SPS sites are made up from multiple templates under the system 60 directory :- SPSBWEB, SPSCOMMU, SPSNEWS, SPSNHOME, etc..

Thus, any changes you make must be made to the ONET.XML file must be made to all the SPS?????/xml/onet.xml files. Additionally, they must be made before you create the portal site.

However, the Portal ONET.XML files already have an alternate header defined, "PortalHeader.aspx" which you can find in the layouts/1033 directory (presuming you are using the 1033 locale). So, you can edit that file to implement changes to the portal header.

Except, no, you can't really.

Without going into great detail on the SharePoint architecture, all sharepoint pages are based on an .aspx template somewhere under the /60/ directory. Some of those templates contain a line of code saying:-

<%
string alternateHeader = SPControl.GetContextWeb(Context).AlternateHeader;
if (alternateHeader == null || alternateHeader == "")
{
%>

Pages that contain this statement will show any changes that you make to PortalHeader.aspx. Pages that don't, won't. Unfortunetly the only pages that have this statement are admin pages under the layouts/1033 directory. Even then, its not all of them.

Pages that the end user sees run under a different architechure to the administration pages. So how do you edit the header on these pages? So far, the only method I am aware of is to edit every single template file. There are about 100 per language for STS sites (web part page and list templates), I haven't worked out how many for portal sites, as I'd rather not even think about it. The most managable solution I have found is to use a javascript include that manipulates the DOM client-side at run-time, but this is only suitable for minor edits.

Anyone who has found how to use an alternate header properly across all pages, please raise your hand. Much kudos is available to whoever can draw the sword of customisation from the stone of SharePoint.