Article
3 comments

Hide toolbar / hero button in list view web part using JSLink

To hide the tool part of a web part is pretty easy. You just need to edit the settings and set them to “No Toolbar” and you are done.
Today I needed to do this programmatically. After I debugged the list view web part an haven’t found a setting for this I took a look into the “clienttemplates.js”, which is mostly responsible to render the views correctly and voila I found a solution how to hide the toolbar.

[Read more]

Article
6 comments

Safer request form fields in list forms using JQuery

Mark Anderson published today an article on his blog concerning an issue that currently exists in Office 365 and is called “Office 365 Update Changes ‘Display Name’ on Required Fields”. In this article he described that the rendering of fields recently have been changed in Office 365. I will take a look what can be done to solve this probably.

The cause of the problem

The title attribute of list fields have been widely use to customise forms in SharePoint using JavaScript, JQuery or SPServices. I used this attribute sometimes too do address fields by the display name. But somehow I always had a bad feeling about this. Why? Well, the ID attribute of the field is the only real unique identifier in the form. The downside using the ID is that you need to have some information about the field to generate the ID. But I will explain this later.
What the update recently in Office 365 did was to change the rendering of the field. Previously it look like this:

<select id="Region_59566f6f-1c3b-4efb-9b7b-6dbc35fe3b0a_$LookupField" title="Region">

Now it has changed to this:

<select id="Region_59566f6f-1c3b-4efb-9b7b-6dbc35fe3b0a_$LookupField" title="Region Required Field">

As you see now the title has additional parts such as required or field. This means that you haven’t in this attribute the display name of the field alone and you will fail if you query by title.

Safer approach to request fields

As mentioned before the ID property is the only one that is unique in the whole page. The ID is formatted in the following form:
Field name + ”_” + Guid of the field + ”_$” + Type of the field.
As seen in the previous section the ID looks like this:
Region_59566f6f-1c3b-4efb-9b7b-6dbc35fe3b0a_$LookupField
So if you like to be absolutely sure and like to generate this ID by yourself you need to do a request to the list and read the fields. The you will be able to find the name by the display name, the id and the type. This will make some lines of code that you can reuse in your projects. I haven’t seen any ready made code yet but I’m sure it can be found somewhere over the internet. (If you have would be great to post that in the comments)
I looked into this problem and what I found was that SharePoint does that job for you and stores it on the form in the JavaScript variable “WPQ2FormCtx”.

Console output of WPQ2FormCtx Object

Console output of WPQ2FormCtx Object

This context is somehow new in SharePoint 2013 and Office 365 This somehow represents the so called form context with a lot of information. Also included in this variable is the list schema which we can use without loading any additional information from the list.
So what I did is that I created a small javascript object that loads the information and allow me to generate the id of the field. The tricky part i currently not have implemented is the type part because this is a little bit tricky and the value changes with the different configurations of the fields. I hope that the following code give you an example how this works.

<script>
/* Handles the field of the form */
var fieldDefinitions = {
  Fieldname: [], // Stores all the display names of the field
  Fields: [], // Stores the complete field configuration
  // This function formats the list schema for easier acces
  ParseSchema: function(formContext){
  		var schema = formContext.ListSchema;
    	for(var field in schema)
    	{
			this.Fieldname.push(schema[field].Title);
    		this.Fields.push(schema[field]);
    	}
  },
  // Genereate the Fieldname and Field Guid Part
  GetIdByTitle: function(title){
	var index = this.Fieldname.indexOf(title);
	var currentProp = this.Fields[index];
	console.log(currentProp);
	// return the beginnng of the ID in the format 
	// FieldName (encoded) + "_" + Guid of Field
	return currentProp.Name + "_" + currentProp.Id; 
  }
};

$(document).ready(
    function () {
		// Reformats the form context   	
		fieldDefinitions.ParseSchema(WPQ2FormCtx);
		// returns the calulated ID of the field
		var fieldID = fieldDefinitions.GetIdByTitle("Region Field");
		// Wildcard request to the field 
		// sets the value of the Region Field
		$("input[id^="+fieldID+"]").val("Works");
    }
)
</script>

To this script the last part needs to be added to be 100% sure. Think about the fill in option for example this will start with the same id but I’m sure there will be added a special type.

Field after update via JS

Field after update via JS

As you see the value was written to the form

A Look to the future

I will never use the title field again. I write this now 100 times to keep it in mind. But not here in this blog post. In future I will reuse my little helper object for a simple reason. If Microsoft changes the format of the ID attribute I only need to change it at a central location instead of search and replace all my jQuery / JavaScript code.
Convenience is not everything better go an extra mile to be safe.

Article
1 comment

Optimise HTML Output of the Rich Text Editor – “-ms-Element” explained

One big prejudice is that SharePoint is not capable to produce clean HTML output via the rich text editor. This was somewhat true with the previous versions of SharePoint. In SharePoint 2013 this has improved and can output all basic text elements without any additional style sheet classes.

How is this possible? By using the magic “-ms-element” attribute.

Element behaviour in the past

To explain how this works in the current version we need to take a look back to the rich text editor definitions of SharePoint 2010. To show I picked out the style definition for the “Header 1” element. This will be rendered as <h1 class=“ms-rteElement-H1”> .

The definition in the “corev4.css” goes like this:

H1.ms-rteElement-H1
{
    -ms-name:"Heading 1";
}
.ms-rteElement-H1
{
    font-size:2em;
    font-weight:normal;
}

The first definition is not a visible style. It is more an indication for the rich text editor that there exists a style definition for an H1 element. The label for the drop down is defined by the “-ms-name” attribute, a Microsoft specific vendor prefix. The H1 prior the classname defines the element that should be rendered.

The second style definition contains then the style that should be applied to the H1 element.

SharePoint 2010 - Rich text editor format and source code

SharePoint 2010 – Rich text editor format and source code

This worked perfect, but every single paragraph, list and headline had those classes assigned. Due this classes the file size increases.

Something to worry about? Let’s take a look how the browser handle those styles and tags.

Rendering in the browser

The most important style sheet files is the “corev4.css” in SharePoint 2010 and the “core15.css” in SharePoint 2013. Both files are huge and have a lot of design information. How will those files rendered by the browser internally?

The browsers follow a clear logic how they render all the elements and style definitions.

  1. Parse all tag styles (eg. H1, H2, P,…)
  2. Parse all class style definitions (eg. .ms-rteElement-H1)
  3. Parse all ID style definitions

“This hierarchy is the reason why sometimes ‘!important’ needs to be used because a style definition of a class gets overruled by an ID definition.”

This parsing goes all through the DOM and requires some time. Once the style is known by the browser the rendering commands will be sent to the render engine and the content gets displayed. To optimise the overall output performance, we just want to have clear HTML element with easy to identify the styles of those.

This is not so important for desktop browsers, but think about mobile devices and the bandwidth you have there. The structure of the HTML and the CSS have direct impact on the user experience, especially on older devices.

Optimise the HTML output using -ms-element

In the style sheets of SharePoint 2013 in some places a mystical new vendor prefixed attribute have been introduced. Mystical because there is a big lack of official information on this.

I research this behaviour. From my experience this attribute is responsible to render only the HTML tags instead of output it the old fashioned way like it was in SharePoint 2010. To explain how this works, let’s use the definition of the “Header 1” once again. First, we take a look at the code that can be found on various places in the “core15.css”.

/* Style 1: General definition of H1 */
h1, .ms-h1
{
	/* [ReplaceFont(themeFont:"large-heading")] */ 
	font-family:"Segoe UI Light","Segoe UI","Segoe",Tahoma,Helvetica,Arial,sans-serif;
	font-size:2.3em;
	/* [ReplaceColor(themeColor:"SubtleBodyText")] */ 
	color:#777;
	font-weight:200;
}
/* Style 2: HTML Definition to add the style to the drop down */
H1.ms-rteElement-H1
{
	-ms-name:"Heading 1";
	-ms-element:"true";
}
/* Style 3: Output optimisation */
.ms-rtestate-field h1,
h1.ms-rteElement-H1,
{
	line-height:1.4;
	/* [ReplaceColor(themeColor:"ContentAccent1")] */ 
	color:#0072C6;
}

The first part of the style shows the general definitions of all H1 tags wherever this will be used in the source code (Style 1).

The second definition (Style 2) defines as before that the editor should list “Heading 1” style in the rich text editor drop down and then there is the “-ms-element” attribute. So this means when a user browses the content only the H1 tag is included in source code. All without any additional class on the header.

The most important part is the third because it shows two different definitions. The “.ms-rtestate-field H1” definition is used for the view mode only. “.ms-rtestate-field” is the style sheet class that encapsulates the rich text editor content while H1 identifies the child tag.

The definition for “h1.ms-rteElement-h1” is the same definition as we had in SharePoint 2010 but now it will be only used for the edit mode. You will see this if you take a look at the source code during editing.

SharePoint 2013 - Rich Text Editor format and Source Code

SharePoint 2013 – Rich Text Editor format and Source Code

Now the content will be rendered differently in display and edit mode. Therefor both definitions are required to display the content correctly.

Summary

As you see now the rich text editor is able to output clean HTML code for all typographic standard elements. Every modern web content management use this. So does SharePoint. The benefit of this is that content migration from other systems is now easier because all that is needed is only plain HTML. Another benefit of this is that it has a positive effect on the SEO ranking of a public facing web site.

Customisation can be done if easily now because all that needs to be define are styles for the standard text element.

Article
1 comment

Remote form customization in modal dialogs

You might know this situation, when you like, for example, pass a query string to a modal dialog to preselect values in a list form. With SharePoint Designer or custom development this is an easy task. What if you like to customize the form without permanently modifying the form itself?

In this post series I will show my newly discovered way to have better control over forms.

How come? Well over the last week I had the request once again, to pre-fill a list form with values from another list. So I was thinking to myself that there must be a better ways to do this task. Lucky me I found one.

In the next posts I will first introduce you to the basic concept of this kind of customization.

The series is planned to contain the parts:

In all these parts the customisations will be done using JavaScript / JQuery and our best friend SP Services, when it comes to SharePoint customization. In all those part I leave the form dialogs untouched. No additional web part on the forms will be used.

Hope you enjoy this series and maybe I will add some additional chapters at the end.

Article
14 comments

Use Syntax Highlighter in SharePoint Rich Text Editor

Love it or hate it, but the rich text editor can be really powerful if you know how to customize. In this article I show you how the well-known SyntaxHighlighter script by Alex Gorbatchev can be added to a wiki page in SharePoint. The idea for this came from a discussion I had with Marc D. Anderson about the Microsoft SharePoint Blog template and how hard it is to format source code in SharePoint in a beautiful way. Well nearly every WordPress blog that provides source code in the posts has a plugin that adds the SyntaxHighlighter to the design. Well here is my integration to SharePoint that consists of the following three components:

  • Wiki Page Layout
  • Rich Text Editor Style
  • Script to embed the SyntaxHighlighter

The wiki page layout

First of all I created a specific wiki page layout to add the functionality of the SyntaxHighlighter. In this page layout I added references to a couple of scripts the SyntaxHighlighter need. I added those inside the content control with the id “PlaceHolderAdditionalPageHead”. This will render the script links to the head section of the master page.

<asp:Content ContentPlaceHolderId="PlaceHolderAdditionalPageHead" runat="server">
	<SharePoint:CssRegistration name="<% $SPUrl:~sitecollection/Style Library/~language/Core Styles/page-layouts-21.css %>" runat="server"/>

	<!-- Basic Style Definition -->
    <SharePoint:CssRegistration name="<% $SPUrl:~sitecollection/Style Library/SyntaxHighlighter/styles/shCoreDefault.css %>" runat="server"/>
    <SharePoint:CssRegistration name="<% $SPUrl:~sitecollection/Style Library/SyntaxHighlighter/SPIntegration/spSyntaxHighlighter.css %>" runat="server"/>

    <!-- Syntax Highlighter and SharePoint Integration -->
	<script type="text/javascript" src="/Style Library/SyntaxHighlighter/scripts/shCore.js"></script>
	<script type="text/javascript" src="/Style Library/SyntaxHighlighter/scripts/shBrushJScript.js"></script>
    <script type="text/javascript" src="http://ajax.aspnetcdn.com/ajax/jQuery/jquery-1.8.2.min.js"></script>
    <script type="text/javascript" src="/Style Library/SyntaxHighlighter/SPIntegration/spSyntaxHighlighter.js"></script>

	<PublishingWebControls:EditModePanel runat="server" id="editmodestyles">
		<!-- Styles for edit mode only-->
		<SharePoint:CssRegistration name="<% $SPUrl:~sitecollection/Style Library/~language/Core Styles/edit-mode-21.css %>"
			After="<% $SPUrl:~sitecollection/Style Library/~language/Core Styles/page-layouts-21.css %>" runat="server"/>
	</PublishingWebControls:EditModePanel>
</asp:Content>

Beside the SyntaxHighlighter I added one style sheet file for the integration to the rich text editor named spSyntaxHighlighter.css and a JavaScript I named spSyntaxHighlighter.js which will be used to render the source code in a proper way and uses JQuery.

Rich Text Editor Styles

To add a format block for the source code I defined for each language a specific rich text editor style. The format block using markup styles looks like this.

pre.ms-rteElement-CodeHTML{
    -ms-name: "Codebox HTML";
    border: 1px black solid;
}

What this markup style definition does is to add the <pre> tag to the content of the wiki page. For each language that should be supported I created an own markup style needs. This is required because it tells the SyntaxHighlighter script how to render the source code properly.

Script to embed the SyntaxHighlighter

As mentioned before I decided to use JQuery to execute the syntax highlighter script. Well the base task of my script is to look for the code blocks defined by the markup styles and then reformat those blocks. For an html code block the output of the rich text editor needs to be converted from:

<pre class="pre.ms-rteElement-CodeHTML">
       <p>Example paragrah in syntaxHighlighter</p>
</pre>

to this

<pre class="brush: js;">
       <p>Example paragrah in syntaxHighlighter</p>
</pre>

The script below will manage this transformation:

$(document).ready(function () {

    $("pre.ms-rteElement-CodeHTML").each(function () {
        addSyntaxStyle($(this), "brush: js");
    });

    SyntaxHighlighter.all();

})

var addSyntaxStyle = function (code, brush) {

    code.removeAttr("class");

    /*** Fixing IE stuff ***/
    var trimedCode = code.html().replace(/<br>/g, "\r\n");
    trimedCode = trimedCode.replace(/<br \/>/g, "\r\n");
    trimedCode = trimedCode.replace(/<BR \/>/g, "\r\n");
    trimedCode = trimedCode.replace(/<BR>/g, "\r\n");
    trimedCode = trimedCode.replace(/<BR\/>/g, "\r\n");
    trimedCode = trimedCode.replace(/<br\/>/g, "\r\n");

    code.html(trimedCode);
    code.replaceWith("<pre class='" + brush + "'>" + trimedCode + "</pre>");

}

For Internet Explorer I need to break the rendering of the source code inside the pre tag. The internet explorer adds additional breaks to the code. Therefore all html breaks needs to be removed and replaced “\r\n”. If those <br> tag won’t be managed the code will be messed up and the result would be only a single line of code instead of a good looking code block.

SyntaxhHghlighter integrated in SharePoint

Final code integrated in SharePoint

Usage

Sometimes it can be a little bit tricky to handle the rich text editor in the right way. For code embedding the best result can be achieved if the style block will be defined in the first step and later the code will be added by using the SharePoint functionality “Paste as plain text”. I recorded a simple video to show you how this works.

[vimeo 51020830 w=660&h=411]

At the end you should get the following result.

Finally you can download this sandbox solution from Codeplex “n8d.SyntaxHighlighter”.

My integration of the SyntaxHighlighter supports currently the following languages:

  • VB, C#
  • HTML, XML, XHTML
  • JavaScript
  • SQL
  • PowerShell
Article
11 comments

Lookup fields as site column declarative deployed

In this article I like to show you my way to deploy lookup fields to SharePoint declarative. I need to note that I won’t do this fully declarative but found a solution that works best. This will be used by SharePoint internally and is fully supported. The lookups I’m talking are lookup fields deployed as site column.

Whenever it comes to content types and site column in my opinion the best way is to create them declarative. The reason for this is that I can handle that all deployed fields have the same GUID that I defined and every Site Collection has the same fields with the same IDs. Simple field types such as text, number, Date and Time, User Fields, Yes/No Fields can be created easily using the declarative approach but with lookup fields this can be a little bit trickier. During the last weeks I did a couple of interviews with Becky Bertram, Doug Hemminger and made a poll on SPYAM. The result of this was that most people deploy or create lookup fields using code and not using the declarative approach. Here is the result of the poll.

SPYam Poll for creating lookups

SPYam Poll on how creating lookups as web site columns

But now let’s take a look how to create a lookup field.

Creating the Lookup Field

The basic declaration of a lookup field looks simple and you can reference the List by using the URL of the web where the site column will be deployed to. This can be done according to the documentation as long as the list will be deployed in the same feature as the lookup column.

<?xml version="1.0" encoding="utf-8"?>
<Elements xmlns="http://schemas.microsoft.com/sharepoint/">
    <Field ID="{6C798145-A205-4FC4-8175-837B0F7744CC}"
     Type="Lookup"
     SourceID="http://schemas.microsoft.com/sharepoint/v3"
     DisplayName="Colors"
     Required="false"
     List="Lists/Colors"
     ShowField="LinkTitleNoMenu"
     UnlimitedLengthInDocumentLibrary="TRUE"
     Group="N8D Fields"
     StaticName="Colors"
     Name="Colors" />
</Elements>

In a second module I created a basic list instance with a custom list.

<?xml version="1.0" encoding="utf-8"?>
<Elements xmlns="http://schemas.microsoft.com/sharepoint/">
  <ListInstance Title="Colors"
   OnQuickLaunch="TRUE"
   TemplateType="100"
   FeatureId="00bfea71-de22-43b2-a848-c05709900100"
   Url="Lists/Colors"
   Description="">
 </ListInstance>
</Elements>

Both elements will be deployed in the same feature which means that the reference of the lookup should match the list and replace the token List URL with the value for “Lists/Colors” with the GUID. The problem is that after the deployment the lookup column looks like this.

Lookup field after declarative deployment

Lookup field after declarative deployment

If you go to the definition of the lookup column the list is empty and won’t be displayed correctly and the field won’t work with lists. The empty “Get information from” is one reason that people create lookup fields using code. As always in SharePoint many ways lead to a solution and a lot of people have created their own provisioning classes to create site column lookup fields, but here comes the good news. This problem can be fixed some simple modifications of the field configuration using code.

Fixing declarative Lookup Field

From my experience the problem is that SharePoint won’t replace the List URL token with the GUID of the list and the web. When you like to use site columns as lookup fields than you have to get those GUID somehow to the schema of the fields. The URL token in Site columns cannot be used because site columns need to have a reference to the GUID of a list and a web. Then SharePoint will be able to find the matching list and web where the lookup should reference to. A sub site cannot make use of a list with the value “List/Colors”.

A quick solution would be to create the list first and the web first and add the GUID in the field definition. Works great as long as you don’t like to reuse the lookup field in another site collection. In this case you have to change the GUID when you like to deploy the solution to another web application or sites. Not really a great option.

My solution is to add the GUIDs to the schema of the field definition and use the List URL as a token to find the proper list. This can be done with a simple feature receiver. The code for this looks like this.

public override void FeatureActivated(SPFeatureReceiverProperties properties)
{
    SPSite targetSite = properties.Feature.Parent as SPSite;

    using (SPSite site = new SPSite(targetSite.ID))
    {
        using (SPWeb web = site.OpenWeb())
        {
            SPField lookupField = web.Fields.TryGetFieldByStaticName("Colors");

            if (lookupField != null)
            {
                // Getting Schema of field
                XDocument fieldSchema = XDocument.Parse(lookupField.SchemaXml);

                // Get the root element of the field definition
                XElement root = fieldSchema.Root;

                // Check if list definition exits exists
                if (root.Attribute("List") != null)
                {
                    // Getting value of list url
                    string listurl = root.Attribute("List").Value;

                    // Get the correct folder for the list
                    SPFolder listFolder = web.GetFolder(listurl);
                    if (listFolder != null && listFolder.Exists == true)
                    {
                        // Setting the list id of the schema
                        XAttribute attrList = root.Attribute("List");
                        if (attrList != null)
                        {
                            // Replace the url wit the id
                            attrList.Value = listFolder.ParentListId.ToString();
                        }

                        // Setting the souce id of the schema
                        XAttribute attrWeb = root.Attribute("SourceID");
                        if (attrWeb != null)
                        {
                            // Replace the sourceid with the correct webid
                            attrWeb.Value = web.ID.ToString();
                        }

                        // Update field with new schema
                        lookupField.SchemaXml = fieldSchema.ToString();
                    }
                }
            }

        }
    }

}

The code above does the following tasks:

  • Get the Field
  • Get the list that should be referenced by the lookup
  • Change SourceID and List to the GUID of the web and list.

Without using the feature event receiver the field looked this:

<Field 
    ID="{6C798145-A205-4FC4-8175-837B0F7744CC}" 
    Type="Lookup" 
    SourceID="http://schemas.microsoft.com/sharepoint/v3" 
    DisplayName="Colors" 
    Required="false" 
    List="Lists/Colors" 
    ShowField="LinkTitleNoMenu" 
    UnlimitedLengthInDocumentLibrary="TRUE" 
    Group="N8D Fields" 
    StaticName="Colors" 
    Name="Colors" />

After the deployment with the feature event receiver the field looked like this:

<Field 
    ID="{6C798145-A205-4FC4-8175-837B0F7744CC}" 
    Type="Lookup" 
    SourceID="f22f83b7-8d4d-4111-a154-714ca309633a" 
    DisplayName="Colors" 
    Required="false" 
    List="aaec4791-2991-4537-b19a-7106e5ffc9fd" 
    ShowField="LinkTitleNoMenu" 
    UnlimitedLengthInDocumentLibrary="TRUE" 
    Group="N8D Fields" 
    StaticName="Colors" 
    Name="Colors" 
    Version="1" />

SharePoint incremented the version number of the field after the changes have been applied to. The manipulation of the schema using the object model is fully supported by SharePoint but you need to take care that your modification are set with a proper xml that matches the field schema definitions. You will find this comment in the SPField.SchemaXML on the MSDN. There is not much difference in setting the schema of a field or create a field directly from XML using AddFieldAsXML.

A second look to the column settings shows that everything will be displayed correctly.

Lookup field after modified schema

Lookup field after modified schema using feature receiver

If you like to try this yourself you can download the solution N8D.Lookup.

Some other recommended Information on lookup fields I used previously was.

Article
3 comments

Deploy Content Type and Document Templates to Office 365 and SharePoint 2010

One of the best concepts in SharePoint are them hierarchical definition of content types that has been first introduces in SharePoint 2007. New content types could be defined by small variations made easily by developer or end users. All document based templates could be assigned with a specific document template that would be used in libraries. If someone has predefined Document Templates that could be assigned with the content type, they could be uploaded or deployed.

Xml Definition of content type with document template

The solution to deploy document templates and content type together in a solution consists of two parts:

  • The content type definition
  • A module for the template file

The first part of this solution is just a xml content type definition with the parent content type set to “Document”. A DocumentTemplate inside the content type definition was specified, which points to the defined template file. The content type looks as follows:

<!-- ContentType: Document (0x0101) -->
<ContentType ID="0x01010064db413f63314bbbb9e4cd59d461beff"
    Name="MyNewContentType"
    Group="Developent Content Type"
    Description="My Content Type"
    Inherits="TRUE"
    Version="0">
    <DocumentTemplate TargetName="MyNewContentTypeTemplate.docx">
    <DocumentTemplate>
    <FieldRefs>
    </FieldRefs>
<ContentType>

 

In SharePoint every content type has its own folder where templates will be stored, no matter if the content type is deployed through a solution or a template file has been uploaded via web the browser. These folders are located in the root of the site collection beneath the _cts folder. This folder can be found in the SharePoint Designer. Once the root of the site collection has been opened in SharePoint Designer and on the left side of the navigation “All Files” has been selected the _cts folder gets visible.

SharePoint Designer content type location

SharePoint Designer content type location

SharePoint Designer content type folder

SharePoint Designer content type folder

The second part of the solution is a module that has word document which will be deployed to the folder of the content type.

<Module Name="MyNewContentType">
  <File 
    Path="MyNewContentType\MyNewContentTypeTemplate.docx" 
    Url="_cts/MyNewContentType/MyNewContentTypeTemplate.docx" Type="GhostableInLibrary" />
</Module>

On solution deployment, first of all the content type is created that reference the template file. Later the module will make sure that the template file could be located in the correct content type folder and make the template file accessible.

After the deployment the content type and the template can be accessed through SharePoint and used in any desired document library.

Content Type inside SharePoint

Content Type inside SharePoint

Content Type in SharePoint with Template

Content Type in SharePoint with Template

SharePoint Farm Solution, Sandboxed or SharePoint Online aka Office 365

This solution works in all the common deployment scenarios no matter where it should be deployed. This is because no custom code is required.  The complete code for this only uses a couple of lines xml definition and looks like this:

<Elements xmlns="http://schemas.microsoft.com/sharepoint/">
  <!-- Parent ContentType: Document (0x0101) -->
  <ContentType ID="0x01010064db413f63314bbbb9e4cd59d461beff"
               Name="MyNewContentType"
               Group="Developent Content Type"
               Description="My Content Type"
               Inherits="TRUE"
               Version="0">
    <DocumentTemplate TargetName="MyNewContentTypeTemplate.docx">
    </DocumentTemplate>
    <FieldRefs>
    </FieldRefs>
  </ContentType>
  <Module Name="MyNewContentType">
    <File 
      Path="MyNewContentType\MyNewContentTypeTemplate.docx" 
      Url="_cts/MyNewContentType/MyNewContentTypeTemplate.docx" Type="GhostableInLibrary" />
  </Module>
</Elements>

For those who like to try the solution can download the VS Studio Solution or the WSP File.

Article
3 comments

Boxes and positioning – Enhance rich text editor – Part 2

Part one was all about the basics of customizing the rich text editor. This part will show some advanced CSS styling definitions. For a nice looking text layout are boxes handy to position side notes, images, videos or any kind of elements beside the content.  The rich text editor has already defined boxes in the markup styles drop down called callouts but they have a fixed position defined. I also will show enhancements for positioning any kind of element.[Read more]