Debugging – Why my Content Editor was so slow

A customer reported to me that their content editor would freeze for 5 minutes if you clicked the root node of their site in Content Editor. I was surprised – bit when I went and did so, it froze for 5 minutes.

Now, this was on a newly upgraded and replatformed system, so I when and tried their existing system – and had the same result. The first click on the root node would take 5 minutes to load. So, it wasn’t our upgrade – but that I could study more easily. As it was the first click only, I figured caching was involved – but what gives? How do I find out what’s going on?

Continue reading “Debugging – Why my Content Editor was so slow”
Debugging – Why my Content Editor was so slow

Out-of-Box Publishing Page layouts suck too

So, might not be news, but SharePoint’s out of box Page Layouts suck. I’ve already described how the page layouts have an image on branding, introducing styles to change the navigation, etc.. This has led me to the conclusion that you shouldn’t use the out-of-box publishing sites – start from a minimal publishing site, and build from the ground up.

But what of customers who have naively thought that, I don’t know, a Collaboration Site Template might be a good template to use for the collaboration site? Well, this is the problem I’ve got now; a customer has used the out-of-box page layouts extensively, and now wants the styles of the text and so on to be consistent. How can I do that? Continue reading “Out-of-Box Publishing Page layouts suck too”

Out-of-Box Publishing Page layouts suck too

Comparison of different ways of putting content into SharePoint 'Pages'

Previously I’ve looked at a couple of ways of entering your data into a Publishing Page. Well, it turns out that really there are 3 ways of putting content in:

  1. Writing content directly using the Content Editor control (the RichHTMLField control)
  2. Writing content in Word 2007 and using the Document Conversion service
  3. Writing content in Word 2007 and cutting and pasting(!)

I decided to test and compare these techniques. For options 2. and 3. I used this document:

The Source Word 2007 Document

Let’s look at the results of this and the code that is behind each resulting page… Continue reading “Comparison of different ways of putting content into SharePoint 'Pages'”

Comparison of different ways of putting content into SharePoint 'Pages'

Modify the RichHTMLField control on your page layouts

When building an intranet, it’s important to try to get consistent styling and formatting, especially if you want to be able to update this later. How do you do this?

To create Pages in SharePoint, you have two options really:

  • Create by hand though the site’s ‘Create Page’ function. Fill in and format your text using the Content Editor Control
  • Create the content in Word, InfoPath, etc., and convert to a Web page using the Document Conversion service.

I’ve been having a bit of a look at this:

Creating Pages through the Web interface

In the SharePoint site, create a new page. Depending on the layout, often they have a RichHTMLField control. In Edit mode, this displays a content editor:

Normal Content Editor Control

and when published, it just displays that content.

However, this control has a lot of options. Editors can adjust text fonts, sizes, colours, boldness – they can even get into the HTML and edit that! I quite like this, but it’s hardly conducive to having a consistent style. What would be good would be to have a number of pre-defined styles, and lock out the other control options.

First, let’s look at removing those option buttons. It turns out that the RichHTMLField control has a number of properties you can set to disable these. This works nicely:

<PublishingWebControls:RichHtmlField id="content" FieldName="PublishingPageContent" runat="server" DisableBasicFormattingButtons="True" AllowTables="False" AllowHtmlSourceEditing="False" AllowLists="False" />

Results in:

Modified Content Editor Control

What I’ve not yet been able to figure out is how to disable the ‘standard html format’ menu thing (the paragraph sign ΒΆ ). I know that it’s for formatting the whole of a paragraph – but we have some problems with that, as we’ll see later. Anyway, now we’ve got those buttons disabled, user’s are MUCH more restricted in the styles that they use.

Second then, how do we define our own styles for the ‘Styles’ menu in the Content Editor? Well, this is a bit more complicated, but there is good documentation out there. Ari Bakker has some good instructions, there’s another (less consise) example from MartyG and there is good documentation on MSDN – though do not believe the top comment, I’ve had my styles working from another CSS file just fine. Do pay attention to the second comment – to see the styles in the menu, you will have to Select some text.

The steps as I found them ultimately were:

1) In your RichHTMLField set the PrefixStyleSheet=”someName”

2) In your styles (whichever one you fancy, as far as I can tell) set up your styles:

.someNameCustom-Heading1 {






3) Publish.

4) Make sure you’ve selected some text, then choose a style:

Editor Styles Menu

Just as a sidebar, there is a fairly good article on MSDN about “How to Create a SharePoint Server 2007 Custom Master Page and Page Layouts for a Web Content Management Site

Anyway what about the next option….

Creating Pages with the Document Conversions Service

First off, this requires that your servers are setup and running the service and your content types are configured set up for it. That’s not too surprising, and I’m not going to go into that any further. I’m also going to look solely at authoring from Word only, and not InfoPath or XML.

Now, things might get confusing here between CSS styles and Word Styles. For simplicity, from here on I’m going to refer to CSS styles with small s (styles) and Word Quick Styles with a big S and italics (Styles).

Once those are services are set up running, you face the same first problem as with the web page authoring – how do we stop users mucking around with our Styles and formatting, except that this time it’s in Word. Well, Word 2007 lets you do this. First, go to the Manage Styles Menu:

Manage Styles in Word

Then on the ‘Restrict’ tab, set the Styles you want to limit users too. This will password protect your template, so that others can’t just undo these settings. Then get users to create their pages using these Styles – they can’t create new Styles or modify the colour/boldness/formatting of the text directly..

Okay, so what happens to the Styles when we upload and convert the document. Well, that depends on the settings you configure for the conversion:

Styles Settings

You can either strip out the Styles from the document, or keep them. Okay, but what does that mean?

Well, Word has a number of ‘default’ Styles – normal, Heading 1, Heading 2, etc. – and there are style definitions of what they should look like in a stylesheet called ‘RCA.css’ (for Rich Client Authoring). In SharePoint Designer you’ll find this in ‘style library > en-us > core styles’ . This defines a the styles for a bunch of Styles
RCA Styles
Click on the image and take a look. You’ll notice that there are css styles for Heading1-P and Heading1-H – we’ll come back to why there are two of each style.

Anyway, returning to what happens to the Styles – if you decide to ‘Remove CSS <styles> section…’ you’ll get a page where your text is formatted as per the styles in RCA.css. This might be quite different to the Styles in your original Word document! Default Styles (Normal, Heading 1, etc.) will be defined by the CSS styles in RCA.css. If you have extra Styles beyond the ‘default’ ones in Word, then they will not have any style, as they don’t have any definition in the RCA.css file. For example, if I define a Styles in Word called ‘Heading 1 Red’, then my page will use css classes called Heading1Red-P and Heading1Red-H. However, in the RCA.css file, there is no definition for these classes, and hence they’ll be unformatted. You can add them though, or you can put them in another stylesheet, etc..

What if you choose to ‘Store CSS <styles>…’? Well, then the CSS definitions for the Styles get stored with the page, and the out-of-box page layouts put this content into the header – but after the RCA.css file has been referenced, so these styles take precedence. Thus, your document will be styled as defined in the document (well, more or less).

Great! Oh, wait, what if I want to change all of my Heading 1 styles and I’m storing the CSS in the page? Well, that’s a problem – ‘cos each page has it’s own definition. Because of that, I would suggest setting up templates with known Styles , locking them down, defining the css styles for those Styles in a CSS file (like rca.css), and then making sure your document conversion ‘Removes CSS‘. If you have gone down the route of having your styles stored with your page, you might be able to fix things by simply removing the FieldValue control that inserts the styles into the page – for the PageFromDocLayout that comes out-of-box, this control is the PageStylesField.

Anyway, you can see why I’m suggesting locking the Styles on your templates – otherwise you might end up with users creating new Styles which aren’t defined in RCA.css, which is pretty painful if you’re then removing the css styles during conversion .

As a side note, what about inline changes to the format of text – what if I change the format of something without creating a new style? Well, those formats are stored inline in the converted page. If, for example, you made some ‘Normal’ Style text red, you’d get the code…

<span style="color:#FF0000">Normal Style + Red</span>

… in your page. Note that this can’t be overridden by style sheets – and doesn’t seem to be removed by either of the Remove or Store CSS options mentioned above. Best to avoid allowing this (returning us to locking down your template again!)

Now, I said I’d return to the question of why two styles for each Style. Well, the short answer is I’m not sure – but it does seem that in Word when you set up a style it applies both to a paragraph (e.g. paragraph spacing), and to a bit of text (e.g. font/colour, etc.). During conversion it appears that to account for this, two styles are required. The converted document’s HTML looks like …

<p class=Normal-P style="margin-top:3pt;margin-bottom:0pt;direction:ltr;unicode-bidi:normal">

<span class=Normal-H><span class="minorAnsiTheme Normal-H">Normal Style</span></span>


…so that might give you some idea. (The text in this paragraph is actually the phrase ‘Normal Style’, and the style applied to it is ‘Normal’).

Final note – and this really caught me out – if you convert a document to a page, then you adjust the document conversion settings and you want to reconvert that page, delete and recreate the page. Updating the page does not seem to change the page, perhaps ‘cos you’ve not updated the document itself.

What about using both?

Well, that’s tricky. The structure of the HTML and the styles are different, so you can’t just apply the same styles as is in the RCA.css file. In principle you can us both in your authoring, but you probably do need to have different definitions for the ‘Heading 1’ style in your Content Editor, and ‘Heading 1’ in your RCA.css file. I’ll blog more about this shortly, but right now I’m tired!

Modify the RichHTMLField control on your page layouts