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.

Continue reading

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:

Now it has changed to this:

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.

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.

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:

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”.

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.

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.

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.

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.

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:

to this

The script below will manage this transformation:

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.

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

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.

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

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.

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:

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

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.

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:

 

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.

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:

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

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.Continue reading