SharePoint 2013 Display and Rendering Issues

Posted by mjimison on August 01, 2014
2013, CSS, SharePoint, xsl / No Comments

Having trouble with some of your pages in SharePoint 2013 rendering incorrectly at times, for no apparent reason? If so, you’ve come to the right place, provided that what I’m about to describe is actually your issue, and it’s not related to your html or css.

<div id="cbqwpctl00_" class="cbq-layout-main" />

Seems harmless right? It’s a content query webpart in SharePoint 2013 that doesn’t have any results, so this is the html it outputs. The issue, however, is that a div tag is not a self-closing tag, and browsers essentially look at it like <div>, which ends up changing the structure of your document, and will ultimately cause you rendering issues. How did it render in SharePoint 2010? The same exact way – with that self-closing div tag. Wondering why you haven’t seen this issue until now? In SharePoint 2010, tables were a primary part of the html that SharePoint output, and a table essentially protects this little accident from spilling onto the rest of your page. Thus, we never saw it in 2010 because when the webpart rendered it was inside of a table, and that protected the rest of the page. The browser essentially does understand the beginning and ending of the table, and so it is able to correct the initial behavior, and maintain your page’s overall structure.

In SharePoint 2013, however, tables in the standard SharePoint output are gone, and so the above snippet is going to likely wreak havoc on your page. You can fix it in SharePoint 2013 by wrapping a table around your content placeholder or webpart zone, so that what goes inside, ultimately gets contained, but that’s not a solution that I would recommend, since you’re then structuring your document around the technology instead of the content. You might also consider trying to introduce tables through JavaScript, via something like $(“.ms-webpart-zone”).wrap(“<table>…”), but this still won’t resolve the issue, because at this point the DOM has already been loaded, and the browser has misinterpreted it.

A clean solution would be ensuring your xsl templates don’t render self-closing tags for html elements like div and span. A simple way to do this is showing text when there are no results. In fact, when you’re in edit mode, you’ll notice your page likely renders fine, and that’s because the default XSL does output a message when no results are found, but it only shows this message while in edit mode. It’s an easy fix to modify this portion of the XSL and take out the condition in the xsl:if statement that only applies the empty text during edit mode (xsl:if test=”$EditMode = ‘True’ … “). You could also switch this to an xsl:when / xsl:otherwise structure if you wanted to show different empty text to the editor versus viewer (Imagine utilizing style=’display:none’ on the viewer’s output so that they never actually see text, but the structure still remains correct)

Hopefully if you’ve come across this post and it solves your issue, you’ve arrived here sooner than later. I hope this helped out, and please feel free to leave any additional questions or observations in the comments.


Sharepoint Saturday Chicago Suburbs Web Content Management Presentation

Posted by mjimison on May 19, 2014
General, SharePoint / No Comments

I had a blast at the SharePoint Saturday Chicago Suburbs event this past weekend. As promised, I have posted my slide deck online. Feel free to reach out if you have any additional questions!

Slide Deck (PDF)


jQuery Rescue Adventure – SPSIndy

Posted by mjimison on January 15, 2013
2010, JavaScript, jQuery, SharePoint / No Comments

I had a great time over the past weekend presenting “jQuery Rescue Adventure” at SharePoint Saturday, Indianapolis. This was yet another great SharePoint Saturday event, and I’m always honored to play both a part as a speaker and attendee. Below you will find a link to my PDF presentation. In addition, I’ve also supplied a text file with the code snippets we walked through during the presentation.


Responsive Web Design with SharePoint

Posted by mjimison on October 29, 2012
2010, CSS, Design, Responsive Web Design, SharePoint / No Comments

I had the privilege of speaking at SharePoint Cincinnati ScarePoint Cincinnati this past weekend, on October 27, 2012, about Responsive Web Design with SharePoint. The goal of the presentation was really to get everyone to step away from SharePoint as the “thing” and instead get back to focusing on html, css, and JavaScript, because at the end of the day all of the various technologies (SharePoint, PHP, Ruby, Java, ASP.Net, etc…) are seen through the eyes and capabilities of the browser, when it comes to the end user. SharePoint is no more limited in terms of its capability than any other technology; it just at times takes more work to get that clean semantic markup. I have now posted my slides in PDF format for anyone who is interested.


Responsive Web Design with SharePoint


Access Denied When Uploading a File in SharePoint 2010

Posted by mjimison on May 29, 2012
2010, Access Denied, Content Organizer / 7 Comments

I recently came across a situation in SharePoint 2010 where an individual with Owner access to a site was getting an “Access Denied” message each time they attempted to upload a document into one of the site’s libraries. The issue wasn’t related to lacking permissions, as the user could still manage the list and edit existing items.

How to Solve the Issue

Upon further investigation, I found other articles online indicating that it was related to the “Content Organizer” feature being activated, and that the resolution was to disable it. However, in this situation, the “Content Organizer” was a necessary feature. I started digging into the components that make up the “Content Organizer” feature and noticed that there were unique permissions assigned to the Drop Off Library on this particular site, and the Owners group did not have permission to it.

The resolution is to make sure that users have Contribute access to a site’s Drop Off Library, if they need to be able to upload documents into other libraries on the site. This was a bit of surprising behavior, as in this case, the Drop Off Library was only being used with the Official File Web Service, where the Record Center Web Service Submitter account was the only one who would be uploading files to the Drop Off Library.


InfoPath Reference to Undeclared Namespace Prefix: ‘PC’

Posted by mjimison on March 08, 2012
2010, InfoPath, SharePoint / 7 Comments

If you’re working with the Person/Group Picker in InfoPath, and you are using the Eval function to do some concatenation of the individuals selected (see this blog for an example usage) you may have come across the following error:

Reference to Undeclared Namespace Prefix PC

The blog I referenced above even has several individuals pointing out this error in the comments, but there is no resolution to the issue. I came across this same problem, and was fortunate enough to discover the remedy.

How to Recreate the Problem

  1. Design a new ‘Blank’ InfoPath form
  2. Add a Person/Group Picker to the form named ‘People’ and configure the control for SharePoint and multiple selection
  3. Add a Textbox to the control, whose default value is the following formula (Edit XPath):
    xdMath:Eval(xdMath:Eval(../my:People/pc:Person, ‘concat(pc:AccountId, “|”)’), “..”)
  4. Verify the Formula
  5. In InfoPath 2010, you should receive the above error (Reference to Undeclared Namespace prefix: ‘pc’)

How to Solve the Issue

  1. Cancel your formula
  2. Save your form
  3. Close InfoPath
  4. Reopen your form in InfoPath
  5. Reinsert the formula into the default value of your Textbox
  6. Verify the formula
  7. You should no longer receive the error


At the heart of the issue seems to be InfoPath’s inability to recognize the new ‘PC’ namespace from the Person/Group Picker control until it has closed and reopened the form. This is a quick fix to the problem, and I hope that this information was able to assist you.



InfoPath Error: The Control Must Be in the Control Tree of a Page

Posted by mjimison on October 28, 2011
InfoPath, SharePoint / 15 Comments

If you are running your SharePoint Server 2010 environment with the latest August 2011 CU, and are using the External Item Picker control in a browser-enabled InfoPath form, you will receive the following message when the form posts back:

If you look in your Event Viewer, you will see the following exception:

Type: ArgumentException, Exception Message: The control must be in the control tree of a page.
Parameter name: control)

This appears to be a regression in the latest CU, but as of yet there is no fix to the problem.

Update: 01/11/2012
I have received new information on this bug that indicates it may be a part of the February 2012 CU.
Update: 11/08/2011
Microsoft has acknowledged the issue as a bug, and are currently working on a hotfix. However, there is currently no date on when that fix will be available.
Update: 10/31/2011
I have applied the October 2011 SharePoint Server 2010 CU, and the problem still exists.

Steps to Reproduce

  1. Ensure your SharePoint Server 2010 Environment has SP1 applied
  2. Ensure your SharePoint Server 2010 Environment has August 2011 CU applied
  3. Create a blank InfoPath form
  4. Add a Repeating Table with 1 Column (remove the default column)
  5. Add an External Item Picker to the Repeating Table and Configure General Settings (use the External Content Type details page in Central Admin to find the following information):
    1. Set ECT Namespace to the Namespace of External Content Type
    2. Set ECT Name to the Name of External Content Type
    3. Set System Instance Name to External System of External Content Type
  6. Publish the form to a SharePoint Form Library as a browser-enabled form
  7. Launch a new form
  8. Launch the Entity Picker and select a value for the first control in the repeating section
  9. Click ‘Add New Item’ to add an additional item (this forces a postback, which is why I chose the repeating table to easily display the issue)
  10. Upon clicking ‘Add New Item’ you will receive the error


At this point the only workaround to this issue is to not upgrade your farm to the latest CU. If you have already done so, however, then I do not currently have a solution that will solve this issue. I will update this post as I get more information.


Content Type Syndication Hub Event Receiver Issues

Posted by mjimison on September 22, 2011
Content Type, Event Receiver, SharePoint / No Comments

One of the great new features in SharePoint 2010 is the Content Type Syndication Hub, where we can finally achieve global content types. This ability is achieved by creating a site collection that we designate as the hub that pushes content types to web applications that subscribe to it.

Along with the content types and their related site columns, event receivers also come over during this synchronization process. Attaching event receivers directly to a content type is a good way to ensure your code runs wherever the content type is used.

The Issue

I have updated this post to provide detailed instructions on how to reproduce an issue where event receivers in the subscribing site’s content types appear to be removed when a parent content type that they are based off of, which is in the syndication hub, gets updated with additional event receivers.

Here are the steps to reproduce the issue:

  1. Create a content type in the syndication hub, with one or more event receivers attached, and publish it
  2. Create a child content type in a subscribing site based on the content type created in the hub, and add one or more event receivers directly to it (at this point it should have the event receivers from the global content type as well as the new ones added in this step)
  3. Update the parent content type in the hub by adding one or more additional event receivers
  4. Republish the content type in the hub
  5. Once the sync takes place, the child content type no longer has the event receivers that were attached to it, and instead only reflects the event receivers in its parent (I have also found through other configurations where the parent event receivers never make it to the child content type)
Update: 10/31/2011

I have reported the issue to Microsoft, and they have been able to reproduce it, but at this time, I do not have any additional information.

The Fix

The one quick fix to this solution is to reattach any event receivers on your child content types that were removed. However, I am still researching this issue for more information. I will update this post once I have more details.


Introduction to Access Services

Posted by mjimison on September 21, 2011
Access Services, Presentation, SharePoint / No Comments

I had a great time presenting today at the SharePoint Users of Indiana group. The topic I presented was an Introduction to Access Services, and as promised during the presentation, I am now posting my slides online.

Thank you to everyone who came out – it was great to see such a great turnout from the Indianapolis SharePoint community. I definitely encourage anyone who has not yet attended the group to check it out. They meet once a month, alternating between a lunch business presentation, and an evening technical presentation. You can also find additional information on the group at the SPIndiana Facebook site.




View Slides


I had some good questions during the presentation, and I will update this posting in the future to provide additional information.