De Dutch Information Worker User Group (DIWUG) is de Nederlandse community rondom SharePoint en de wereld rondom de 'information worker'. Tijdens de aankomende community avond worden een tweetal presentaties gegeven over relevante onderwerpen rondom het SharePoint platform.

Om 18.00 uur start de avond met een hapje en een drankje. Na een korte introductie door Mavention zal Marianne van Wanrooij (Connected Solutions) starten met een sessie over de nieuwe Office integratie features in SharePoint 2013. Stefan Strube (2die4 it solutions) vertelt aansluitend hoe je als power user de zoekresultaten er beter uit kan laten zien, zonder dat je er een ontwikkelaar bij hoeft te roepen! Zoals gebruikelijk wordt de avond afgesloten met een SharePint!

Mavention heeft dit event al verschillende keren mogen organiseren en hoopt ook dit keer weer op een hoge opkomst en een interessante avond. Kijk voor meer informatie over de Diwug op de, door Mavention gerealiseerde website, www.diwug.nl Inschrijven kan via deze site.

Now as most things in SharePoint the answer to the result of that discussion is: ‘it depends’.

If you would enter your URL to your SharePoint environment like:

http://SomeIntranet

While IIS knows your site as

http://someintranet

You would be redirected correctly, without any errors or hassle. However if you would have a wrong casing in your RootFolder when uploading documents might end up in the wrong place, as is proven in a blog post about SharePoint is Case-Sensitive.

Having that in mind I didn’t take much risks and always used the correct casing in my URL’s having no problem with it. However I recently was called in on a project that had a strange issue: For some of the users of an intranet the reply’s they made on discussions were not stored and posting them didn’t give an error. Now for most of the users their replies showed up perfectly so my first thought was to check the ULS logs to make sure there were no exceptions thrown when posting replies.

Since there was nothing there I moved up to ruling out the usual, but since there was no real pattern I didn’t find much usefully, and was not able to reproduce the error. However at some point it struck me that if there weren’t any errors the replies should be there. So I created a view that actually showed all items (by default a Discussion board list only shows the ContentType Discussion), and all the ‘missing’ replies showed up in the rootfolder instead of the discussion. Since discussions are some sort of folder with extra metadata it all started to make sense. If the wrong URL is used the reply cannot be saved to the correct discussion. So I dug up the IIS logs and checked all the reference URLS.

Now that is where it all started to become a bit frustrating though. Within SharePoint there are two ways to enter a discussion. You could either use:

http://someintranet/list/discussionboard/My%20First%20Discussion

Or you could use the following:

http://someintranet/list/discussionboard/view.aspx?RootFolder=http%3A%2F%2Fsomeintranet%2Flist%2Fdiscussionboard%2FMy%2520First%2520Discussion%20

Both of these URLs will end up serving you with the same discussion. Now in both discussions you would have the reply button allowing you reply to any given question. If you would hit reply you would always end up with an URL that looks like this:

http://someintranet/list/discussionboard/NewForm.aspx?RootFolder=http%3A%2F%2Fsomeintranet%2Flist%2Fdiscussionboard%2FMy%2520First%2520Discussion%20&ContentTypeId=0x0107&DiscussionParentID=17

After some playing around the DiscussionParentID I figured it can be safely deleted from the request, as it seems not to be used anywhere. Leaving only the RootFolder parameter there. Now if you would have wrong capitalization there you would end up with replies in the rootfolder instead of the discussion. So while checking the IIS logs for the request that were made and having the ULS logs to check what happened there I managed to figure it out. If you would enter the following URL

http://SOMEINTRANET/list/discussionboard/My%20First%20Discussion two things will happen. Your URL will be translated to the lowercase version that is the correct one but not before a RootFolder parameter is constructed containing the wrong capitalized version of your URL, ending up in something like

Now as you can see spotting a difference in the URL above (a wrong one) and the working one above that is quite hard, and since it will not throw an error or log anything about not being able to store to the correct discussion figuring it out took me a bit longer then I wished for. What happens under the head is that SharePoint constructs the rootfolder parameter before it rewrites to the corrected URL this having a ‘wrong’ rootfolder parameter. The logic that constructs the rootfolder also implements some caching thus every time a rootfolder parameter is already present it will take that into account. So once you hit a discussion wrongly (with: http://SOMEINTRANET/list/discussionboard/My%20First%20Discussion) you have a wrong RootFolder parameter, and every call from within that discussionboard will fail when replying to a discussion.

So whenever you are missing replies in your discussion board make sure to check the rootfolder for replies and make sure you are not reference some wrongly capitalized URL :-).

Originally posted at http://www.sharepointappie.nl/inconvenient-rootfolder-parameter-in-discussions/ 

On June 11 in Utrecht, The Netherlands Microsoft Netherlands organizes a day-long event focused on the new and improved capabilities that SharePoint 2013 offers for building public-facing websites.

During this SharePoint 2013 WCM Bootcamp you will learn how to build websites using responsive web design and bring your website to live using the SharePoint 2013 content publishing capabilities. Additionally you will learn how to plan, design and build websites by making the best use of the new functionality that SharePoint 2013 offers you.

The event will consist of two tracks: one focused on the user experience side of public-facing websites and one focused on their architecture. Together you will have a unique opportunity to learn how to build great websites with SharePoint 2013.

I will be presenting sessions in the architecture track. Other presenters are Fredrik Holm (Senior Program Manager Lead at Microsoft, where he leads a team that is responsible for Web Content Management features in addition to many Search based features) and Josh Stickler (Program Manager at Microsoft, where he's responsible for a variety of SharePoint 2013 Web Content Management features, including the Design Manager and Variations).

Register now for the WCM Bootcamp and see you in Utrecht on June 11.

Originally posted at http://blog.mastykarz.nl/sharepoint-2013-wcm-bootcamp-netherlands/

SharePoint 2013 Search-driven publishing

One of the great improvements in SharePoint 2013 is the search-driven publishing model, where the content is published using SharePoint 2013 Search. A particularly interesting scenario of leveraging the search-driven publishing model is cross-site publishing, where content is stored in one or more catalogs and published on your public website.

When working with cross-site publishing, the content is retrieved from SharePoint 2013 Search index and rendered using a Catalog Item Page. A Catalog Item Page is a Publishing Page with a number of Catalog Item Reuse Web Parts that are responsible for retrieving the right item and rendering its contents on the page. Following screenshot present a sample blog post published using the SharePoint 2013 cross-site publishing capability on the mavention.com website:

In most scenarios one of the Catalog Item Reuse Web  Parts placed on the Catalog Item Page is responsible for retrieving the right catalog item based on the information from the URL. And while it works just fine when the URL is typed as expected, the problems start when the URL refers to a catalog item which does not exist.

Catalog Item Not Found

If your visitors mistype a URL of a catalog item, all that they will see is an empty page:

Although SharePoint 2013 allows you to configure a ‘Page not found’ page, it isn’t displayed for non-existing catalog items.

So why is it happening and, what’s more important, what can we do about it?

How it works: catalog items

When publishing content from catalogs there are two types of pages that you have to configure: the Category Page and the Catalog Item Page. Both are routed to, using the mapping information stored in the navigation taxonomy of your Site Collection. Following screenshot presents a sample configuration of the Category and Catalog Item pages for a navigation term.

When you configure a Catalog Item Page for a navigation term, every URL that is located below that term will be rerouted to that Catalog Item Page, for example if Blog is our category located at the /blog URL, then the blog post about us launching the mavention.com website, located at /blog/mavention-com-live URL will be rerouted to the Catalog Item Page responsible for rendering blog posts.

Unfortunately during the rerouting process SharePoint doesn’t check if the requested catalog item exists or not: after all the logic that you configured for retrieving the catalog item is stored on the Catalog Item Page to which SharePoint is rerouting you and there is no way SharePoint could guess it.

Once on the Catalog Item Page, the Catalog Item Reuse Web Part located there takes over the control. Using the information from the URL it executes a search query which returns the requested catalog item which is then rendered on the page.

The challenge with the Catalog Item Reuse Web Part is that it’s no more than a Search Web Part: it either finds something or not; it contains no additional logic based on the number of retrieved results. As a consequence, if no catalog item is found, no information is rendered on the page.

Better Catalog Item Not Found experience

From the end user perspective there should be no distinction between how the website handles non-existing Publishing Pages, Category Pages and Catalog Item Pages. In either of those cases the website should let the visitor know that the requested page does not exist and it could suggest some alternatives based on the requested non-existing URL. To put it simple, it should display a proper ‘Page not found’ page.

In order to make the Catalog Item Reuse Web Part distinct between existing and non-existing catalog item URLs you have to extend it and check the number of retrieved results. The following snippet presents the extended Catalog Item Reuse Web Part that handles non-existing catalog item URLs:

public class MaventionCatalogItemReuseWebPart : CatalogItemReuseWebPart {
    protected override void Render(System.Web.UI.HtmlTextWriter writer) {
        if (GetNumResults() < 1) {
            HttpContext.Current.Server.TransferRequest(String.Format("{0}?url={1}", SPContext.Current.Site.FileNotFoundUrl, HttpContext.Current.Request.RawUrl));
        }
        else {
            base.Render(writer);
        }
    }

    private int GetNumResults() {
        int numResults = -1;

        ResultTableCollection syncResult = AppManager.GetSyncResult(QueryGroupName);
        ResultTable rt = syncResult.Filter("TableType", TargetResultTable).FirstOrDefault();
        if (rt != null) {
            numResults = rt.TotalRows;
        }

        return numResults;
    }
}

If you would use this extended version of the Catalog Item Reuse Web Part instead of the one provided with SharePoint 2013 and would navigate to a URL of a non-existing catalog item, instead of an empty page you would be presented with a ‘Page not found’ page:

Summary

One of the new capabilities of SharePoint 2013 is cross-site publishing where content stored in a catalog can be published on one or more Site Collections. Unfortunately, when using cross-site publishing, SharePoint doesn’t handle properly non-existing catalog item URLs by itself. By leveraging the extensibility capabilities of SharePoint 2013 you can add support for proper handling of non-existing catalog item URLs with minimal effort.

Originally posted at http://blog.mastykarz.nl/inconvenient-catalog-item-page-page-not-found-404-experience/

Read more about optimizing SharePoint 2013 websites for mobile devices in my article published on the SharePoint Dev Blog.

Originally posted at http://blog.mastykarz.nl/optimizing-sharepoint-2013-websites-mobile-devices/

Bij de diagnose kanker komt er heel veel op iemand af. Om de behandeling zo goed mogelijk te ondersteunen, vormt de website een extra informatieschakel tussen de patiënt en de behandelaars. De website geeft informatie over alles wat met kanker te maken heeft: over onderzoek, verschillende kankersoorten, diagnose, behandelingen, mogelijkheden voor begeleiding en advies en over het team van specialisten dat bij de zorg betrokken is. Daarnaast zijn er ervaringsverhalen van patiënten te vinden.

Toegevoegde waarde SharePoint 2013
De nieuwe website zorgbijkanker.nl  is ontwikkeld  binnen de nieuwste versie van SharePoint; het SharePoint 2013 platform. De belangrijkste toegevoegde waarde van SharePoint 2013 voor het Oncologiecentrum is dat de reeds bestaande content op www.spaarneziekenhuis.nl op een slimme manier (her)gebruikt wordt en op één plaats beheerd hoeft te worden.
De navigatie en structuur van de website is opgebouwd met behulp van 'Managed navigation and term set' binnen SharePoint. Daarnaast worden technieken toegepast zoals zoekmachineoptimalisatie (SEO), eenvoudig leesbare URLs (Friendly URLs) en 'image renditions' voor de optimalisatie voor het weergeven van afbeeldingen.

In drie inspirerende sessies wordt ingegaan op de volgende onderwerpen:
- Hoe kunt u veranderingen doorvoeren en tegelijkertijd procesinformatie borgen in de organisatie?
- Hoe brengt u op een gestructureerde manier procesinformatie naar de werkvloer?
- Hoe krijgt u controle op de gehele 'document life cycle' van kwaliteitsdocumenten?
- Welke interessante mogelijkheden biedt het nieuwe SharePoint 2013 platform?
Centraal in dit seminar staat de koppeling tussen Mavim Rules en SharePoint, die Mavention en Mavim gezamenlijk hebben ontwikkeld.  De combinatie van beide producten biedt een unieke kans voor de volledige integratie van BPM, kennis delen en samenwerken.

Locatie
Wij nodigen u van harte uit deze middag bij te wonen op locatie bij Mavention in de Caballero Fabriek unit 40 in Den Haag. Bekijk het volledige programma van het seminar. De aansluitende borrel biedt ruimte voor discussie en het delen van ervaringen.

Aanmelden of meer informatie?
Wilt u zich aanmelden voor dit gratis seminar? Stuur dan een email naar Bert.verzijl@mavention.nl en vermeld in het onderwerp 'aanmelden seminar'. U kunt ook bellen met 070 820 02 31.

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&amp;M307 Building intelligent websites with SharePoint 2013" target="_blank">P&amp;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?

Script-safe widgets

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:

• youtube.com
• youtube-nocookie.com
• player.vimeo.com
• bing.com
• office.microsoft.com
• skydrive.live.com

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')

Summary

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.

Originally posted at http://blog.mastykarz.nl/inconvenient-embedding-slideshare-presentations-widgets-sharepoint-2013-publishing-pages/

Real-life building public-facing websites with SharePoint 2013

SharePoint 2013 ships with a variety of new and improved WCM-capabilities. In this session we will walk through the new SP2013 WCM functionality and discuss how you can apply it in real-world solutions and get the most out of it when building public-facing websites.

Although this is the same session as the one I presented earlier this week on the SharePoint Evolution Conference 2013 in London I’m quite sure that by the end of the year, based on the new experiences from building real-life public-facing websites, the content will be changed and updated. After I presented the session in London I also got some good feedback which I will incorporate into the presentation as well.

Register now

Register now as there is a great lineup of speakers and sessions. See you in Amsterdam in November!

Originally posted at http://blog.mastykarz.nl/presenting-sharepoint-connections-amsterdam-2013/

P&M302 Real-life building public-facing websites with SharePoint 2013

SharePoint 2013 ships with a variety of new and improved WCM-capabilities. In this session we will walk through the new SP2013 WCM functionality and discuss how you can apply it in real-world solutions and get the most out of it when building public-facing websites.

P&M307 Building intelligent websites with SharePoint 2013

SharePoint 2013 supports us with building intelligent websites: websites that adapt their experience to different devices but also their content to visitors. In this session we will discuss what intelligent websites are and how we can leverage new capabilities of SharePoint 2013 to build them.

Recap

The SharePoint Evolution Conference 2013 was yet again a great experience. I would like to thank Steve, Zoe and the rest of the crew for organizing this awesome event: thank you!

If you attended the event you will receive all of the event’s content within a few weeks time. In the meanwhile let me know should you have any questions about any of my presentations and if you attended my sessions, once again: thank you and I hope you learned some new useful information.

Originally posted at http://blog.mastykarz.nl/sharepoint-evolution-conference-2013-presentations/