Microsoft Enterprise Content Management (ECM) Team Blog : Web Content Management

Publishing Sites: Field Controls or Web Parts... That is the Question!

ecmblog — Thu, 09 Oct 2008 07:40:00 GMT

There isn't a week that goes by where I don't get an email asking me this very question. More often than not, its because someone has been using the Content Editor Web Part (CEWP) when they should have been using the Publishing HTML field type. This mistake typically goes unnoticed until a customer needs to roll back to a previous version of a page or when they run a content deployment job. So what goes wrong? Well, the CEWP doesn't store version history, it doesn't participate in any publishing approval workflow and it does store absolute URLs rather than relative URLs. The first problem means you'll have to go to site backups to get access to previous versions of content, the second problem means that users will see updates to the content in the CEWP even if an editor hasn't approved the page for publishing and the third problem means that all your hyperlinks will resolve to the wrong address (e.g. http://staging.adventure-works.com/ vs http://www.adventure-works.com/).

Thankfully, all of these problems can be avoided by using the Publishing HTML field type. I've talked at length with Andrew Connell (MVP) about this and I know it's something he is passionate about so I asked him to write up a guest post to explore the topic.

Ryan Duguid
Technical Product Manager
Microsoft Corp

Andrew Connell on Field Controls and Web Parts

One of the most common problems I see with people developing Publishing sites stems from the lack of understanding in the core differences between Web Parts & Field Controls and when to use them. Many a consultant have dug a deep hole in this area. My goal in this post is to make you aware of the differences to make educated decisions when selecting one over the other.

What follows is a discussion with respect to MOSS 2007 Publishing sites (aka: WCM sites), but all the concepts apply to any Windows SharePoint Services 3.0 based site.

When creating editable content regions on a page layout, enabling content owners to add and manage their own content, developers/designers are presented with two options: field controls or Web Parts. These two options are very different and Publishing site developers should be aware of the differences. The fundamental difference comes down to where the data is stored.

Web Parts
Web Parts come straight from ASP.NET and their data is stored in a personalization store. Microsoft was nice and baked the personalization store into the site collection's content database. Data in a Web Part is stored within the context of the PAGE (i.e.: URL) & the user (which could be the shared user or a specific person). This does allow the content in Web Parts to be uniquely personalized by authenticated users.

In addition, developers and designers can only create Web Part Zones on the page layout. Content owners can then put any Web Part in the zones and any content within them.

Field Controls
Field Controls are much different from Web Parts. They are more like windows into list items. A field control pulls data (in display mode) from a particular column in a list item and writes back to that column in edit mode. Pages in a Publishing site are stored as items in a list; the Pages list. Because they are in a list, they can leverage all the benefits a list has to provide, but visioning & history is the most important here. Just keep one thing in mind: field controls are simply gateways, or windows, to the data.

When a developer places a field control on a page layout, they have the ultimate control of where it is placed on the page and any rules such as if the content owners can insert tables or images into the content. The content owners can only work within the rules defined by the developers.

What is the significance?
Great question! From my experience, MOST customers (90%+) who are rolling out a Publishing site, or Web-based content management systems such as MOSS 2007 WCM, are doing so because the following aspects are important to the project:

Consistent lookand feel (aka: a corporate brand)
Empower content owners & subject matter experts (SME) to maintain the content
Free up IT staff from updating content submitted by SMEs
Structured organization of contentand a versioned and/or historical record of the content

The challenge here is that Web Parts pose a problem with this approach. Because their data is stored in the ASP.NET personalization store in the context of the page (it's URL mind you) & the user. However with field controls, the data is saved with the page's list item. This means that when the page is updated, a new version is created and the old data is retained with the page.

Another challenge is with URLs in the content... especially relative URLs. Take the Publishing HTML field type & the Content Editor Web Part (CEWP). The CEWP does not store relative URLs... it stores only absolute URLs. Even if you enter a relative URL into the editor, it will be converted to an absolute URL. The rich text editor that the Publishing HTML field type is tied to does not convert relative URLs to absolute URLs.

If structure and history is important on your site, you should ONLY consider field controls for your content. If you want to have a more relaxed authoring environment where structure & history isn't important, Web Parts are better. What if structure & history is important... does it ever make sense to use Web Parts? Sure! Use them for providing functionality like stock quotes, consuming news feeds, or rolling up content (as in the Content Query Web Part). In this scenario, the only data that's stored is configuration data... not true content.

To summarize: the content in Web Parts is not versioned and there is no history, but the content in field controls is versioned & a history is retained (provided the Pages library has versioning enabled, which it does by default).

-AC

Andrew Connell
MVP Office SharePoint Server
www.andrewconnell.com/blog
Sr. SharePoint Instructor - Ted Pattison Group
http://www.tedpattison.net/

Announcing: End-to-End Content Deployment Walkthrough

ecmblog — Wed, 11 Jun 2008 22:45:00 GMT

Hi, I'm Cern McAtee, a technical writer for Office SharePoint Server 2007. I'm pleased to announce that the Office SharePoint Server 2007 content team and the Global Readiness team have combined efforts to write and publish a new walkthrough guide for content deployment: End-to-End Content Deployment Walkthrough.

What's covered

This downloadable guide is aimed at IT pros planning to use content deployment with their enterprise sites using Microsoft Office SharePoint Server 2007. The guide takes you through the steps for setting up source and destination site collections, creating a deployment path and job, and then running the job to see how it populates the destination site collection with the content from the source site collection. One important thing to note when it comes to doing content deployment is that when you first set it up, the destination site collection must be empty. You can create the destination site collection using either the Blank site template, or by using the Stsadm createsite operation to create an empty site.

In addition to the walkthrough, we have also published a set of topics about Administering Web content management that cover publishing and content deployment operations. These topics are intended for IT pros who manage publishing and content deployment for their enterprise sites. More WCM topics that cover cache settings and profiles, document conversion, and variations will be published soon.

Send your feedback

We're very excited about publishing this walkthrough guide and the new WCM content, and we're especially interested in your feedback on this new content. There are three ways you can provide feedback on this content: First, in each topic you will find a "Click to Rate and Give Feedback" control with a text box for supplying feedback. Second, you can send us mail at o12ITdx at Microsoft.com. Third, you can use the "Leave a Comment" interface in this blog to provide comments, either about this blog entry or about the newly published content.

We look forward to hearing from you and to continuing to improve this content in partnership with you!

Thanks,

Cern McAtee
SharePoint Enterprise Solutions content team

Two new MSDN articles on WCM

ecmblog — Mon, 17 Sep 2007 21:27:00 GMT

In case you missed them, two new WCM-focused articles hit MSDN recently:

Branding and performance are two of the most popular topics when it comes to leveraging the WCM features of MOSS 2007, especially in the context of building an Internet-facing site. I'm eager to hear people's questions or comments that stem from the articles above. Please post comments if you have them.

George Perantatos, ECM Program Manager

Increased performance for MOSS apps using the PortalSiteMapProvider

ecmblog — Wed, 23 May 2007 09:07:00 GMT

Performance is usually top-of-mind for any web site deployment, including MOSS. If you're writing code that deals with SharePoint items, and you're deploying that code to a site with even moderate traffic, you should consider using the PortalSiteMapProvider for increased performance. In this post, Chris Richard takes us through the feature and describes how it can be leveraged. Take it away Chris!

Introduction

The SharePoint OM works best when providing access to data in the "context" items - the web, page, list, list item, etc. that the request URL specified. Fetching the context web via SPContext.Current.Web and referencing the majority of the properties on that web completes quite quickly and without a high number of database roundtrips. However, there are a number of scenarios where a variety of data from multiple webs, lists and list items is required, and using the SharePoint OM to repeatedly fetch this data can become very costly. Navigation rendering is an example of such a scenario - rendering navigation on a particular page often involves fetching at least the title and description of a large number of ancestor and descendant webs.

MOSS employs a number of in-memory LRU caches to speed up access to such information while decreasing the load on the database server. Specific parts of this caching system are exposed through public caching APIs - CrossListQueryCache (http://msdn2.microsoft.com/en-us/library/microsoft.sharepoint.publishing.crosslistquerycache.aspx), and CbqQueryCache (http://msdn2.microsoft.com/en-us/library/microsoft.sharepoint.publishing.cbqquerycache.aspx) can be used to optimize repeated access to these types of queries which can sometimes be very expensive to run.

The cache also stores more basic SharePoint objects like SPWebs and SPListItems. The objects are fetched from the database when first requested and then stored in memory on the web server in order to speed up the processing of subsequent requests for the same data. This data stays in memory until memory pressure and usage patterns force it out, or the backing data is changed in the database. And although there isn't a public OM geared specifically to expose this functionality, the PortalSiteMapProvider exposes a number of methods that can be used to get at this cached data.

PortalSiteMapProvider Instances

In general, you shouldn't create new instances of PortalSiteMapProvider to be discarded after use in a single method. These objects contribute to a lot of memory use and are designed to be shared across a large number of requests. Any PortalSiteMapProvider instances declared in web.config can be accessed with:

PortalSiteMapProvider portalProvider = (PortalSiteMapProvider)SiteMap.Providers["<InstanceName>"];

MOSS declares a number of instances of PortalSiteMapProvider in web.config which are used for rendering navigation. For convenience, the PSMP class exposes a number of static properties which allows even easier access to these standard named instances. In addition, there is a similar static property defined for "WebSiteMapProvider" which doesn't correspond to a definition in web.config, but is a useful instance of PortalSIteMapProvider for caching purposes as it returns only webs. By default, an instance of PSMP returns webs, Publishing pages, headings and authored links - the 4 different types of items that show up in navigation. The following properties are set on this provider at initialization time in order to remove (possibly) unwanted items:

// do not limit the number of children a particular node may store
webSiteMapProvider.DynamicChildLimit = 0;
// do not include pages in results
webSiteMapProvider.IncludePages = IncludeOption.Never;
// do not include authored links in results
webSiteMapProvider.IncludeAuthoredLinks = false;
// do not include headings but return nodes beneath headings
webSiteMapProvider.FlattenHeadings = true;

See http://msdn2.microsoft.com/en-us/library/microsoft.sharepoint.publishing.navigation.portalsitemapprovider_members.aspx for the full list of configurable properties for the provider. Most of these properties affect the collection of nodes returned by the GetChildNodes method which I'll touch on in just a minute. Depending on your scenario, it may make sense to define your own static instance of PortalSiteMapProvider with a configuration that suits your needs.

PortalSiteMapProvider.FindSiteMapNode

This method allows fast and easy access to webs by URL:

PortalSiteMapProvider portalProvider = PortalSiteMapProvider.WebSiteMapProvider;
PortalSiteMapNode webNode = ((PortalSiteMapNode)portalProvider.FindSiteMapNode("/site/web"));
System.Console.WriteLine(webNode.Title);

You can also access Publishing pages in a similar fashion, using a different provider which doesn't exclude pages:

PortalSiteMapProvider portalProvider = PortalSiteMapProvider.CurrentNavSiteMapProviderNoEncode;
PortalSiteMapNode pageNode = ((PortalSiteMapNode)portalProvider.FindSiteMapNode("/site/web/Pages/Page1.aspx"));
System.Console.WriteLine(pageNode.Title);

Be aware though, you cannot fetch the default page of a web, as you will be returned a node representing the web itself. This quirk has to do with providing the right set of navigation links for the navigation menus - after all, the PSMP is first and foremost a navigation site map provider. I discuss a different technique which does allow you to fetch the default page, a little later.

PortalSiteMapNode

All nodes returned by this provider are of type PortalSiteMapNode and may be safely cast to this type. The class exposes a number of properties, some of which are related to navigation specifically but most are generally useful. Title, Description and UniqueId are examples of simple but useful properties available on all nodes. The Type property provides information about the node's internal type, and may be used to determine if casting to a more specific type of PortalSiteMapNode is possible. WebNode is also a useful property, returning the web associated with a particular item; a node representing a web returns itself for its WebNode property. See http://msdn2.microsoft.com/en-us/library/microsoft.sharepoint.publishing.navigation.portalsitemapnode_members.aspx for a list of all available properties.

PortalWebSiteMapNode

If a node has type NodeTypes.Area, it may be cast to a PortalWebSiteMapNode which provides a few extra methods for getting at cached data only available on webs. GetProperty and TryGetProperty are great for accessing properties found in the SPWeb.AllProperties property bag. See http://msdn2.microsoft.com/en-us/library/microsoft.sharepoint.publishing.navigation.portalwebsitemapnode_members.aspx for a list of all members.

PortalListItemSiteMapNode

If a node has type NodeTypes.ListItem or NodeTypes.Page, it may be cast to a PortalListItemSiteMapNode. This type exposes indexers which allow access to cached field data by field name and ID. See http://msdn2.microsoft.com/en-us/library/microsoft.sharepoint.publishing.navigation.portallistitemsitemapnode_members.aspx for a complete list of members.

PortalSiteMapProvider.GetChildNodes

This method has a number of overloads and allows fast and easy access to a particular node's navigation children (only webs and headings may be parents, sub-webs, Publishing pages, and the other navigation items show up as direct children). If you're using the "WebSiteMapProvider", GetChildNodes will only include webs in the child node collection. If you're not using a specially configured provider, but still want to control the type of children returned, you can use the following overload:

PortalSiteMapProvider portalProvider = PortalSiteMapProvider.CurrentNavSiteMapProviderNoEncode;
SiteMapNodeCollection children = portalProvider.GetChildNodes(((PortalSiteMapNode)portalProvider.CurrentNode).WebNode,
    NodeTypes.Area, NodeTypes.Area);

The first NodeTypes parameter denotes the type of child nodes you want returned, the second denotes the types you want to have returned even if items of this type have been hidden from navigation. Specifying the same type(s) for both parameters will ensure that node of that type will be returned regardless of any navigation visibility settings. Multiple types may be specified as follows:

PortalSiteMapProvider portalProvider = ortalSiteMapProvider.CurrentNavSiteMapProviderNoEncode
SiteMapNodeCollection children = portalProvider.GetChildNodes(((PortalSiteMapNode)portalProvider.CurrentNode).WebNode,
    NodeTypes.Area | NodeTypes.Page, NodeTypes.Area | NodeTypes.Page);

Note that the set of page nodes returned by this method will not include the page which is set to be the default page of the web. Continue reading for a more generic method of accessing cached list items that doesn't have this limitation.

PortalSiteMapProvider.GetCachedListItemsByQuery

List items which are Publishing pages are easily accessible via FindSiteMapNode and GetChildNodes, but for all other types of list items, this method allows access to cached list items by SPQuery. For example:

SPQuery query = new SPQuery();
query.Query = query.Query = "<Neq><FieldRef Name=\"FSObjType\"></FieldRef><Value Type=\"Integer\">1</Value></Neq>";
SiteMapNodeCollection children = portalProvider.GetCachedListItemsByQuery(((PortalSiteMapNode)portalProvider.CurrentNode).WebNode,
    "Pages", query, SPContext.Current.Web)

This fetches all items from the Pages list, including the default page which GetChildNodes leaves out. The method uses the supplied context web to determine the current user's access rights and trim the results accordingly, and is not affected by any of the navigation-related configuration I mentioned earlier, so it doesn't really matter which instance of PSMP you call this on.

PortalSiteMapProvider.GetCachedList

This method provides access to cached lists, returning a node of type PortalListSiteMapNode. The data available via this interface is not extensive, but may meet your needs. See http://msdn2.microsoft.com/en-us/library/microsoft.sharepoint.publishing.navigation.portallistsitemapnode_members.aspx for a complete list of members.

Drawbacks

Using PortalSiteMapProvider in this way can have some drawbacks. The first request for a particular web or page via FindSiteMapNode or GetChildNodes will take longer to fetch than a similar call into the WSS OM. This is because in this case the caching mechanism must roundtrip to the database and will often fetch more data than it needs in an attempt to pre-fetch and optimize subsequent requests. Therefore it is not useful to fetch data which is accessed very infrequently via these methods. The benefit associated does not show up until multiple calls have been made for the same data.

Also, using the above methods to fetch data which frequently changes can also be counterproductive. If the data changes frequently, it will be frequently invalidated and re-fetched from that database negating the benefits of caching. The invalidation mechanism is relatively coarse, with a change to a particular item invalidating any data in the same web as the item.

Finally, I should mention the "Site collection object cache" page, accessible via the "Site Settings" page. Here you can control a number of object cache properties - in particular the amount of memory, in MB, to allocate to the object cache on a per-site collection basis. If you notice sluggish performance on a large site collection, you might want to try upping the default limit of 100MB. Performance counters can help you fine tune cache performance by monitoring the effect of changing the cache size. The counters available on performance object "SharePoint Publishing Cache" will give you information about this caching system - be sure to select the instance that corresponds to your site collection URL.

--Chris Richard, ECM Developer

Anonymous Users, Forms Pages, and the Lockdown Feature

ecmblog — Sat, 12 May 2007 02:41:00 GMT

If you're running an anonymously accessible MOSS website, especially an internet-facing one, you may have noticed that your SharePoint Forms pages are also accessible to anonymous users. For example, if you're using the publishing features, anonymous users might be able to get to http://SERVER/Pages/Forms/AllItems.aspx. Typically you don't want this, so how do you prevent anonymous users from accessing these pages?

In order to help with this, we provide a Feature out of the box called the ViewFormsPagesLockdown Feature, which we usually just call the Lockdown feature for simplicity. If you're experiencing this problem and want to lock anonymous users out of your Forms pages, then you can execute the following stsadm command on your farm:

stsadm.exe –o activatefeature –url <site collection url> -filename ViewFormPagesLockdown\feature.xml

This will enable the lockdown feature on your site collection. If you already had anonymous access enabled, you'll need to go disable it, then enable it again. Go to the _layouts/setanon.aspx page, switch anonymous access off, click OK, then go back and set it to on, click OK. You should now get an authentication prompt when you try to navigate to a forms page. For example, try http://www.tylerbutler.com/Pages/Forms/AllItems.aspx.

If you just wanted the solution, you can stop reading. If you want to know what this feature does and why you may or may not be having this problem, read on. :-)

In SharePoint, anonymous users' rights are determined by the Limited Access permission level. Limited Access is a special permission level that cannot be assigned to a user or group directly. The reason it exists is because if you have a library or subsite that has broken permissions inheritance, and you give a user/group access to only that library/subsite, in order to view its contents, the user/group must have some access to the root web. Otherwise the user/group will be unable to browse the library/subsite, even though they have rights there, because there are things in the root web that are needed to render the site or library. Therefore, when you give a group permissions only to a subsite or library that is breaking permissions inheritance, SharePoint will automatically give Limited Access to that group or user on the root web.

This explains why you might see users and groups having Limited Access applied to them even though you never did it explicitly. But what about anonymous users? Where do they fit in? As I said above, anonymous users' rights are defined by the Limited Access permission level. If you want to see what rights Limited Access is composed of in your site, go to http://SERVER/_layouts/role.aspx and click on Limited Access.

Because there's no way to change this permission level through the UI, and because anonymous users' rights are defined by this permission level, we create the Lockdown feature to toggle on and off a couple of rights. Specifically, the Lockdown feature removes the View Application Pages permission, and the Use Remote Interfaces permission. The View Application Pages is the one that allows our anonymous users to access the Forms pages. After enabling the lockdown feature, they no longer have that right.

So why are some people having the problem where the lockdown feature isn't enabled? It all depends on what site template you used when you created your site. By default, the Lockdown feature is enabled on the Publishing Portal template, so if you started with that template, then you shouldn't have this problem. Otherwise, enable the feature and you're good to go.

For more info on security for external sites, see Plan security for an external anonymous access environment on TechNet.

Tyler Butler
Program Manager, Web Content Management

Building a real world extranet application with MOSS 2007 (Part 2 of 3)

ecmblog — Wed, 07 Mar 2007 08:43:38 GMT

Introduction

In the first installment of this blog series, we introduced the project and its requirements and started creating the basic site and content structure. In this installment, we’ll cover the customization and branding choices that we made, venture into the slightly gray areas that needed some additional thinking, and discuss some of our “off the beaten path” customization tactics.

Site and content customization (i.e. branding)

The new file management system was to replace an existing model, which users were already familiar with. This coupled with the fact that an already well established corporate brand existed meant that creating a consistent and familiar experience would be very important towards encouraging speedy user adoption of and efficient transition to the new system.

Once the UI was established visually, we began the process of matching best practices with both customer requirements and the new MOSS 2007 design and development experience.

The customization process was divided into two major sections in an attempt to offer maximum scalability while separating the majority of presentation from the content and code base.

Master Page Customization
Cascading Style Sheet Customization

The art of creating a custom Master Page in MOSS 2007

MOSS 2007 adopted the ASP.NET 2.0 master pages model, a model which allows you to separate the chrome (UI elements) from the content. The second major benefit of using master pages in MOSS 2007 is that you can control the UI of a site or entire site collection with a single page, the master page.

Before creating our custom Master Page, it was important for us to fully understand the following concepts:

Content Place Holders and Content Controls, and how they are used in MOSS 2007

There are several pages behind a rendered page that you would see in SharePoint. The Master Page which holds the UI chrome as well as content place holders where content can later be “plugged in” from other pages. These other pages, known as Content Pages have Content Controls with IDs matching those on the placeholders in the master page.
When requested, the content from the Content Control is merged into the Content Place Holder of the Master Page, finally presenting you with a single rendered page. Understanding this concept is very important when customizing a Master Page because removal of a content place holder that is later called on will result in an error. It’s important the content place holders exist on the page – even if not visible. For a list of content place holders, which reside in the default Master Page of a SharePoint site, see http://msdn2.microsoft.com/en-us/library/ms467402.aspx.

Creating a minimal Master Page

Unlike standard design, there is no blank slate from which to start a site in SharePoint. There is no magic “File New” button in SharePoint Designer 2007 that will allow you to just begin coding your UI and have the SharePoint functionality just work. Instead, you will need to understand how to work with SharePoint’s default Master Page and to minimize it by leaving only the placeholders that are required for SharePoint to function. Luckily for us, MSDN has been kind enough to post a minimal Master Page complete with comments, which you can use as a starting point for your own sites: http://msdn2.microsoft.com/en-us/library/aa660698.aspx.

Armed with information on the preceding topics and the tool of choice, SharePoint Designer 2007, we set out to create our custom branded application. SharePoint Designer 2007 allows you to connect to and work with your SharePoint sites, so the first thing we did was fire up SharePoint Designer 2007 and connected to our site via the File, Open Site menu.

MOSS 2007 introduces a new concept of “publishing features”. Publishing features represent the CMS 2002 integration into SharePoint, now known as Web Content Management or WCM. When enabled, publishing features allow you to do things like enable content approval workflow or change the Master Page and style sheet on the fly, both of which we utilized and proved useful in creating a custom branded application.

After combining our custom UI (graphics and code) with the minimal Master Page from MSDN, we uploaded our custom Master Page to the _catalogs/masterpage folder. This is a good time to point out that with a blank starting Master Page (and page layouts), we were able to vastly reduce the number of tables, and take advantage of our CSS based UI.

After uploading our custom Master Page, we added some final tweaks such as adding the company logo to the Master Page. While there is an out of the box method for adding a logo (Site Settings > Title, Description and Icon), doing this does not automatically carry the logo down to new sub-sites as they are created; instead, you would need to re-specify the logo on each site. This is by design just in case you want to specify a different logo on the subsites, which normally makes perfect sense, but in our project, a requirement was that all sites are to be created using the parent company’s corporate logo unless otherwise specified. To accomplish this, we created a custom picture library labeled “site images” and uploaded the corporate logo (named companylogo.gif) to the library. Next we replaced the default mechanism for switching the logo in the Master Page:

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

replacing it with some key new functionality in SharePoint 2007:

<asp:Image runat="server" id="Logo" ImageUrl="<% $SPUrl: ~site/site images/companylogo.gif %>"/>

What this change does is tell the image control to check in the site’s site images library for companylogo.gif. Because this is specified in the Master Page, the change is seen on subsites, which inherit this Master Page. Also, because we have specified the “site” site images library in SPURL, changing the company logo on a sub site is simply a matter of over writing the default companylogo.gif image in the specific site's site images library. We mimicked this approach when adding a header image to the page, allowing even further customization on a site by site basis.

To apply our custom Master Page, we went to the root site's Site Settings, Master Page section where we were able to select and apply it to the site and subsites right from the browser, completely transforming the UI into an intuitive and branded application.

Separating the presentation

To separate the content, mark-up, and presentation as much as possible, we opted to use the alternate style sheet approach. By default, the core style sheet, appropriately named CORE.CSS controls the majority of the sites, colors, fonts, and positioning.

To over-ride these default values, we took advantage of the “AlternateCSS”, an option which can be specified from the browser under Site Settings, Master Page, Specify “AlternateCSS” URL.

We started by creating a blank style sheet and saving it to the style library, a library created by default with all publishing portals. After adding our style sheet and specifying it using the method described above, any styles/properties we add which exist in the default (CORE.CSS) will be overwritten because our alternate style sheet is read last.

To figure out what classes we needed to override, we took advantage of a free tool from Microsoft’s Internet Explorer Team, the Internet Explorer Developer Toolbar. Download the beta here.

Using the “Select Element by Click” option in the IE Developer Toolbar, we were able to click on any element of our screen and instantly see what class should be changed in our alternate style sheet. In the example below, we clicked on the Recycle Bin link.

In the example above, we could add .ms-recyclebin to the alternate style sheet to change its properties. Tip: Make sure you copy all properties specified in the CORE.CSS; otherwise, they will not be overwritten.

Using “AlternateCSS”, we were able to isolate the presentation to a single style sheet, overriding the default styles when applied.

Because subsites can be set to inherit the Master Page and alternate style sheets of their parent, this method also allows for sweeping brand changes by editing a single file. Just as it can be set to inherit, you can also choose not to in which case subsites are free to use a completely different Master Page or style sheet.

In this installment, we covered the key customization methods which allowed us to brand our sites as well as keep a familiar and intuitive UI for our application. In the next and final installment, we will take a look at Search as well as how we overcame multilingual obstacles before wrapping up with a look at our template system and our finished product. We'll also provide a summary of the MOSS 2007 specific features that were utilized for our project.

Shane Perran – User Experience Lead, SharePoint MVP
Jared Rypkema – Lead Software Architect
Infotech Canada | Information Worker Solutions

Building a new page layout which does not reference core.js (but downloads it while the page is being viewed thereby optimizing response time)

LLiu — Thu, 22 Feb 2007 07:06:00 GMT

[The optimization technique described below is an updated version of a previous blog entry. The primary change is that a new page layout rather than a detached page should be used.]

If you have an internet-facing website, you are probably exploring all avenues to make it more responsive to clients. For some users – particularly those with low-bandwidth or high-latency connections – the very first page load of a site can take a long time because of all the resources which need to be downloaded along with the page markup itself. Although these resources are often shared between pages and cached on the client, the first page load can be painfully slow.

In MOSS 2007, it is possible to defer the downloading of some of this content until the user is actually able to read the homepage. In this way, the page is rendered much more quickly, while the user’s experience of interacting with the site is not negatively impacted.

In this blog we will describe how you can create a specific page within your site (for example, it could be the root homepage) using a special layout, and remove core.js from the list of resources that must be downloaded before the page can render for an anonymous user. Because this core.js is about 54KB in its compressed form, this can enable the page to render as much as 10 seconds earlier for clients on a 56kb modem connection. Once the user is reading the page, core.js will download in the background.

By default, all pages in MOSS 2007 contain a reference to core.js. In many places, this file is critical, such as where the Site Actions Menu is shown. There are also some instances, however, when core.js is unnecessary. This workaround makes it possible to delay downloading core.js by certain users on a pages created with a specific layout. It does not matter whether the user is anonymous or authenticated; core.js will still be downloaded to the client. The distinction is that for authenticated users, it will be downloaded before the page is readable, while for anonymous users it will be downloaded after the page is readable.

First, let’s set some expectations. This is not an officially supported optimization, but it puts the ability to fine tune in the hands of the site administrators, while assuming the burden of ensuring that the site works as expected afterwards. This does not remove core.js from the entire site, just from pages created with a specific layout, and these pages will have the requirement that nothing on them requires core.js (otherwise they would obviously break). For example, the SharePoint Menu control, if required for anonymous users, would not function on such a page.

We welcome feedback on any elements of this process.

Before beginning, we need to do three things:

· Ensure that the Site Master Page is different from the System Master Page. This information can be found by browsing to the URL http://<yourservername>/_Layouts/ChangeSiteMasterPage.aspx . If you observe that the Site Master Page and the System Master Page are referencing the same file, this optimization will not work for you; it is required to change the Site Master Page to use a different file. Example pages that use the System Master Page are /_layouts/Settings.aspx, and in general any pages in the _layouts directory.

· Ensure that there are no controls in the Site Master Page which will be visible by anonymous users and which require core.js but do not register it. The optimization we use will suppress core.js only for anonymous users, and only on a single page, which means that authenticated users will still get core.js by default. If you modify the code referenced in step 5 to suppress core.js for more than just anonymous users, you will need to take this into account at the Site Master Page level, as well.

· Ensure that the Site Master Page does not have any ScriptLink controls which register core.js. The goal of this exercise is to create a single page which suppresses core.js, even though it would have been registered by the SPWebPartManager under typical circumstances.

Having satisfied these criteria, we can now be confident that the site is ready for our optimization.

1. Create the page layout which is not to reference core.js. One way of doing this is to use SharePoint Designer, make a copy of an existing layout and paste the copy in the same directory. For this example, we’ll copy ArticleLeft.aspx and call the new layout ArticleLeftNoCore.aspx. Note that you’ll probably want to edit the description of this new file so that when you create a new page, you’ll be able to distinguish the two layouts.

2. In SharePoint Designer, Edit ArticleLeftNoCore.aspx.

3. Inside the tag with ID PlaceHolderAdditionalPageHead, Add the following markup: <SharePointWebControls:ScriptLink runat="server"/>

This has the effect of telling the server that unless core.js is specifically registered by some control, it should not be referenced. Note that this example was created using BlueBand.master, but other master pages may have a different tag required to reference the ScriptLink control. For example, in default.master, the tag would be SharePoint:ScriptLink instead of SharePointWebControls:ScriptLink. The correct tag will be referencing the Microsoft.SharePoint.WebControls namespace, and looks something like this:

<%@ Register Tagprefix="SharePointWebControls" Namespace="Microsoft.SharePoint.WebControls" Assembly="Microsoft.SharePoint, Version=12.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" %>

4. Create a new binary based on the code in Appendix A, and set the version to “1.0.0.0”. In my example, this new binary is called PerfTools.dll.

The purpose of this code is to tell the server that if the user is not anonymous, we do want to specifically register core.js. We do this because by default many authenticated users will have access to the Site Actions menu, which requires core.js, while anonymous users do not. Your scenario may require that you suppress core.js under different circumstances, and if so, this is the code to change. Please note that the OnInit method will be executed any time the page is loaded, so you will want to ensure that you do not add any code which would adversely impact the throughput on the server. Accessing the current SPListItem, for example, will most likely incur a round trip to the SQL database.

5. Add PerfTools.dll to the GAC on the server.

6. In the web.config file for the server, add this line to the set of SafeControls (but with the correct PublicKeyToken):

<SafeControl Assembly="PerfTools, Version=1.0.0.0, Culture=neutral, PublicKeyToken=3ec1cbf2475be08c" Namespace="WebControls" TypeName="*" Safe="True" />

7. In ArticleLeftNoCore.aspx, add a tag to register the new binary. It will look something like this (but with a different PublicKeyToken):

<%@ Register TagPrefix="PerfTools" Namespace="WebControls" Assembly="PerfTools, Version=1.0.0.0, Culture=neutral, PublicKeyToken=3ec1cbf2475be08c" %>

8. On the line following the markup from Step 4, add the following markup: <PerfTools:RegisterCoreWhenAuthenticatedControl runat="server"/>

9. Copy CorePreLoad.aspx (file content in Appendix B) to the _layouts directory on the server.

The markup in this file references a single function in core.js, and will download core.js before executing it.

10. In the master page used by the site, add a new placeholder in the markup after the </form> tag and before the </body> tag that looks like this:

<asp:ContentPlaceHolder id="PlaceHolderBottomIFrame" runat="server" />

This is necessary because the IFrame we are about to add can not be inside the Form tag, otherwise the page will break when a postback is executed.

11. In ArticleLeftNoCore.aspx, at the end of the file, add markup that looks like this:

<asp:Content ContentPlaceholderID="PlaceHolderBottomIFrame" runat="server">

<iframe src="http://blogs.msdn.com/_layouts/CorePreLoad.aspx" style="display:none"/>

</asp:Content>

This will reference CorePreLoad.aspx in such a way that everything else on the page is displayed before it gets loaded and serves its purpose (which is to download core.js).

12. The page layout should now be currently checked out to whoever is editing it in SPD. At this point it can be checked in, published, approved, or whatever you need to make it live.

13. Create a new page using ArticleLeftNoCore.aspx as the layout. It is ready for use. When anonymous users browse to it, core.js will not need to be downloaded before they can begin interacting with or reading the page. (If you create two identical pages, one with ArticleLeft.aspx as the layout, and the other with ArticleLeftNoCore.aspx as the layout, you should see that one references core.js while the other does not.)

14. Ensure that no controls on the page are broken for anonymous users due to missing scripts. Test the page well, and if there are any controls which fail to work for anonymous users because core.js is missing, they must be removed from the page itself or from ArticleLeftNoCore.aspx. The assumption of the optimization is that this special page has been created which does not require core.js because nothing on the page requires it.

15. Ensure that core.js does continue to appear on other pages in the site. If core.js is now missing from other pages aside from the one we have just created, you can be sure problems will follow. Browse various other pages and examine the markup to see that core.js is referenced on the page.

You will know that our optimization is working properly because when you browse to the new page with an empty browser cache as an anonymous user and view the page source, you will not find a reference to core.js. When you look in your cache, however, you will find that core.js has been downloaded from your server. Other pages in your site will continue to reference core.js as usual.

Sterling Crockett, Software Design Engineer

SharePoint Web Content Management

Appendix A: RegisterCoreWhenAuthenticatedControl

using System;

using System.Collections.Generic;

using System.ComponentModel;

using System.Text;

using System.Web;

using System.Web.UI;

using System.Web.UI.WebControls;

using Microsoft.SharePoint;

namespace WebControls

{

[DefaultProperty("Text")]

[ToolboxData("<{0}:RegisterCoreWhenAuthenticatedControl runat=server></{0}:RegisterCoreWhenAuthenticatedControl>")]

public class RegisterCoreWhenAuthenticatedControl : WebControl

{

protected override void OnInit(EventArgs e)

{

if (HttpContext.Current.Request.IsAuthenticated)

{

Microsoft.SharePoint.WebControls.ScriptLink.RegisterCore(this.Page, true);

}

base.OnInit(e);

}

Appendix B: CorePreLoad.aspx

<%@ Register Tagprefix="SharePoint" Namespace="Microsoft.SharePoint.WebControls" Assembly="Microsoft.SharePoint, Version=12.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" %>

<html>

<head>

</head>

<body>

<SharePoint:ScriptLink name="core.js" runat="server" />

DisableRefreshOnFocus();

</script>

</body>

</html>

Building a detached page that does not reference core.js (but downloads it while the page is being viewed thereby optimizing response time)

ecmblog — Wed, 07 Feb 2007 09:21:00 GMT

[Update 02/21/2007: VERY IMPORTANT -- the optimization technique described below may introduce an undesirable caching side effect. An updated optimization technique using a new page layout has been posted here.]

If you’ve implemented or are planning to implement a Internet facing website, you are probably exploring all avenues to make it more responsive to users and visitors. For some users – particularly those with low-bandwidth or high-latency connections – the very first page load of a site can take a long time because of all the resources which need to be downloaded along with the page markup itself. Although these resources are often shared between pages and cached on the client, the first page load can be painfully slow.

In MOSS 2007, it is possible to defer the downloading of some of this content until *after* the user sees the page. In this way, the page is rendered much more quickly, while the user’s experience of interacting with the site is not negatively impacted.

In this blog entry, I will describe how you can modify a specific page within your site (in this example, the root homepage) and remove core.js from the list of resources that must be downloaded before the page can render for anonymous users. Because the core.js file is about 54 KB in its compressed form, doing this can enable the page to render as much as 10 seconds faster for users on a 56 Kbps modem connection. Once the user is reading the page, core.js will download in the background.

By default, all pages in MOSS 2007 contain a reference to core.js. In many places, this file is critical, such as where the Site Actions Menu is shown. There are also some instances, however, when core.js is unnecessary. My performance tuning tip makes it possible to delay downloading core.js by certain users on a specific page. It does not matter whether the user is anonymous or authenticated; core.js will still be downloaded to the browser. The distinction is that for authenticated users, it will be downloaded before the page is readable, while for anonymous users it will be downloaded after the page is readable.

Before I continue, let me set some expectations. This is *not* an officially supported optimization, but it puts the ability to fine tune in the hands of the site administrator, who must assume the burden of ensuring that the site works as expected afterwards. This does not remove core.js from the entire site -- just from a single page, and this page must not have anything that requires core.js (otherwise, it will obviously break). For example, the SharePoint Menu control, if required for anonymous users, would not function on this page.

For starters, you need to do three things:

· Ensure that the Site Master Page is different from the System Master Page. This information can be found by browsing to the URL http://<yourservername>/_Layouts/ChangeSiteMasterPage.aspx. If you observe that the Site Master Page and the System Master Page are referencing the same file, this optimization will not work for you; this optimization requires that the Site Master Page use a different file. Example pages that use the System Master Page are /_layouts/Settings.aspx, and in general, any pages in the _layouts directory.

· Ensure that there are no controls in the Site Master Page, which will be visible by anonymous users and which require core.js but do not register it. This optimization will suppress core.js only for anonymous users, and only on a single page, which means that authenticated users will still get core.js by default. If you modify the code referenced in Step 5 below to suppress core.js for more than just anonymous users, you will need to take this into account at the Site Master Page level as well.

· Ensure that the Site Master Page does not have any ScriptLink controls, which register core.js. The goal of this exercise is to create a single page, which suppresses core.js, even though it would have been registered by the SPWebPartManager under typical circumstances.

Having satisfied the above criteria, you can now be confident that the site is ready for this optimization.

1. Create the page, which is not to reference core.js. We’ll call it NoCore.aspx, but in your case, default.aspx might be more appropriate since that’s the default Home Page for your site.

2. In SharePoint Designer, navigate to NoCore.aspx in the tree hierarchy, right click, and select “Detach from Page Layout.” This will have the effect of converting NoCore.aspx to an “untemplatized page.” What this means is that while it is still subject to the site wide Master Page, its markup is no longer governed by the layout from which it was created, and you will be able to update the markup as you see fit.

3. In SharePoint Designer, Edit NoCore.aspx.

4. Inside the tag with ID PlaceHolderAdditionalPageHead, Add the following markup: <SharePointWebControls:ScriptLink runat="server"/>

<%@ Register Tagprefix="SharePointWebControls" Namespace="Microsoft.SharePoint.WebControls" Assembly="Microsoft.SharePoint, Version=12.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" %>

5. Create a new binary based on the code in Appendix A, and set the version to “1.0.0.0”. In my example, this new binary is called PerfTools.dll.

The purpose of this code is to tell the server that if the user is not anonymous, we want the page to specifically register core.js. We do this because by default, many authenticated users will have access to the Site Actions menu, which requires core.js, while anonymous users do not. Your scenario may require that you suppress core.js under different circumstances, and if so, this is the code to change. Please note that the OnInit method will be executed any time the page is loaded, so you will want to ensure that you do not add any code which would adversely impact the throughput on the server. Accessing the current SPListItem, for example, will most likely incur a round trip to the SQL database.

6. Add PerfTools.dll to the GAC on the server.

7. In the web.config file for the server, add this line to the set of SafeControls (but with the correct PublicKeyToken):

<SafeControl Assembly="PerfTools, Version=1.0.0.0, Culture=neutral, PublicKeyToken=3ec1cbf2475be08c" Namespace="WebControls" TypeName="*" Safe="True" />

8. In NoCore.aspx, add a tag to register the new binary. It will look something like this (but with a different PublicKeyToken):

<%@ Register TagPrefix="PerfTools" Namespace="WebControls" Assembly="PerfTools, Version=1.0.0.0, Culture=neutral, PublicKeyToken=3ec1cbf2475be08c" %>

9. On the line following the markup from Step 4, add the following markup:

<PerfTools:RegisterCoreWhenAuthenticatedControl runat="server"/>

10. Copy CorePreLoad.aspx (file content in Appendix B) to the _layouts directory on the server.

The markup in this file references a single function in core.js, and will download core.js before executing it.

11. In the master page used by the site, add a new placeholder in the markup after the </form> tag and before the </body> tag that looks like this:

<asp:ContentPlaceHolder id="PlaceHolderBottomIFrame" runat="server" />

This is necessary because the IFrame we are about to add can not be inside the Form tag, otherwise the page will break when a postback is executed.

12. In NoCore.aspx, at the end of the file, add markup that looks like this:

<asp:Content ContentPlaceholderID="PlaceHolderBottomIFrame" runat="server">

<iframe src="http://blogs.msdn.com/_layouts/CorePreLoad.aspx" mce_src="http://blogs.msdn.com/_layouts/CorePreLoad.aspx" style="display:none"/>

</asp:Content>

This will reference CorePreLoad.aspx in such a way that everything else on the page is displayed before it gets loaded and serves its purpose (which is to download core.js).

13. The file should now be currently checked out to whoever is editing it in SPD. At this point it can be edited, checked in, published, approved, or whatever you need. It is ready for use. When anonymous users browse to it, core.js will not need to be downloaded before they can begin interacting with the page.

14. Ensure that no controls on the page are broken for anonymous users due to missing scripts. Test the page well, and if there are any controls which fail to work for anonymous users because core.js is missing, they must be removed from NoCore.aspx. The assumption of the optimization is that this special page has been created which does not require core.js because nothing on the page requires it.

You will know that the optimization is working properly because when you browse to it with an empty browser cache as an anonymous user and view the page source, you will not find a reference to core.js. When you look in your cache, however, you will find that core.js has been downloaded from your server. Other pages in your site will continue to reference core.js as usual.

I hope that you found this optimization tip useful. Leave a comment here if you have any questions or suggestions for other ways of improving page load performance.

Sterling Crockett, Software Design Engineer

SharePoint Web Content Management

Appendix A: RegisterCoreWhenAuthenticatedControl

using System;

using System.Collections.Generic;

using System.ComponentModel;

using System.Text;

using System.Web;

using System.Web.UI;

using System.Web.UI.WebControls;

using Microsoft.SharePoint;

namespace WebControls

{

[DefaultProperty("Text")]

[ToolboxData("<{0}:RegisterCoreWhenAuthenticatedControl runat=server></{0}:RegisterCoreWhenAuthenticatedControl>")]

public class RegisterCoreWhenAuthenticatedControl : WebControl

{

protected override void OnInit(EventArgs e)

{

if (HttpContext.Current.Request.IsAuthenticated)

{

Microsoft.SharePoint.WebControls.ScriptLink.RegisterCore(this.Page, true);

}

base.OnInit(e);

}

Appendix B: CorePreLoad.aspx

<%@ Register Tagprefix="SharePoint" Namespace="Microsoft.SharePoint.WebControls" Assembly="Microsoft.SharePoint, Version=12.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" %>

<html>

<head>

</head>

<body>

<SharePoint:ScriptLink name="core.js" runat="server" />

DisableRefreshOnFocus();

</script>

</body>

</html>

Building tylerbutler.com, Part 6: What Was Tough, and What’s to Come

ecmblog — Tue, 16 Jan 2007 05:23:00 GMT

Part 1 :: Part 2 :: Part 3 :: Part 4 :: Part 5 :: Part 6

This is part 6 of an ongoing series of posts about my experience building a custom site on top of Office SharePoint Server 2007. If you haven't yet read parts 1 through 5, I'd strongly suggest starting there.

In my last post, I discussed some of the final touches I put on my new site. In this post, I'll talk about things that I found particularly difficult during this project, and discuss some other ideas for features and functionality that might come in the future.

Content Query Web Part Limitations

I love the Content Query Web Part. It is pretty customizable in both result sets and presentation, it drives RSS feeds, and it generally solves the very real problem of aggregating content dynamically across a site. However, it has one core drawback that can be a bit annoying – it doesn't know where it is. What I mean by that is that a given CQWP doesn't know that it's in a specific subsite. In my site, I have a page layout for my rollup pages that includes a CQWP for the main content. I wanted to just add my CQWP to the layout and have it automatically aggregate content from only the current subsite. Unfortunately, because the CQWP isn't aware of its current location, you can't configure it that way. You must explicitly set a property on the part telling it what specific sites you want to aggregate content from.

While this is an unfortunately limitation, there is a way to make this work. You can write a small custom control that you add to your page layout that is aware of the current location and sets properties on the CQWP at runtime. This is the method I will be looking at pretty soon, because it also has the pleasant side-effect of letting me set web part properties at the page layout level. If my custom control sets the properties at runtime and lives in the page layout, then I can just modify it once and all of my rollup page CQWP's magically get updated. I'm not sure how this will impact performance of the part, so that's something to investigate if you're considering going down a similar road. The impact should be relatively negligible if you're making use of output caching.

Styling Issues

Another problem I ran into was around styling. Some things are pretty tough to style. The major culprits here are web parts. Web parts always want to inject their own chrome and color scheme into the page content. This was frustrating when using the CQWP, because I specified all of the markup I wanted in the XSLT styles, and then the web part would throw some random CSS style or table around itself when it rendered. You can still see markup like <td id="MSOZoneCell_WebPartWPQ2" valign="top"> and <div id="WebPartWPQ2" class="ms-WPBody"... in my page markup, even though I have the web parts configured to not output any of their chrome. Talk about annoying!

Most of this stuff ends up being pretty innocuous. However, some of the side-effects are that your CSS styles might not look right when content is being output from a web part, because your styles are cascading incorrectly because the web part (or more correctly, the web part zone) is throwing something extra into the markup. I got around this by adding some additional CSS class to make sure the web part CSS got overridden. For example:

.ms-WPBody a:link {

color:#888888;

font-family:"Lucida Grande",Helvetica,Arial,sans-serif;

font-weight:bold;

text-decoration:none;

}

This works, but it's very annoying that I had to go this route in the first place. One other trick you can use if your web part doesn't live inside a zone is to set SuppressWebPartChrome="true" on the web part. This suppresses almost all of the web part chrome from being rendered. Unfortunately, this only works on web parts that don't live in a zone, which means that you can really only use this for page layouts. In my case CQWP's won't serve RSS feeds unless the web part lives in a zone, so I couldn't use this approach in most cases.

Another area that was a bit frustrating from a styling perspective was the search control. I haven't managed to get it right yet. If you look at my site in Firefox, the search box is not right-aligned like it should be. IE6 renders it right aligned, but I think IE7 does it like Firefox. Anyway, this is just another example of what can be frustrating when controls output presentation elements that aren't easily overridden. I'm sure I'll figure it out eventually, but just like with the web part styles, I shouldn't need to. I want a clear, unified way to style my page and I don't want controls usurping my look and feel that I painstakingly crafted.

This project was a lot of fun, but it certainly didn't come about without a share of challenges. I toyed with several designs or options in various sections of the site before settling on the "final" solution, and things are far from done, and as is always the case, there are drawbacks to every solution. Some of the things I have written about in my posts have already been changed because I decided to try something different; no doubt more changes will come in the future.

In fact, I have a whole lot of ideas that I want to implement. Alas, time is short and I probably won't get to most of them, but I thought I'd mention a few because people might find them interesting.

Authoring in Word

Word 2007 has the capability to post to blogs using both the MetaWeblog and Atom APIs. The SharePoint blog template has a server-side implementation of the MWL API, so you can post to your SharePoint blog using Word, Windows Live Writer, or any other MWL-compatible authoring tool. But my site isn't a SharePoint blog. One of the core reasons I used the publishing features was because I had a specific look and feel I wanted for the site, and I wanted to be able to update that on a grand scale easily.

That said, there are a lot of features that blogs have that I would like to have on my site. One of those is the ability to create posts offline and post them later. To this end, I have been working on an implementation of the MWL API that knows how to post Publishing pages. I even have it working, though it's not ready for anyone else to use it or anything. If I manage to get it in releasable shape at some point, I'll put it on my site. But basically, my point is that with a little time and elbow-grease, you can make some services that extend the authoring capabilities of the system. George, another PM on my team, also built a prototype email handler that would create a publishing page based on incoming mail. There are lots of possibilities here, and the object model we have is robust enough to allow you to build you these sorts of things pretty quickly.

Forms Authentication, User Sign-up, and Comments

One of the things I'm missing from my old site is the ability for people to sign up for accounts and then either contribute posts or comment on existing posts. In order to support this, I need to switch over to use Forms Authentication (which is super easy because SharePoint has a pluggable authentication model) and build a sign-up page. Again, I have this working already, but it's not live yet. Once I make it live, people will be able to sign up for their own account, log in, and post content on the site (with my approval, leveraging the awesome workflow capabilities of SharePoint). If you're looking for more info on setting up forms auth, Andrew Connell has a great post at http://www.andrewconnell.com/blog/articles/HowToConfigPublishingSiteWithDualAuthProvidersAndAnonAccess.aspx.

Custom Layouts and Controls

I also have quite a few custom controls and layouts that I'd like to write. One big one is a custom DateTime control, because the default SharePoint one only allows you to set time in 5-minute increments. I demand more precision! :-)

I also plan to make a couple of controls for my music/movie/game/book reviews that will connect up to Amazon and load information about the item I'm reviewing. This should be pretty straightforward, since Amazon has an extensible web services framework.

Well, ladies and gents, I think it's time for me to bring this post series to a close. I hope that some of you have found the information useful. If you are interested in any future projects I do for the site, I encourage you to visit http://www.tylerbutler.com, or subscribe to a special RSS feed that is tailored to my more technical audience. This feed only has items from my Work and Projects sections. I figured some of you might not be interested in my poetry, music, or book reviews, but if you are, hey, there are feeds for that too. :-)

I doubt this is the last you've heard of me, though, so until next time...

Part 1 :: Part 2 :: Part 3 :: Part 4 :: Part 5 :: Part 6

Telerik's cross-browser rich text editor for SharePoint 2007 -- public beta now available

LLiu — Wed, 10 Jan 2007 00:18:00 GMT

[Cross-posting from the SharePoint Team Blog]

As previously announced on this blog and as of now officially named r.a.d.editor for SharePoint 2007, this Web-based rich text editor extends the web content authoring environment of Office SharePoint Server 2007 by providing cross-browser compatibility (i.e. with Netscape 7.1+ and Mozilla 1.3 browsers) and support for the Macintosh platform (i.e. Safari browser). This special edition of Telerik’s market leading editor offers the same functionality as SharePoint’s native rich text editor and is provided by Telerik at no cost to all registered customers of Office SharePoint Server 2007.

This r.a.d.editor can be used in the following scenarios:

· Rich text field control in a SharePoint List

· Rich text editor Web Part

· Web Content Management page

To get the public beta, go to http://www.telerik.com/sharepoint.

For online Q&A and discussion, go to http://www.sharepointcontrols.com/support/forums/forum/b3041S-btc.aspx.

Happy holidays as a bunch more MOSS-based Internet sites go live

LLiu — Sun, 24 Dec 2006 10:53:00 GMT

On behalf of the SharePoint product group (actually, our official name is the Office Business Platform Group), I wish you a wonderful holiday break and a very happy new year!

Here’s a bunch more MOSS-based Internet facing websites that have recently gone live (go here for a list of others mentioned in the past):

http://www.cegos.fr -- Cegos Group, the largest European learning and development provider with 28 offices in 15 countries, has adopted MOSS for their WCM and transactional needs. This implementation is the first production website that relies on MOSS 2007 and Commerce Server 2007.
http://www.shareview.co.uk -- Shareview is Lloyds TSB Registrars’ online portfolio service that helps shareholders and employees to manage their holdings. Lloyds TSB Registrars is the UK’s leading provider of share registration services. Lloyds TSB Registrars is a division of Lloyds TSB Bank plc and acts as Registrar for over 650 companies, including around 60% of the FTSE 100, managing some 24 million shareholder accounts.
http://www.infocision.com -- As a leading provider of call center solutions, InfoCision specializes in political, religious and nonprofit fundraising, and sales and customer care.
http://www.paulmitchell.com – I’ve been using Paul Mitchell’s excellent hair beauty products since, like, high school. Need I say more? J
http://www.speaktech.com – speakTECH is a Microsoft Gold Certified Partner focused on delivering solutions for demanding enterprise environments and growing small companies.
http://www.sharesquared.com – ShareShared is a premier provider of technology solutions for SharePoint, collaboration, and knowledge management.
http://www.satama.com – Satama is a leading European digital services company, based in Finland, with a global clientele and offers services and solutions for marketing, productivity, and mobility.

Of course, it would be inexcusably ironic for this blog to be hosted on anything other than SharePoint for too much longer. Hence, this blog will be migrated to a MOSS-based environment in 2007. More details will be forthcoming.

Again, happy holidays to you! Thank you for continuing to read this blog, and please don't hesitate to leave feedback via comments.

Lawrence Liu
Senior Technical Product Manager and Community Lead

Building tylerbutler.com, Part 5: Final Touches

ecmblog — Mon, 18 Dec 2006 22:49:00 GMT

Part 1 :: Part 2 :: Part 3 :: Part 4 :: Part 5 :: Part 6

This is part 5 of an ongoing series of posts about my experience building a custom site on top of Office SharePoint Server 2007. If you haven't yet read parts 1 through 4, I'd strongly suggest starting there.

In my last post, I discussed using detached pages and migrating content from my old site. In this post, I'll cover a few of the final touches that I added to the site.

The "All Posts" Page

In my old site, when you visited a rollup page, only the first five posts were displayed. If you wanted to see additional posts, you could search for them, or you could click one of the numbers at the bottom of the rollup page. That would take you to a different "page" that displayed items further down the list. For example, if you went to page 2, you'd see items 6-10. Page 3 contained items 11-15, and so on. This was fine, but using Content Query web parts in MOSS didn't allow me to configure this behavior right out of the box. Instead, I opted to create an "All Posts" page that would list all the posts for a given category.

In order to do this, I created a special page layout called "AllPostsLayout.aspx," and added a CQWP to a zone right in the middle of the layout. I configured that web part to get all the Pages except those that had category "Rollup Page." I then went through on every subweb and created a page using that new layout. I had to customize the individual CQWP's on every new page, to make sure they rolled up the right data, but this was pretty painless since I made sure that most of the properties were set properly when I added the web part to the layout.

The other thing I did was add a link to the "all posts" page in the Site Rollup layout. To make sure that this link worked properly regardless of what subweb the rollup page was in, I made use of some SharePoint controls I'd used previously for other things in the site. This is what the markup looked like:

<SharePointWebControls:splinkbutton runat="server" NavigateUrl="~site/Pages/AllPosts.aspx" id="onetidProjectPropertyTitle">
see all posts in <SharePointWebControls:ProjectProperty Property="Title" runat="server" /></SharePointWebControls:SPLinkButton>

This was a major change from the way things worked in my old site, but I think it's for the better. The problem with paging (showing items 1-5 on the first page, 6-15 on the second, etc.) is that people only ever use the first 2 or three pages. For example, they know that there was a very recent post that they saw and they want to get back to it. After that they use search because it's faster than sorting through every page. I could have built paging with a custom web part or control that changes the parameters of the CQWP based on some query strings, but frankly, it would have been more work than it's worth. The All Pages view was simple to put together and meets my needs. To be fair, it doesn't scale – if you have hundreds or thousands of items in a single category you'll start having problems. Not necessarily in performance, but definitely in usability. Definitely keep this in mind if you're looking at a similar solution.

The Current Date and Time

My old site had a gratuitous little feature that out put the current date and time in top right-hand corner of the page, right under the search box. This should be pretty straightforward, right? All I needed to do was call System.DateTime.Now.ToString() with a special date time format string. Unfortunately, this was slightly more complicated in SharePoint because I couldn't just get ASP code blocks to execute in my master page by default. However, I was able to enable this functionality by adding some markup in web.config:

<PageParserPaths> 
         <PageParserPath VirtualPath="/_catalogs/masterpage/*" CompilationMode="Always" AllowServerSideScript="true" IncludeSubFolders="true" /> 
</PageParserPaths>

Once this was added to my web.config, I was able to add code blocks to items only in the master page gallery. This is important – you typically don't want to enable code blocks on every page in your site because if you do, any user with access to any library in your site can upload an ASPX page that executes code. Then they can visit that page and get code to execute on your box, leading to major pwnage. There are very good reasons why code blocks are disabled by default in SharePoint.

However, in this case, I only enabled code blocks for pages in the master page gallery (check out the VirtualPath property in the snippet above), which is much safer. Only your site designers or owners should have access to the MPG, so there's a level of trust there that is probably OK. In my case, this is further mitigated by the fact that I am currently the only person with write access to the site. However, even if I allow users to post content later, they still won't have rights to upload content to the MPG.

After the code blocks were enabled, all I had to do was paste in my code snippet into the right spot in my master page. This is the markup:


<div class="header-datestamp">
    <asp:ContentPlaceHolder ID="HeaderDate" runat="server">
        <% Response.Write(System.DateTime.Now.ToString("dddd, MMMM d yyyy @ h:mm tt")); %>
    </asp:ContentPlaceHolder>
</div>

I should point out that you can most definitely also do this sort of thing with a user control. In this case, it would be a very simple user control, but wrapping functionality in controls, marking them as safe, and putting them in your layouts is in general the best approach to custom functionality. In my case, because the functionality I needed was so basic, I opted to do it in a code block. However, if you're looking at enabling code blocks in any part of your SharePoint site, take some time to really consider the ramifications and your needs. If the functionality you need is even remotely complicated (read: more than one line of code), write a control.

RSS Feeds

The next step was configuring RSS feeds for my site. I had a couple of different options to accomplish this. The CQWP's that were already on my homepage could easily be configured to spit out feeds. However, they only contained five items, and I wanted my feed to contain ten items.

In order to accomplish this, I added a page to my site using a layout with a web part zone. This page wasn't meant to be seen by any visitors to my site, so it didn't matter which layout I used, as long as it had a zone in which I could put the web parts. I added a CQWP to this page with its RSS feeds turned on. I configured this web part with the same properties that I used for the ones on the front page, except I set it to roll up ten items instead of five.

When you turn on the RSS feed, the CQWP by default renders out a little orange feed icon that links to the feed. You can override this presentation by editing CQMain.xsl in the Style Library. Another feature of turning on the RSS feed on a CQWP is that it injects markup into the page header that lets browsers like Firefox and IE 7 discover the feed automatically.

This functionality is perfect if you want to make your feeds available only on the page that's hosting your CQWP. However, in my case the CQWP that was serving my feed was on a "hidden" page, so I needed to copy the URL of the feed and then modify my master page to include it. I also wanted some statistics around feed subscriptions, so I wrapped my feed up through FeedBurner so I could get these statistics easily.

Customizing the master page was very straightforward. I added the following markup to the header to get the auto-discovery in Firefox and IE 7:

<link rel="alternate" type="application/rss+xml" title="Recent posts on Tyler Butler.com" href="http://feeds.feedburner.com/TylerButlerAllPosts"/>

Then I added a section in right column that linked to the feed, for people who were using other browsers. In the future, I can add more feeds here, or I might opt to build out a feed landing page that lists all of my feeds, similar to what sites like CNet or GameSpot do.

At this point, I had my feed configured and linked to, but unfortunately, it wasn't outputting things exactly like I wanted. For example, I wanted the date and time of a post to be the date and time I set, not the Creation Date, which is the default. I also wanted to provide full post text with my feeds, so people who use RSS readers such as Bloglines or Google Reader don't have to visit my site if they don't want to.

Supporting this sort of feed customization was super straightforward. The thing to remember is that ultimately, the feed is supported by a Content Query Web Part. That means that all the functionality and extensibility that the CQWP provides can apply to the feed. In my case, what I needed to do was customize the fields that were returned by the web part (namely, override the CommonViewFields property on the web part). That ensured that the query that the CQWP was issuing would return the fields I wanted to include in my RSS feed. Note that this process was the same as what I did back in part 2 of series.

In order to customize exactly what content went into my feed, I had to edit RSS.xsl in the Style library. You can also create a copy of RSS.xsl, then modify the copy to suit your needs. This is a better approach, because then you can customize specific feeds by modifying the XSL that governs them specifically. There are some specific things you have to do if you go down this road, but George goes into much greater detail about this in his post on RSS customization. If this is something that interests you, his post is a great resource.

At this point, my site was pretty much migrated. It's not done, of course! I have lots of cool ideas for some customizations, and I'm still missing some core functionality, most noticeably user comments and the ability for people to sign up for an account and post. The core functionality and look and feel, though, is complete. That means this post series is about to come to an end. Not quite yet, though. :-) I will post a final post soon to discuss some of the specific challenges I encountered while working on this project and flesh out some of my ideas for future functionality. Until next time...

Part 1 :: Part 2 :: Part 3 :: Part 4 :: Part 5 :: Part 6

Building tylerbutler.com, Part 4: The Main Home Page and Migrating Content

ecmblog — Mon, 11 Dec 2006 08:58:00 GMT

Part 1 :: Part 2 :: Part 3 :: Part 4 :: Part 5 :: Part 6

This is part 4 of an ongoing series of posts about my experience building a custom site on top of Office SharePoint Server 2007. If you haven't yet read parts 1 through 3, I'd strongly suggest starting there.

In my last post, I discussed customizing the XSL styles to get my rollup pages looking exactly how I wanted them, and talked a bit about some of the limitations I ran into with my design. In this post, I'll cover creating my main site home page using a "detached page" and migrating the content from my old site into the new one.

The Main Home Page

On my old site, every category rollup page was pretty much the same, each of them just rolled up different content. My main home page was slightly different than the other rollup pages, because I wanted to hide the right navigation, and display some other special content on it, such as my Xbox Live gamertag and some RSS feeds.

One option was to create another page layout and override the right navigation with custom content. However, the layout was going to be pretty much the same as a typical rollup page, so why create a whole other page layout just for this one instance? Plus, there weren't going to be a lot of other pages that looked the way the home page did. As I was talking with some other PM's on my team about how I could solve this in an elegant way, George suggested I use a "detached page." I'm glad he brought it up, because I had almost forgotten about the feature, and it allows me to do exactly what I want.

Typically when we talk about publishing pages in MOSS, we are talking about "templatized pages." That is, pages that have an associated page layout that maps the pages content, which is stored in columns in the Pages list, to their actual position and appearance on the rendered page. This allows the great flexibility to change the appearance of pages because of the separation between data and presentation. However, there are most definitely things called "untemplatized pages." These are just aspx pages that are dropped in a library. MOSS is running on top of ASP.NET, so these pages will happily render.

You can make an untemplatized page by simply creating your own aspx page and putting it in a library. However, using SharePoint Designer, you can also create an untemplatized page from an existing templatized page. We refer to this process as "detaching," since you're essentially severing the link between the page layout and the page, and copying the appropriate markup from the layout into the actual detached aspx page. Once this is done, you can make changes to the page without changing the layout or impacting any of the other pages that are using that layout. This makes it perfect for situations like mine, where essentially everything was the same as another page layout, but there were some one-off changes I wanted to make, like overriding the right navigation.

In order to do this, you need to have a templatized page first. I went ahead and created one using the Site Rollup page layout that I created earlier. Once the page was created, I went to the Pages library of the site in SharePoint Designer, right-clicked on the page, and selected Detach from Page Layout. I received the following warning about the ramifications of detaching the page from its layout.

After clicking Yes on the warning dialog, my page was detached. I opened it up is SharePoint Designer and customized its placeholders, saved it, and my homepage was done.

There are some things to note about detached pages. As the warning dialog clearly points out, changes to layouts do not affect detached pages, because they're no longer associated with a layout. However, they are still associated with the site master page, so changes to it will be reflected in the detached page. Also, the contents of the page itself is still stored in the columns of the list, and gets versioned, just like you'd expect. There's still a page edit mode in the browser that you can use to change the contents of the page, so you don't have to use SharePoint Designer to make content changes on detached pages. When you think about it, this makes sense. The detachment process is copying all of the markup from the page layout, so the resulting page behaves just like a normal page, except that instead of grabbing the layout markup from the page layout file, it's stored in the page itself.

You can also reattach a detached page. When you do this, you lose all of the customizations that you've made, and the page starts getting changes from its associated page layout, since it's reattached to it. The actual data in the page is still preserved though, just like it is when you detach from the page layout.

One other potential negative to detached pages: they don't get the benefit of output caching. In my case, since my site is relatively low traffic, I am not concerned about this quite yet. However, if you want to use a detached page on a very high traffic site, you'd want to consider the performance impact of not having caching on this page. Kai has a great post about caching in MOSS that is a fantastic place to start if you're new to the whole caching thing.

Migrating Content

The basic look and feel of the site was done. I had created my master page, layouts, customized my XSLT's, and created the rollup pages and homepage. However, my old site had around 200 posts that I wanted to move over to the MOSS site. I had several options for migrating the content over.

First, I could do it manually. I could open every post in my old site, create a corresponding page in the new site, and copy/paste the content. With 200 posts, this was doable, but I wasn't exactly excited about the prospect of hitting Ctrl-C, Ctrl-V that much.

Another option was to create a package using the WSS Content Migration API (known internally as PRIME, and I'll refer to it as such through the remainder of this post). PRIME is designed to export and import content from WSS, and since MOSS is built on top of WSS, it can handle MOSS content as well. Because PRIME has a public schema, I could craft a custom package that I then fed into the PRIME import code, which would handle importing all of my content for me. This is essentially what we do when we migrate content from Content Management Server 2002. We connect up to the CMS 02 DB and create a custom PRIME package, which we then feed into PRIME to import for us.

The final option was for me to write some custom code to do the migration. The logic would be pretty simple: connect to the GeekLog DB, get the post data, then create a page in the right subweb and put all of the content from the GeekLog database into the right field on the page. In the end, this is what I opted for. Like I said, I like writing code! The code is below. Please note that this code is very barebones and specific to my needs. The huge if/else logic for mapping the categories to the right subweb is particularly ugly, but it was just the most straightforward way for me to get it done. I leave the formulation of a more elegant approach as an exercise for the reader. :-)using System; using System.Collections.Generic; using System.Text; using MySql.Data.MySqlClient; using Microsoft.SharePoint; using Microsoft.SharePoint.Publishing; using System.Text.RegularExpressions; namespace GeeklogMigration { class Program { static void Main( string[] args ) { string connectionString = "Server=localhost;Database=geeklog;User ID=root;Password=password"; string query = "SELECT tid,date,title,introtext,bodytext FROM gl_stories order by tid;"; // connect to the MySql DB that has my geeklog data MySqlConnection dbCon = new MySqlConnection( connectionString ); using ( SPSite site = new SPSite( "http://tylerbutler/sites/tylerbu/" ) ) { // get a publishing site by passing in an SPSite PublishingSite pubSite = new PublishingSite( site ); // Get the root publishing web PublishingWeb rootWeb = PublishingWeb.GetPublishingWeb( pubSite.RootWeb ); // Get the layout to use for the posts PageLayout layout = pubSite.PageLayouts["_catalogs/masterpage/TBPost.aspx"]; // Connect to MySql, execute the query, and get the result set dbCon.Open(); MySqlCommand cmd = new MySqlCommand( query, dbCon ); MySqlDataReader results = cmd.ExecuteReader(); while ( results.Read() ) { // Get the various pieces of data from the result row string title = results["title"] as string; string category = results["tid"] as string; DateTime date = (DateTime)results["date"]; string intro = results["introtext"] as string; string story = results["bodytext"] as string; PublishingPage page; SPListItem pageItem; if ( category.Equals( "books", StringComparison.OrdinalIgnoreCase ) ) { // Get the specific PublishingWeb for the category PublishingWeb web = rootWeb.GetPublishingWebs()["books"]; // Add a new page to the PublishingWeb using the layout page = web.GetPublishingPages().Add( cleanPageName( title ), layout ); // Get the page’s backing list item pageItem = page.ListItem; // Set the category for the page pageItem["PostCategory1"] = "8;#Books"; } else if ( category.Equals( "cool", StringComparison.OrdinalIgnoreCase ) ) { PublishingWeb web = rootWeb.GetPublishingWebs()["cool"]; string pageName = cleanPageName( title ); page = web.GetPublishingPages().Add( cleanPageName( title ), layout ); pageItem = page.ListItem; pageItem["PostCategory1"] = "5;#Cool"; } else if ( category.Equals( "essays", StringComparison.OrdinalIgnoreCase ) ) { PublishingWeb web = rootWeb.GetPublishingWebs()["essays"]; page = web.GetPublishingPages().Add( cleanPageName( title ), layout ); pageItem = page.ListItem; pageItem["PostCategory1"] = "9;#Essays"; } ... more else if statements for each of the categories ... else { // we should never get here... page = null; pageItem = null; throw new Exception( "something went horribly wrong..." ); } // Set all of the page’s properties pageItem["PostAuthor"] = "1;#Tyler Butler"; pageItem["Post_x0020_Time"] = date; pageItem["Title"] = title; pageItem["Comments"] = removeHTML( intro ); pageItem["PublishingPageContent"] = story; // Commit the changes and check the page in (but don’t approve) page.Update(); page.CheckIn( "Migrated from Geeklog" ); Console.WriteLine( "Migrated " + title ); } dbCon.Close(); } } static string cleanPageName( string name ) { // Remove invalid characters from page titles string newName; newName = name.Trim().Replace( " ", "" ); newName = newName.Replace( ":", "" ); newName = newName.Replace( ",", "" ); newName = newName.Replace( ".", "" ); newName = newName.Replace( "?", "" ); newName = newName.Replace( "\\", "" ); newName = newName.Replace( "/", "" ); newName = newName.Replace( "=", "" ); newName = newName.Replace( "!", "" ); newName = newName.Replace( ";", "" ); newName = newName.Replace( "&", "" ); newName = newName.Replace( "*", "" ); newName = newName.Replace( "#", "" ); newName += ".aspx"; return newName; } static string removeHTML( string s ) { // Remove HTML tags from a string Regex r = new Regex( "<[^>]*>" ); return r.Replace( s, "" ); } } }

The code took about 2 hours to write, and the actual migration of the data took around 20 minutes I think. I think this was the right route to go, since crafting the custom PRIME package would have taken at least as long as the code did to write, and this was more straightforward and easier to debug. However, if I anticipated having to do this more regularly, or cared a lot about importing multiple versions or a bunch of documents, then the custom PRIME package would definitely have been the best option.

A couple of things to point out about the code: you'll notice that I set the Person/Group and Lookup fields to values like 8;#Books. The reason for this is because of the way WSS internally stores values of these types. The number is the index of the item in the list (the Users list or the Categories list), and the string is the name of the item in the list. This is admittedly a bit annoying to program with, since you need to not only know the name of the item, but its index as well. I simply hardcoded these values in my code, but you could conceivably lookup the appropriate index values in code and go that route.

Also, the cleanPageName method was necessary because there are certain characters that cannot be contained in a page name in MOSS. Note that this is not the Page title, but the name; the actual name of the aspx page. I wrote this method by trial and error. Every time I got an exception about the title containing an invalid character, I just added some additional logic. I think there's a list of the invalid characters in the WSS SDK; if I find it I'll link to it here.

I hope this code is somewhat useful in illustrating how you can create pages in code, set values of the fields in the resulting page, and check the pages in. You'll find a lot more examples of things like this in the MOSS SDK.

Now that my content was migrated, I had a site that actually looked like a site! I still had a couple of things to do, like creating an "All posts" page, setting up RSS feeds, output the current date and time in my master page, etc. All that and more in my next post! Until next time...

Part 1 :: Part 2 :: Part 3 :: Part 4 :: Part 5 :: Part 6

Customizing the WSS 3.0/MOSS 2007 Menu Control -- MossMenu source code released

LLiu — Sat, 02 Dec 2006 20:37:00 GMT

(Cross-posted from the SharePoint Team Blog.)

The AspMenu class that ships with WSS 3.0 (and by extension MOSS 2007) is nearly identical in behavior to ASP.NET 2.0’s Menu class (as the name implies). AspMenu derives from Menu and adds tweaks to work around a few reasonably well known annoyances and provides improved highlighting support.

Unfortunately, this class was marked sealed and is therefore not eligible to be used as the base class for derived types. Effectively, this means that customers cannot inherit the additional functionality of the AspMenu class when trying to provide further customization of the menu.

We realized this problem too late in the release process and were unable to remove the sealed marker from the AspMenu class that ships with WSS. However, we are instead providing the source code for that class here (as an attachment to this blog entry) under the name MossMenu.

Note: MossMenu is provided as is and will only work on sites built with WSS 3.0 or MOSS 2007. MossMenu relies on some JavaScript which has been included along with the C# source. This is really just for completeness’ sake [aside: some trival about the use of the apostrophe for the possessive forms of nouns] as this script is automatically included on most pages through the core.js script include reference.

Issues with the ASP.NET 2.0 menu, which have been worked around:

1) If the mouse pointer happens to be hovering over a menu item that exposes a fly-out as the page is loading, it is possible that an error dialog will appear stating: "Internet Explorer cannot open the Internet site, Operation aborted" and a blank page will be shown upon clicking OK. It seems that the problem arises from attempting to append to the DOM before it is properly initialized.

2) If SSL termination is employed on a site with a menu, users will be greeted with “This page contains both secure and nonsecure items. Do you want to display the nonsecure items?” when hovering over a menu item which exposes fly-outs. (http://support.microsoft.com/?id=910444)

3) In right-to-left locales, the fly-out indicator arrow still points from left-to-right.

Improvements to default highlighting behavior of ASP.NET 2.0 menu:

· When hooking the menu up to a SiteMapProvider through a SiteMapDataSource, the menu automatically highlights the node that matches that returned by the provider’s CurrentNode property. However, if the particular node returned by CurrentNode is not shown by the menu nothing will be highlighted at all. The improved behavior determines if there is an ancestor of the current node which is displayed in the menu and highlights this node instead.

Hope this helps.

Chris Richard, Software Design Engineer, WCM Features

More MOSS-based Internet corporate web presence sites go live

LLiu — Thu, 23 Nov 2006 02:17:00 GMT

The HedKandi website that was profiled here is indeed very cool, but most of you probably wouldn’t think of showing it to a CIO or a BDM/TDM as customer evidence or reference for SharePoint Server. J Now that we have RTM’d, there will be many more websites that will go live within the next few months. Here are three that you can tell your CIO about:

· ~~Monsanto UK’s (part of a~~ ~~Fortune 500 company) website:~~ ~~http://www.monsanto-ag.co.uk~~ [Oops: They haven't gone live yet!]

· Our first Chinese company (the Rui Jin Hospital in Shanghai) website: http://www.rjh.com.cn

· UCB's (a French bank with 5 million customers) e-banking website: http://www.ucb.fr

And a few more in French:

· http://www.oasys.fr

· http://www.revue-d-etudes.fr

· http://www.formextern.fr

Now, I just need to convince them to put the “Powered by MOSS 2007” badge on their home pages. J

Happy Thanksgiving (to those of you in the world who celebrate it)!