Posts Tagged ‘Master Pages’

Wednesday, July 23rd, 2008

SharePoint Branding Issues: Edit In Datasheet View

For a couple of weeks now, I’ve got some reports about crashing datasheet views when using custom master pages. As a reminder, the datasheet view is a view you can select when browsing within a list. It’ll enable you to view and edit the list in an excell-like format. Quite handy for bulk changes.

So, what is happening? I noticed the page was going into an infinite loop. When debugging I stumbled upon the GC-functions. Those functions are located in core.js and control the resizing of the datasheet view control. After carefull reviewing, I noticed the document.documentElement.scrollHeight was growing and growing. It seemed that my custom master page let the scroll height go out of it bounds.

To fix this, I simply bound the scroll height to the client height. To accomplish this, you look for

var lGCWindowHeight=document.documentElement.scrollHeight;

in core.js and replace it with

var lGCWindowHeight=(document.documentElement.scrollHeight>document.documentElement.clientHeight) ? document.documentElement.clientHeight : document.documentElement.scrollHeight;

This seemed to solve the problem and stopped the browser from crashing.

But why was this happenning? My best bet is the use of a specific doctype in my masterpage. In quirks mode, IE includes top and bottom borders and padding widths when calculating the offsetheight. Standard mode only defines the content height as offsetheight. I’m guessing core.js relies on the extra margins. Now, the strange thing is, the custom master pages of MOSS (BlueBand, OrangeSingleLevel, …) do not experience this bug, altough they also use a specific doctype. I didn’t really investigate into it too much, but I suspect they restrict the height of some container surrounding the main content. This could stop the growth of offsetheight. If anyone of you, readers, can confirm this behaviour, feel free to respond in the comments.

In the meantime.. have fun branding!

Update: according to reader Rufino, you can also revert this behaviour by specifying a height. Didn’t test it yet, but I’m pretty sure this ‘ll do the trick too. Thanks Rufino!

Tags: , , , , , , ,
Posted in Branding, SharePoint | 1 Comment »

Monday, December 3rd, 2007

SharePoint Branding Issues: Calender View

Back again for a SharePoint branding issue, and this time we’ll tackle the calender. More specifically its calender views: the day and the week view. Let me first show you, how the week view should look like:

SharePoint Branding Issue: Calender view on default.master

As you can see, an appointment can cover multiple hours. This way you have a graphical overview of how much time appointments will take. This, however, is how it looks like on the other MOSS master pages:

SharePoint Branding Issue: Calender view on MOSS master pages

This is not what we expected. Appointments now only cover a small fragment of the time to take, while the rest stays blank. It is very confusing for the user. And some appointments seem to pointlessly be in different columns. The day view experiences the same kind of problem. What is this weird voodoo? We did not change anything to the calender, now did we?
Well, no, we didn’t. But we did change the looks of it by changing how the looks are parsed. As I already mentioned in another article a couple of weeks ago, the other MOSS master pages use a (correct) doctype declaration, while the default master page does not even contain one:

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd“>

Make no mistake, this is a declaration HTML pages should contain. Otherwise, you have no clue how browsers will render the page. Internet Explorer falls back to its “quirk mode”, where everything is “kinda” allowed. Other browsers will just try to render the page. And this is what we experience in the calender views. The inner box of the appointment has a CSS property: height equals 100% to make the appointment cover the whole time slot space reserved in the table of the view. In the doctype declared version, this is only supported if all parent elements also have a CSS height equal to 100%. Of course, this is not the case for all its parents. That’s why the appointments get shortened.

Is there a solution? Well, no solutions, only workarounds, I’m afraid.

  • Remove the doctype declaration from the master page. I don’t really advice it, but it can do the trick. Make sure other browsers still display the master page correctly. Future browsers can break the layout however. (this is what SharePoint did for the default.master)
  • Rewrite the views. You could make the views compatible with current standards, but it’ll cost quite some time to develop.
  • Have SharePoint show the default.master for the calender views. It’s an ugly workaround, as you’ll have different layouts in your site, but it works.

Once more, a very unfortunate branding issue. Aspecially, because it could have been prevented by generating correct HTML. Hopefully this kind of bugs will be resolved in future SharePoint versions. Till next time.

Tags: , , , , ,
Posted in Branding, SharePoint | 2 Comments »

Monday, October 29th, 2007

SharePoint Branding Issues: Application Pages

Application pages are those special pages within SharePoint that share functionality accross sites. Some examples include the site settings, the list settings, each setting page within those settings, the All Site Content pages, the personal settings pages, etc. A way to directly recognize one of these pages is to look at the URL of the accessed page. If the url contains this segment “/_layouts/”, you are dealing with an application page. Why? Well, the /_layouts/ directory is a virtual directory created by IIS and is available to every created SharePoint site. You can access every page within the layouts directory by simply adding the path to your site url. For example: http://www.host.com/subsite/_layouts/settings.aspx. But where does this path redirect? The _layouts virtual directory is mapped to a fixed directory within the SharePoint hive, more specifically: C:\Program Files\Common Files\Microsoft shared\web server extensions\12\TEMPLATE\LAYOUTS\. So, every page within this directory is accessible through the special \_layouts\ directory.

Another way to recognize these pages is that, if you use a master page other than the default one, the application pages still seem to use the default master page. I write “seem”, because although the appearance seem to be the same, it is a different master page. This master page is also located within the layouts directory and is called application.master.

If you want a complete make-over of your SharePoint site, chances are you’ll want to change the appearance of those pages. One way to do this, is to edit the application.master master page. This can be a valid solution if your whole farm uses the same master page, as all application pages of the sites on your server use this system master page. So, if you change the master page, the changes will be visible on all instances. Most of the time, however, you have different sites on your server with different branding needs. So this approach is usually out of the question.

My solution consists of altering the application pages themselves. Although this is not a recommended practice, as Microsoft is not supporting this (Service packs could overwrite the changes), sometimes it’s the only option left. Let me show you what to add:

<script runat="server">
protected override void OnPreInit(EventArgs e)
{
base.OnPreInit(e);
MasterPageFile = SPContext.Current.Web.CustomMasterUrl;
}
</script>

Basicly we’re assigning, at run time, a new master page to the application page. Application pages can use the SPContext object to find out the context in which they are called. From this object we extract the current site (a SPWeb object) and assign the CustomMasterUrl property as the application page’s master page. This will do the trick just fine.

An important note to this solution, regards the master pages themselves. Master pages for application pages need to support two extra content place holders, PlaceHolderPageDescriptionRowAttr and PlaceHolderPageDescriptionRowAttr2. As these place holders don’t seem to do much, you can just add those two tags within a hidden ASP.NET panel to your master page.

<asp:ContentPlaceHolder id="PlaceHolderPageDescriptionRowAttr2" runat="server" />
<asp:ContentPlaceHolder id="PlaceHolderPageDescriptionRowAttr" runat="server" />

If you are using this technique, be sure to add these tags to the default.master master page in the SharePoint hive and this for compatibility reasons with the other sites. Of course, do not forget to add them to your custom master page too, as this is usually the reason, in the first place, to apply this solution.

A nice extension would consist of making the Application Pages Master Page of a site selectable through the UI (in MOSS) for selecting a master page. You could then use the SPWeb property bag to save the master page url.

Untill next time, happy sharepointing.. :-)

Tags: , , , , ,
Posted in Branding, SharePoint | 3 Comments »

Tuesday, October 16th, 2007

SharePoint Branding Issues: MOSS Search Center

When searching in MOSS, your results are shown in the search center. This is a special site you can create within your MOSS site collection. When using the default master pages, everything looks nice. The search box is in some blue area, while results get listed on the page. So far, no problem.

Search in default.master Search results in default.master

Say you want to develop a new master page. You take your basic place holders and arrange them on your page, the way it best fits your design. One of those placeholders is called PlaceHolderTitleBreadcrumb. What does this place holder contain? You might have guessed it, it should contain the breadcrumb of the page. And this is very crucial. Master pages are a technology which rely on “design by contract“. This is a special way of designing based on trust. In our master page we add content place holders to enhold specific parts of page. We give them specific locations and identifiers and we expect the correct functionality in it. Sadly, this is not always the case.

The search center is one of those areas not respecting the content place holders. Let’s look what will happen, when changing the master page of our site. (And once again, I’m just switching to a MOSS master page)

Search in OrangeSingleLevel.master Search results in OrangeSingleLevel.master

As you can see, the layout of the pages is somewhat disturbed? Why? The page layouts, which are used in those pages, give another meaning to our PlaceHolderTitleBreadcrumb place holder. They have the complete search box logic in it. A valid question here would be: why? Well, my guess is: the search looks nice when used in the default master page. They wanted to distinguish the search box area from the results. So they added the search box in the PlaceHolderTitleBreadcrumb. Now, for people who have moved this place holder (to the top, for example) within their custom master page, this can be a serious problem.

The solution, per se, is not that complicated, nor hard to apply. You just open up the two page layouts (SearchMain.aspx and SearchResults.aspx in your site collection’s masterpage catalog) move the search boxes from the PlaceHolderTitleBreadcrumb to the PlaceHolderMain. And you’re done, quite simple. But this is not where the problem resides. What to do with your other search centers in your farm? … Let me think… How about altering the files directly on the disk in the 12 Hive? This way, when provisioning, the search centers will have a nice layout in all master pages? Ok, but what if your distributing the thing? Well, in this case, one could provide some altered page layouts to use, and dynamically switch the old ones to the new ones in a feature receiver. And so on, and so on…

I hope most of you will realize these practices are mere patching up work. They are not giving a real solution. Sadly, most of the times, this is what we have to do to get things done. The true solution consists of conventions, and keeping them applied. Unfortunately, in a team as big as the development team of Office, this can be quite cumbersome. Hopefully they’ll keep that in mind for next iterations, and try to be more consistent. :-) Until next time!

Tags: , , , , ,
Posted in Branding, SharePoint | 1 Comment »

Friday, October 12th, 2007

SharePoint Branding Issues: Table Of Contents WebPart

On one of my projects I had to customize the table of contents webpart. This webpart can list pages, lists and subsites of a specific site, and this in a custom organization and presentation. When using it on the default master page, it shows the content in different levels with some nice indentation applied to it.

Table of Contents using default.master

But when I activated my custom master page, the indentation suddenly did not show. My first reaction was: “OK, this surely is some classic CSS problem. I’ll just set the correct class back in my custom CSS file.” However, whatever I tried, whatever CSS rule I put in, the indentation did not come back. Worse, there’s already margin applied to the elements, hard coded in the webpart. But Internet Explorer did not seem to wanna show it when using my master page. And this was only the beginning…

When stripping down both the default master page and my custom master page down to the bare necessities (no css files, no other controls, … nothing), the default master page still showed the indents while my master page didn’t! And to get even more confused, the other MOSS master pages do not show the margins either! This is weird.. very weird. What the hell makes the difference?

Table of Contents using OrangeSingleLevel.master

And then it hit me. My master page and the MOSS master pages use following code, where the default.master does not:

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd“>

For those of you who do not know what this is, you can read all about it over here . Basicly, it instructs the browser how to parse the HTML and CSS. How is this relevant, you ask? Well, as I said, the table of contents uses some inline code to display the indentation.

      <div style="margin-left:12;">

At first glance, this seems spot on, correct. Except, it isn’t. Though the default behaviour of Internet Explorer would accept this line. When using the doctype, Internet Explorer demands more precision and clarity. What kind of clarity? This kind:

      <div style="margin-left:12px;”>

Yes, indeed, it’s the unit. Doctype requires correct values and units. And if those are not available, the browser will simply ignore the values. So what are the implications? All MOSS master pages and custom master pages, using this kind of doctype, will not show the identations. Talking about a bug.. ;-)

The solution, of course, is adding the ‘px’ unit to the style. Luckily, the table of contents is one of those webparts which uses XSL style sheets to format its data and makes those available in the Style Library within your SharePoint site collection. Once inside this style sheet (LevelStyle.xsl), one can easily add the px to the different styles using the margin. This creates an instant solution to the problem. If you want to apply this to your entire farm, go to your server and adjust the LevelStyle.xsl in the PublishingResources feature.

Fixed Table of Contents using OrangeSingleLevel.master

For the aftermath: this is sort of a silly problem. It could have been easily prevented. Nevertheless, these kind of problems are very hard to track down. My fear is this is not an isolated case and there could be more of those little ‘bugs’ within SharePoint, due to inconsistent use of CSS. This is quite a shame, I think, for such a rich product. :-(  But anyway, what have we learned today? Always set your units in CSS! ;-) See ya next time.

Tags: , , , , , ,
Posted in Branding, SharePoint | 9 Comments »

Monday, October 1st, 2007

SharePoint Branding Issues

As promised, I am writing a series of blogposts regarding issues you may encouter when developing a custom branding solution for SharePoint. Customers usually want to customize the out of the box design SharePoint is offering. It often simply does not reflect their company’s branding. SharePoint uses master pages and CSS to provide a consistent look throughout their pages. But when developing a custom design, you will notice it is not that easy to customize the things you want. So how do I tackle this?

I always create a custom master page. Why do you ask? The master pages SharePoint provides do not always provide CSS support on all it tags, and codewise the HTML is not really clean. The number one thing to remember when developing a minimal or custom master page for SharePoint is that SharePoint expects a number of PlaceHolders to be within the master page.  If there’s some content in a placeholder you don’t want to be available on the page, don’t simply remove the place holder. Move the place holder within a hidden ASP panel.
So is that it? Obviously, no. SharePoint makes extensive use of controls within its pages. You can add and remove them at your discretion. Though there are a couple one which are pretty critical to ensure SharePoint running correctly. Namely, You better declare a SPWebPartManager on your page, otherwise WebParts won’t work. Another thing is to include the form tag right after the beginning of the body tag. This to ensure pages can be posted. Some other controls you might want to include, but which aren’t necessary include wssuc:Welcome, PublishingSiteAction:SiteActionMenu and PublishingConsole:Console.

In short:

  • add a form tag (don’t forget the JS wrapper functions)
  • include all place holders
  • add a WebPartManager control

So, now you have your master page. What about the CSS? SharePoint uses the CSSLink control to add references to their CSS files, of which core.css is the most important. The default way to do CSS in SharePoint is to overwrite the SharePoint CSS in custom CSS files. Unfortunately this method can be quite cumbersome, as core.css seems to be a SS rather than a CSS. They don’t really use the cascading part of style sheets. So, you have to overwrite multiple classes before a change comes through, and sometimes it’s impossible to overwrite a style whithout changing another style too.
My preferred way to work is to remove the CSSLink control altogether and use my own stylesheets. I have two. The first one is a CoreLight.css. It encapsulates only the most necessary classes from core.css and the ones who mostly do not have to be customized. Of course, I cleaned up this style sheet. This is a file I reuse with each project and keeps getting better with each project. The other file is the CSS specifically for the current project. It’ll define the styles, colors, layouts, typography the project uses.

In short:

  • do not use CSSLink
  • create a CoreLight, which incorporates the necessary core.css classes (and others)
  • create a specific stylesheet, where you define project related resources.

Mind that this way to work may not be the most recommended with SharePoint guidelines. It just makes my work far more easier. I can redesign a whole site within one work week. It is up to you to use the method you’re more at ease with.

This was my global approach for custom SharePoint branding. Following articles will deal with some specific issues when creating a custom SharePoint branding.

Tags: , , , ,
Posted in Branding, SharePoint | No Comments »