Category Archives: User Interface

Removing and Replacing Default SharePoint Ribbon Styles

SharePoint 2010 (and most likely future versions) provides default styles in the ribbon. You can see these with the “Styles” and “Markup Styles” sections of the ribbon. Here is an example of the “Markup Styles” section in action.

Default Markup Styles

What if a client does not want the default ones in there? You could overwrite them in CSS, but most likely your client will not want all of the default ones available. The way to change this is to use the PrefixStyleSheet attribute on the RichHtmlField in your page layout. Here is an example of it in action using the default column for publishing content. (This is also where you can disable other parts of the ribbon using attributes such as AllowFonts=“False” to turn off the font selection option in the ribbon.)

<PublishingWebControls:RichHtmlField PrefixStyleSheet="mystyle"
FieldName="PublishingPageContent" runat="server">
</PublishingWebControls:RichHtmlField>

Changing the prefix for the custom styles will now remove them from the ribbon. Now using the following CSS, you can add selections to the “Styles” and “Markup Styles” section. (As a note, the default CSS prefix is “ms-rte”.)

/* Add to Styles Section */
.mystyleStyle-Bold   {
  -ms-name:"Bold";
  font-weight: bold;
}
/* Add to Markup Styles Section */
h3.mystyleElement-Title   {
  -ms-name:"Heading 3";
  font-size: 30px;
}

Now you can see your custom styles in each dropdown. Notice that the “Markup Styles” styles necessitate an element on the selector.

Our New Markup Styles

Using Custom Styles in Content Editor Web Parts

One of the caveats of this method is that it doesn’t work in content editor web parts. So, if a user were to try and add a content editor web part and edit the text, not only would they see the old default styles, but our custom ones would be gone. I thought that was just the way it would be until I found this post on the MSDN forums. In it, someone shares a bit of jQuery that allows us a similiar behavior on the content editor web parts as the publishing HTML fields.

jQuery(document).ready(function ($) {
/* Enable custom stylesheet prefix for CEWP */
ExecuteOrDelayUntilScriptLoaded(function() {
   $("div[RteRedirect]").each(function() {
      var id = $(this).attr("RteRedirect"),
      editSettings = $("#" + id);
      if(editSettings.length > 0 && editSettings[0].PrefixStyleSheet != 'mystyles') {
         editSettings[0]['PrefixStyleSheet'] = 'mystyles';
      }
   });
}, "sp.ribbon.js");
});

2 Replies

Using a DOCTYPE in SharePoint 2007

While SharePoint 2007 certainly moved the platform forward for its time, there is no doubt that doing UI work with the CMS is nothing short of excruciating. The reason for this is (a) really, really bad markup and (b) no DOCTYPE (SharePoint Designer doesn’t help the cause either). There is a lot you can do to deal with the first issue, but you’re largely stuck on the second.

The reason adding a DOCTYPE is problematic is because adding the DOCTYPE to the master page makes core functionality break like moving web parts between zones, and all the default styles are not made to work in browser’s standards mode. The best way to get around this would be for the DOCTYPE only to show when the page is in “display” mode but not in “edit” mode. (If you need to develop custom master pages for the “System Master Page” then I would not suggest using this solution because it will cause more heartache then it’s worth.)

To do this we need to include a content placeholder at the top of the master page.

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

Then, in our layouts, we can include the following EditModePanel that will only output what we have in display mode. Keep in mind that all attributes are necessary to include. It would be nice if we could just include the code block belowin the master page, but it doesn’t work (I presume because it isn’t in the form tag).

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

<PublishingWebControls:editmodepanel PageDisplayMode="Display" SuppressTag="True" 
runat="server" id="doctypeedit">

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" 
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

</PublishingWebControls:editmodepanel>

</asp:Content>

Add this CSS to fix alignment on the site actions menu.

.ms-MenuUILabel {
	text-align: left;
}

Thanks to Carlos Fernandez for working through this with me.

UPDATE: Turns out I needed an addition content placeholder to include the X-UA Compatibility Meta Tag. If I didn’t include it I had issues with the browser mode changing effectively. You can’t reuse the same content placeholder because the meta tag belongs in the head.

4 Replies

Advanced Metadata Techniques in Page Layouts

When SharePoint unveiled their web content management functionality in 2007, they included the practice on inline editing directly into the content management experience. While they were by no means the first to do so, I feel strongly that they did a very good job considering it was their first iteration of the technology. User interface developers creating page layouts can very easily integrate the editing of metadata directly into a page layout very easily by dragging columns from the “Page Content” section in the toolbox panel of SharePoint Designer. But what if we have some more advanced layouts, and when we try to add metadata into the editing experience? It actually makes the editing experience much less attractive.

Case in point, here is an event page layout for the new Portal Solutions site built in 2010 (the methods described in this post will work in 2007, but all sample code is tested in 2010). As you can see, I have a section that highlights details about the event, and this section is a smaller, floated column on the right. Dragging the columns from the toolbox into the page layout produces a rather ugly content management experience.

A picture of an unoptimized page layout editing experience

A Rather Ugly Experience

The forms that are added inline throw off the layout. You can also notice that I also have a styled button, and putting this page into edit mode actually makes that metadata column incomprehensible. Clearly, we need a better solution.

Using the Read-Only Metadata Value Control

Thankfully the platform provides us some tags that allow us to change how this works. Instead of using a single control that does both the edit mode and display mode we can split the two. Here is what the code looks like when I simply drag and drop the column from the toolbox (this is the address column which actually OTB).

<SharePointWebControls:NoteField FieldName="fc2e189e-ba91-48c9-9dd3-16531afddd50"
   runat="server"></SharePointWebControls:NoteField>

What this control does is in display mode it only pulls the value of the column, but in edit mode it adds the form to support editing the value. We need the ability to separate the two display modes to make for a better experience, and I will show you how.

But first let me direct your attention to that nasty GUID in the snippet above. That comes from SharePoint Designer 2010 by default, and what we really want to use there in the FieldName attribute is not the GUID but the internal name for the column (in SP Designer 2007 it correctly pulls the internal name). While this code might work for a one-off, it certainly won’t work in a scenario where we need to publish these page layouts particularly in a feature deployment. If you didn’t create the column with a feature you can find the internal name by simply opening up the column in edit mode inside the UI (Site Settings » Site Columns » Your Column Name), and in the title bar it will tell you the internal name after the ?field= in the URL (be sure if you create the name in the UI to keep the column name all one word when first creating, and then you can go back and add spaces).

A screenshot of finding the internal name for a column.

The Column’s Internal Name

Now let’s look at a special control that only pulls the value from a column, and even when it’s in edit mode it doesn’t show a form. This truly is a column in read-only mode. This snippet uses the same address column.

<SharePointWebControls:FieldValue id="WorkAddress" FieldName="WorkAddress"
   runat="server"></SharePointWebControls:FieldValue>

This is much better! Technically, the ID can be whatever you want, but be sure to coördinate to with a developer if they are working with this in any way and need to know the ID. I usually keep the ID and the FieldName the same, but that is at your discretion. Now let’s replace all the columns with this read-only control and see what this looks like in edit mode.

A screenshot depicting column values pulled with read-only access.

A Much Better Appearance

Adding Back in the Editing Experience

This is looking good, but we still want the ability to edit the values for these columns inline. To do this I add a section at the bottom of the page dedicated to editing metadata. I still keep the rich HTML fields (Publishing Page Content) in the page where they display (if I’m using it), but I move all other columns down below (and sometimes depending on the situation I even put publishing HTML fields in this metadata zone as well). To accomplish this we are going to use the EditModePanel control from the same toolbox panel (in the SharePoint Controls » Server Controls section) to add content into the page that only displays when the page is in edit mode.

<PublishingWebControls:EditModePanel runat="server" id="PageMetadata">

<div class="pagemetadata">

<h4>Edit Page Metadata</h4>

<SharePointWebControls:TextField FieldName="Title" runat="server"></SharePointWebControls:TextField>
<SharePointWebControls:DateTimeField FieldName="EventStartDate" runat="server"></SharePointWebControls:DateTimeField>
<SharePointWebControls:DateTimeField FieldName="EventEndDate" runat="server"></SharePointWebControls:DateTimeField>
<Taxonomy:TaxonomyFieldControl FieldName="EventType" runat="server"></Taxonomy:TaxonomyFieldControl>
<SharePointWebControls:UrlField FieldName="RegisterLink" runat="server"></SharePointWebControls:UrlField>
<SharePointWebControls:NoteField FieldName="WorkAddress" runat="server"></SharePointWebControls:NoteField>
<link href="/_layouts/1033/styles/Themable/forms.css" rel="stylesheet" type="text/css" />

</div>

</PublishingWebControls:EditModePanel>

This will allow the content contributor to have a much more streamlined experience particularly in pages where you have a significant amount of metadata you want to offer to edit inline. The column controls I’m using above are similar to the ones provided by the toolbox (with the GUIDs replaced with internal names), but with the EditModePanel it only shows the form layout to edit when the user asks for it in a much better layout.

The one thing to notice is the inclusion of a SharePoint stylesheet that styles the HTML from the controls added when the page is in edit mode. I noticed sometimes the stylesheet didn’t come through, so to alleviate I just included it. It only renders when in edit mode so it’s not an unnecessary HTTP request for viewing content only, and even if it is already included it shouldn’t cause you a styling issue unless you want to overwrite these form styles (in that case remove that reference above).

Here is what the edit metadata zone looks like in edit mode which I put under the page content. I didn’t do much with it style-wise in this screenshot, but you could add some nice touches depending on your desires or needs.

A screenshot showing editing metadata in edit mode.

The Dedicated Metadata Editing Area

Siolon

Musings on SharePoint, User Experience, and More