Archive for October 24, 2014

Hide empty fields on a SharePoint 2013 Page Layout

Nice this is already my second post this month, that doesn’t happen often! This time a little trick to help developers with Custom Page Layouts. I’ve seen quite a few solutions where Custom Page Layouts where used to display content in a sort of Form feel. For instance where all the Content Type fields are rendered with Labels to indicate what the content means. A typical problem with this solution is that whenever you decide to leave the contents of a field empty, still the Label is being rendered. And so is the HTML of the field.

Custom Controls

When searching for a solution lots of BlogPosts pop up about creating a custom ASP control based on the SPSecurityTrimmedControl to manage the rendering like in this Post of Brian Farnhill.

This approach works in an On-Premises environment where moving to the cloud is not an issue. But since I’m a huge fan of Cloud Ready programming I was searching for a different solution.

jQuery for the win

The first open door is to use jQuery on the page for some good ol’ DOM manipulation to make the fields disappear when empty. We can easily work our way through the DOM looking for elements to hide. This is an ok solution but I prefer to have it a little bit more generic. Besides that I took some time to investigate in other Frameworks over jQuery and came across this post:

In short: Libraries and FrameWorks are two different things used for different purposes. Since I’m a fan of data-binding and the abstraction level a framework provides, I decided to use Angular.

Angular for the win

When using Angular this issue can be solved in many ways. I choose to create a controller and applied it to a <div> element that wraps the SharePoint Control that needs hiding. My Page Layouts is looking like this.

Here we have the Display of the Titel Property and a Field calld “DoelGroep” which is a TaxonomyField. Preceding the contents of the Taxonomy field is a label Displaying the DisplayName of the Field.

Wrap the Field

First I have to add the data-ng-app to the top element where all the fields are childs of.
<div class="article-content row" data-ng-app="Empty">

To make sure my Controller works on the specific Fields, I have to wrap those fields with a new HTML element.
<div data-ng-controller="EmptyController"></div>

How my HTML finally looks.

Build the Controller

Now all we have to do is write out the controller. Since we are only wrapping the SharePoint Field that holds content we have to keep in mind to remove its parent since the Label is part of the parent as well.

Edit Mode

Since we don’t want this javascript code to execute when the page is in Edit Mode, we need to add this piece of script to a EditModePanel with DisplayProperties set to View.

That’s it

Just by applying these small changes to the Page Layout (of course make sure AngularJS is loaded). Pretty awesome and practically works with most SP Fields (I haven’t checked them all). Hopefully this will help build a solid solution to deal with empty SharePoint Fields on Page Layouts and is a “cloud ready” solution.

4 Steps to smarter App Part resizing

Wow it feels like forever since I wrote something and finally I got some good new content. I started to research a little bit more on the resizing of App Parts in SharePoint Hosted Apps and came up with some really small changes in basic CSS and JS that make App Part resizing a lot more stable and X-browser compatible. #winning


1. No horizontal scrolling

In this example I’ll use an App that Lists Apps on the Host Web. This particular App displays a list of Title just below one another. Nothing fancy. However when we want to display the page in an App Part, this happens.


Visually it seems that we have more then enough space between the Titles and the end of the IFrame (300px width by default). Still we see a nasty scrollbar! What happened? Inspecting some elements up in the DOM explains a lot. Very funny SharePoint.


The defaultcss.ashx causes trouble! This control is loaded on the page by default in an ASPX page like Default.aspx or most likely by a dev in a plain HTML page to keep default SharePoint branding alive in the App. That is a good principle, but this width style is not really helping us out.

Full Width Power

In order to get rid of the scrollbars in this scenario there’s a simple CSS fix we can apply in our App.css.

#contentBox { min-width:100%; margin:0; }
#contentRow { padding:0; }

This way we make sure no weird margins or paddings will cause our App Part more pain and it’s also going to help us when resizing the WebParts height later on.


Better! Now the content, that we know for sure should fit, actually fits. Width wise. Still the height of the App Part is not right.


2. Resize your App Part

Resizing App Parts using the postMessage technique is nothing new to most people. We need a function in our App that sends a message to the parent of the IFrame. SharePoint can pickup this message and then resizes the IFrame for you using a given width and height. I used the following code

resizeIFrame = function (height, width) {
 if (window.parent == null) return;
 var senderId = '';
 var params = document.URL.split("?")[1].split("&amp;");
 for (var i = 0; i &lt; params.length; i = i + 1) {
  var param = params[i].split("=");
  if (param[0].toLowerCase() == "senderid")
   senderId = decodeURIComponent(param[1]);

 //Bug for self reference in href='#'.
 senderId = senderId.replace('#', '');
 var message = "<Message senderId=" + senderId + ">"
 + "resize(" + width + "," + height + ")</Message>";
 window.parent.postMessage(message, "*");

In this common piece of code I added a check for “#”. When this is used in the App (I came cross it once), the QueryString is extended with this “#”. This causes the SenderId, which is always last in the QueryString, to be compromised and the Resize function from SharePoint to fail!

Function call

To call this function we first determine the height of the DOM element that holds all the content. The width shall be “100%” to have an App Part that will always fill the entire space.

var height = jQuery('#OverView').outerHeight(true);
var width = "100%";
resizeIFrame(height, width);

This function resizes the entire iframe to the dimensions given.


But wait! there is still a vertical scrollbar! Something must be wrong. In the Elements File of my ClientWebPart I removed the Height and Width properties of the App Part.


Here is where a very weird phenomenon shows itself. Since we don’t have any requirements set regarding width or height, SharePoint sets a default width and height to the AppPart which is the same as the ClientWebPart xml states when it is just created.


Here our default width is 300px. The funny bit is that because we use the ResizeIFrame method, the width is only set to 100% after the Resizing is done. To make it even more complex, the Height is meisuring the content that now is rendered within 300px width. Therefor the height also cannot be trusted. This makes the resizing of the App very buggy. Now we see it still as 300px width. Refreshing a couple of times shows 100% width but still with a vertical scrollbar and height that is just a couple of px off. Some DOM element must be holding back some padding info.


3. Body Container

Again the main obstacle here is some styling that comes from defaultcss.ashx. By default the CSS sets a padding-bottom:35px; on #s4-bodyContainer. This is why we add to our App.css this piece as well.

#s4-bodyContainer { padding:0; }


Instantly this is starting to look good! The App Part now scales over the entire width of the Page using a correct height and most important: NO scrollbars! Since I placed my App Part in the text part of this SitePage it is displayed in full width. When I use a Publishing page with multicolon WebPart Zones, it will also adept to the width of the colons. This comes in very handy for instance with use of Bootstrap.


4. One last thing

One last nag, which is actually really tough. Thereby I don’t mean the fix, that ones easy. I’m talking about consideration on how to deploy the fix. The thing is, as I just explained, the height is calculated at the wrong time in rendering. In order to get the height right, the IFrame must have it’s width set to 100% first. We’ve seen SharePoint set it to a default value of 300px. When a dynamic list of <span>’s wrap over 3 lines for instance, the height at a 100% width is very different from the height at 300px width.

A fix here can be set all IFrames to a default width of 100%. I don’t see why you shouldn’t do that in the first place. But still it depends right.

Custom CSS

The best option in my opinion is to use the capability to upload and add your custom CSS when using Publishing Sites. You can do this in the MasterPage section of the Site Settings. Just create a blank CSS file and add

iframe{ width:100%; }

When you aren’t using publishing sites, there is another possibility.


You can add some code to your App to deploy a UserCustomAction to the HostWeb. In the UCA you can add a ScriptBlock that writes this CSS style to every page. This is a dangerous option when not done right. Waldek wrote about these things and explained why it can break your site. The following code will do so, but keep in mind that everytime this executes another UCA is created. You still have to create a “Run Once” type of mechanism.

P42.ScalingAppPart.setFrameWidth = function ($) {
 var execute = function () {
  var deferred = $.Deferred();
  var hostUrl = decodeURIComponent(P42.Utils.getQueryStringProperty("SPHostUrl"));
  var appWebUrl = decodeURIComponent(P42.Utils.getQueryStringProperty("SPAppWebUrl"))

  var context = new SP.ClientContext(appWebUrl);
  var factory = new SP.ProxyWebRequestExecutorFactory(appWebUrl);
  var appContextSite = new SP.AppContextSite(context, hostUrl);
  var site = appContextSite.get_site().get_rootWeb();
  var userCA = site.get_userCustomActions();

  var customAction = userCA.add();

  context.executeQueryAsync(function () {
  }, function (sender, args) {
   deferred.reject(sender, args);

  return deferred.promise();

 return {
  execute: execute

Famous Last Words

These steps will get you some smoother App Part resizing experience that will work cross-browser. By removing all the extra margins and paddings you are now in control over the exact width and height of your App Part. I never got it right untill I put some work in it, hopefully this post will help you too getting it right.

– Cas