One of the improved capabilities of SharePoint 2013 is embedding widgets in rich content. And while it seems to just work at the first glance, it can be very inconvenient in certain scenarios.
Widgets as a part of rich content
With the explosive growth of social media in the last years, more and more content is created and shared on different networks. Referring to that content from rich content is a powerful mechanism that the web offers us to further enrich its value.
The idea of linking to content on the web using hyperlinks is not new and while it just works, it has its limitations. By following the link the user leaves one context and moves into another. This scenario is far from user-friendly especially if you want to discuss some external content. Widgets – short snippets of HTML markup, offer a great alternative, as they allow you to embed the content directly within your page. In this approach your visitors have direct access to the external content without losing the context of your website.
Widgets and SharePoint
The concept of embedding external content using widgets is not new and has been around for quite some time now. In the past working with widgets in SharePoint was quite challenging. The main reason for this were the security features implemented in the rich text editor used by SharePoint for creating and managing rich content. Because of the security features all of the widgets markup would be removed from the rich content. The only way to embed widgets was to use Web Parts, which in the past couldn’t be mixed with content.
With the introduction of Web Parts in content, SharePoint 2010 made it easier for us to embed widgets in rich content. While the security features of the rich content editor would still not allow us to embed widgets directly in content, we were offered the ability of adding Web Parts containing those widgets in content.
In SharePoint 2013 the support for embedding widgets has been improved even further. A new option called Embed Code has been introduced that allows us to embed widgets in page.
Depending on the widget, it will embed it either as-is or in a special Script Web Part; in both cases assuming that the user editing the content has sufficient permissions to embed widgets.
The distinction between the so called script-safe widgets (which are embedded as-is) and script widgets is exactly the reason of the inconvenience.
Inconvenient widgets and search-driven publishing
One of the new capabilities introduced with SharePoint 2013 is the new search-driven content publishing model, where SharePoint 2013 Search is used to publish the content between different Site Collections, Web Applications or even Farms. After indexing, the content becomes available to any number of publishing sites, assuming they have access to the Search Service Application that has indexed that content.
One of the consequences of using search-driven publishing is, that, as it’s based on search, it only publishes the indexed content. The binaries or the Web Parts are not included in the index and therefore not published using search-driven publishing.
Inconvenient widgets: a sample scenario
To illustrate you the problem, let’s take look at a sample scenario. Let’s try to include a YouTube video and a SlideShare presentation on a publishing page that is going to be published using the new search-driven publishing model. For the YouTube video we will use the following widget:
<iframe width="560" height="315" src="http://www.youtube.com/embed/4pY-GEprwAY" frameborder="0" allowfullscreen></iframe>
For the SlideShare presentation we will use the deck from my latest presentation on the SharePoint Evolution Conference in London:
<iframe src="http://www.slideshare.net/slideshow/embed_code/19008586" width="427" height="356" frameborder="0" marginwidth="0" marginheight="0" scrolling="no" style="border:1px solid #CCC;border-width:1px 1px 0;margin-bottom:5px" allowfullscreen webkitallowfullscreen mozallowfullscreen> </iframe> <div style="margin-bottom:5px"> <strong> <a href="http://www.slideshare.net/waldekm/p-m307-building-intelligent-websites-with-sharepoint-2013" title="P&M307 Building intelligent websites with SharePoint 2013" target="_blank">P&M307 Building intelligent websites with SharePoint 2013</a> </strong> from <strong><a href="http://www.slideshare.net/waldekm" target="_blank">Waldek Mastykarz</a></strong> </div>
As you can see, both snippets are very similar: they are both basically an iframe and the SlideShare snippet contains some additional text and a link to my other presentations.
So what do we get if we try to insert those two snippets on a publishing page in SharePoint 2013?
When embedding the YouTube widget everything seems to be okay:
However when we try to embed the SlideShare widget SharePoint will present us with a slightly different experience:
First we get a warning that the widget will be embedded as a Web Part. Then, after we pressed the Insert button, we will see how different the two widgets are displayed:
While the YouTube widget is embedded directly in the page, the SlideShare widget has been embedded as a Web Part.
Should you publish this page now using the new SharePoint 2013 search-driven publishing model, you will only see the YouTube video.
The only thing that is left of the SlideShare widget is the HTML markup reference to where the Script Web Part is supposed to be placed, but the Web Part itself isn’t there.
So why is this happing exactly, and, what’s more important, is there anything that we can do about it?
As I mentioned before SharePoint 2013 distinguishes between two types of widgets: script-safe widgets and script widgets. When embedding widgets in rich content, script-safe widgets are embedded as-is. Script widgets on the other hand are embedded within Script Web Parts. As script widgets are more complex, they require more permissions comparing to script-safe widgets to be embedded in rich content, which is additional security measure to ensure for the security of the publishing site.
For a widget to be script-safe it has to fulfill two requirements. First of all it may not contain a script **** tag. Secondly its contents must originate from a script-safe domain. SharePoint 2013 contains a configurable list of script-safe domains, which by default contains the following domains:
Looking back at our two widgets: even though our SlideShare widget didn’t contain any script tags, the slideshare.net domain isn’t listed in the list of safe domain what causes the whole widget to be marked as script-unsafe and therefore embedded using a Web Part.
If you decide to trust SlideShare widgets and allow your users to embed them in rich content, the only thing that you need to do is to add the slideshare.net domain to the list of safe domains. This is a per-Site Collection setting that can be done using the following PowerShell code snippet:
$site = Get-SPSite http://mavention $site.ScriptSafeDomains.Add('slideshare.net')
After running this code snippet your users will be able to embed SlideShare presentation snippets similarly to how they embed YouTube videos.
As script-safe widgets are a part of the rich content they will also be published when using the search-driven publishing model.
Should you want to remove a domain from the list of script-safe domains, you can use the following PowerShell code snippet:
$site = Get-SPSite http://mavention $site.ScriptSafeDomains.Remove('slideshare.net')
SharePoint 2013 contains improved support for embedding widgets in rich content. Unfortunately in some scenarios widgets get embedded as Web Parts which will prevent them from being published when using the new search-driven publishing model. For some widgets adding the domain of the originating site to the list of the script-safe domains can prevent them from being embedded via the Script Web Part and make them available for publishing using the search-driven publishing model.