Modern SharePoint in Office365

During these past couple of years, the SharePoint field has changed drastically. Instead of loads of on-prem installations and massive brandings, intranets and team sites have largely migrated to the cloud, to Office 365 and gotten a truck load of new options and tools as time has passed.

Office 365 is so much more than just SharePoint. SharePoint still is at the core of everything and intranets and team sites can still be built as they always have been in SharePoint: by centrally creating site collections for different purposes. While this has still been and still is the chosen path by many companies, there is so much more to SharePoint and team work today, that it really should be considered in each and any organization instead of locking the usage to "the way it's always been".

The Office 365 tool pallette revolving around SharePoint today includes:

- Classic SharePoint sites - publishing, teams, blogs, project etc. "managed" site collection created either in Admin Portal by SharePoint global admins or usually offered to users via a site provisioning tool connected to a site order form

- Modern SharePoint sites - two types of sites: Team sites and Communication sites, which users can create using the self service site creation on the "SharePoint" page in O365 portal

- Office 365 groups - "AD groups" created by users; users have shared mailbox and calendar and group site (modern)

- Forms - app for creating polls, feedback forms etc.

- PowerApps - tool for creating interactive apps and modifying list forms

- Flow - app for workflows

- Power BI - app for all kinds of data

- Planner - Microsoft's answer to Trello, ie. canban board app connected to groups

- Teams - app for team/topic conversations; connected to groups

- Yammer - app for conversations

And more, but these are the most essential ones for modern team work, when we are looking at things from a SharePoint perspective. It is no wonder then, that so many times people are totally confused and lost in the jungle of possibilities. 

The above mentioned set of tools is more or less loosely connected to SharePoint but not necessarily immediately. Some of them can be used, or rather launched from SharePoint sites, e.g. Flow and PowerApps from a list or library page. Some of them provide a means to show data in a SharePoint page, e.g. Forms and Power BI. Some of them are linked to groups, like e.g. Planner and Teams, and a group also always has its own modern team site with (almost) all SharePoint functionalities. 

Modern Team sites however are only one type of SharePoint sites currently available. Modern Commucation sites are the modern version of classic publishing sites. Classic sites - publishing and teams - still exist also. A classic team site (site collection) can be groupified (soon) thus creating a "O365 group wrapper" around it, bringing the group functionalities to it.

In the world of modern intranets, there still are fully branded classic publishing site intranets, but also ones built using Communication sites only are quite a few already. Communication site intranets can be built either by creating subsites (like in the classic version) or in the future by using SharePoint Hub sites (currently available in targeted release) to network separate sites together into a more flexible web. 

Since pictures usually say things better than a million words, I will let my little diagram do the rest of the explaining. Hope it helps to understand the different philosophies and technologies behind the different site types!

List with Paging on the Bottom Control Template

One of our customers wanted to use the List with Paging control display template on their news page. For some strange reason this template positions the paging in the top right corner of the web part instead of at the bottom of the list, and preferably horizontally in the center.

I fugured there were two options to do this:

1) Use CSS only (usually my preferred way)

2) Create your own display template for the purpose

Now the problem with approach #1 is that there are other content search web parts on the page too, so if you make general rules to create space at the bottom of the ul.cbs-List, this will be applied to all of those CSWPs. There is no special CSS class to hook into in the paging template ul. So even at best, this approach is a bit of a hack because in order to target it properly, you would need to use some container identifier and thus cause the whole hack to break if the web part is moved to a different zone on the page.

Number 2 seems easy enough, though, and replicable, which is even better. I set to action, downloading the original Control_ListWithPaging.html template file and opening it for editing in Expression Web and saving it with a new name. 

First, I added another class to the ul.cbs-List element, in order to be able to target rules only to the CSWPs using my new template. Small enough change, don't you think? 

<ul class="cbs-List pagingbtm">

Of course I also changed the title of the html document to List with Paging on the Bottom.

<title>List with Paging on the Bottom</title>

No biggie, right? I then uploaded the file, just to check that it works. Which it didn't! This puzzled me immensely, especially since the error message said, that the div, body and html tags have not been closed. They are not closed in the original control template (at least not when I opened it in notepad to check) but that works fine. 

So fine, I closed those tags at the end of my new template file. The error message disappeared and instead my template worked perfectly. Well, almost. The little arrow icons weren't visible but at least there was no error anymore. I decided to ignore that for the time being and finalize my control template changes. 

As said, I could've done it all in CSS only (after adding the new class), but I decided to make one more minor change in html to make the css shorter and less vulnerable and avoid the extra space when there are less items than the paging limit. I moved the resultset to the beginning of the list, so that the paging became the last node instead of the first one.

The results are displayed by this variable:

_#= ctx.RenderGroups(ctx) =#_

It is originally right before the closing ul tag. By simply moving it right after the opening ul tag, the order is reversed.

<ul class="cbs-List pagingbtm>

_#= ctx.RenderGroups(ctx) =#_

When this was done and tested, I started looking into that arrow icon issue. Quirkily, the img src was pointing to a nonexistent file on my own computer! This can be blamed on Expression Web. It's a first, though! I'm quite used to SharePoint Designer pulling off sh*t like this, but Expression Web has generally been a very reliable editor and loyal to the original code. Not this time. 

I opened the original file in notepad and sure enough, the correct source string was there, intact. 

<img class="_#= $htmlEncode(nextPageImageClassName) =#_" alt="_#= $htmlEncode(lastPage.title) =#_" src="_#= $urlHtmlEncode(GetThemedImageUrl('spcommon.png')) =#_">

So I copied and pasted it to my template and all was well in SharePoint Land again.

Here's the CSS:

ul.cbs-List.pagingbtm li.ms-promlink-header {

    text-align: center;

}

ul.cbs-List.pagingbtm .ms-promlink-headerNav {

    float: none;

    margin-top: 6px;

}

Search Results vs. Content Search Web Parts: customizing and date formatting

The default way to display feeds from news, events etc. on an intranet front page is to use the Content Search Web Part. Used to be Content Query, but customizing the CQWP is way more complicated plus it is restricted to the same Site Collection only. This is still used, as is, by many of my customers, for it is easier for content managers to set up than the search queries. Anytime any custom templates are needed (or when I am setting up the feeds), definitely CSWP is the way to go.

Lately, though, I have had several customers with SharePoint Standard lisence only. Unfortunately this leaves out the CSWP completely. Search indexing and search driven content is still available, but building those said feeds is just a tad more complicated for you need to use the Search Results Web Part, which is not created for this kind of usage, even though it CAN be used. It requires some more work, but once you've figured out the basics, it's not that difficult. Just a bit different than the CSWP.

The display templates of CSWP consist of a control template and an item template (for more info, see my post "The Anatomy of SharePoint 2013 Display Templates"). Mostly the modifications and customizations are rather straightforward to make by following the example of things already there. The date formatting, however, is a bit tricky. What you need to do is:

1) Copy the item display template you want to modify from MasterPages gallery, Display Templates, Content Web Parts directory.

2) Create a managed property of the field you want to use, if not using Created or LastModifiedDate, in Search Schema.

3) Use the date field as value for desired line data, eg:

var line1 = $getItemValue(ctx, "Line 1");

var line2 = $getItemValue(ctx, "Line 2");

var eventdate = new Date(line2.inputValue);

4) Format the date as you wish in the HTML where the value is rendered:

 <div class="cbs-Line2 ms-noWrap" title="_#= $htmlEncode(line2.defaultValueRenderer(line2)) =#_" id="_#= line2Id =#_">_#= eventdate.format("d.MM.yyyy H:mm") =#_</div>

5) Upload your display template (remember to change the title in the HTML and rename your modified file) back to the same folder in MasterPages gallery and publish it. It's ready to be used.

As for the Search Results web part, the system is slightly more tricky. First off, there are more display templates involved: 

• Control templates
• Item templates
• Item HoverPanel templates

Mostly, you need to work with Item templates and/or hoverpanel templates, if using the hover panel. In the case of displaying feeds on front page, the hover panel is seldom wanted. It can be removed. Simply delete highlighted parts from the display template you copied, eg. ItemDefault (note, that the Search Result templates are in the Search folder):

<div id="_#= $htmlEncode(itemId) =#_" name="Item" data-displaytemplate="DefaultItem" class="ms-srch-item" onmouseover="_#= ctx.currentItem_ShowHoverPanelCallback =#_" onmouseout="_#= ctx.currentItem_HideHoverPanelCallback =#_">

And then comment out the following line:

 <!--  <div id="_#= $htmlEncode(hoverId) =#_" class="ms-srch-hover-outerContainer"></div> -->

Other modifications that I have found useful and quite necessary in said use case are

• removing the item URL - actually in default item template I just remove the whole default body render tag:
  _#=ctx.RenderBody(ctx)=#_
• building your own stuff to show for each item, e.g. rollup image, a content summary, publish/create date eg. 

Adding fields to the display template is simple enough. The fields need to be managed properties in Search Schema, so remember to do this first for any custom fields. Then you add the properties to the template mso:ManagedPropertyMapping tag:

<mso:ManagedPropertyMapping msdt:dt="string">'Title':'Title','Path':'Path','Description':'Description','EditorOWSUSER':'EditorOWSUSER','LastModifiedTime':'LastModifiedTime','CollapsingStatus':'CollapsingStatus','DocId':'DocId','HitHighlightedSummary':'HitHighlightedSummary','HitHighlightedProperties':'HitHighlightedProperties','FileExtension':'FileExtension','ViewsLifeTime':'ViewsLifeTime','ParentLink':'ParentLink','FileType':'FileType','IsContainer':'IsContainer','SecondaryFileExtension':'SecondaryFileExtension','DisplayAuthor':'DisplayAuthor','Created':'Created','NewsSummary':'NewsSummary', 'PublishingImage':'PublishingImage' </mso:ManagedPropertyMapping>

Then you use this to build your own HTML for the items, eg.

<div id="_#= $htmlEncode(itemId) =#_" name="Item" data-displaytemplate="DefaultItem" class="ms-srch-item">

    <div class="newscontainer">

<div class="newstitle">

<a href="_#=ctx.CurrentItem.Path=#_">

_#=ctx.CurrentItem.Title=#_

</a><br>

               <span class=newsdate>

              _#=ctx.CurrentItem.Created=#_

</div>

<div class="newsbody">

<div class="newsimg">

_#=ctx.CurrentItem.PublishingImage=#_

</div>

<div class="newstext">

_#=ctx.CurrentItem.NewsSummary=#_

</div>

</div>

</div>

Note the date there, though. It will give you a very long date format by default, but in a Search Results template it is way easier to format the date than CSWP. Simply add format(yourdiesiredformatting) to the value in HTML. Like this:

_#=ctx.CurrentItem.Created.format("d.M.yyyy")=#_

Then there is only one little nuisance left: the hover background color. 

This comes from this CSS rule: 

.ms-srch-item:hover, .ms-scrch-resultHover:hover, .edisc-SearchResultItemContainer:hover{

background-color: rgba(...);

}

Now, if you override this as is, it will effect the search results pages too. So try to identify the targets in some way, use eg. .welcome or .article classes for targeting content pages only in removing the hover color.

Whew! All done!

SharePoint Dev Kitchen 2016

I was really happy when I heard that the embargo was being lifted on the current SharePoint development stuff, and I could finally tell the wolrd about the amazing SharePoint Dev Kitchen experience of this past March in Brussels. An invitation only -event for SharePoint dev community, the bootcamp was full of people with ideas, views and passion, and the core of the Microsoft SharePoint team.

The big meeting room was buzzing with electricity as we all settled into our seats to hear what the SharePoint team wished to share with us. The preparation emails had given but a little hint on what was happening in our SharePoint world. 

When the keynote ended, I felt a whoosh of delight. The SharePoint team was not only being candid with us but also looking to get feedback, thoughts and ideas from us who crowded the room. Still, the most exciting thing was the message [NOTE: this is purely PRE-RELEASE info]:

SharePoint is going towards more and more open source coding
Instead of doing a whole lot of behind the scenes closed-cirquit development, the SharePoint team has adopted the usage of JavaScript libraries and frameworks that enable the third-party developers to create add-ins and solutions for SharePoint with any JavaScript framework they wish to use.  

Mobile leads development
They were pretty clear on this one. All develoment is done mobile first. Not desktop first keeping mobile in mind but actually mobile first, then desktop experienve. 

SharePoint Home
If I had a euro for each time a customer has asked me: "But where's the SharePoint here in O365? There's only this Sites... is that it? But how do I find my workspaces if I haven't followed them?" As far as I understood, SharePoint Home will asnwer this question once and for all. It's where SharePoint is, it's where the workspaces are. 

A lot of nice new features are coming to SharePoint
Document libraries will get a bunch of new features. Publishing sites will get a new page model as an addition to the current one (i.e. the current publishing pages aren't going anywhere; your data is safe) with the feel of Sway to them - adding modules (or cotnrols or web parts, whatever the name will be) to a page canvas (or several). Publishing sites will get a gallery of these modules - new web parts - that are fully JavaScript based. 

Office UI Fabric
In addition to this new more open way of developing for SharePoint, Microsoft is providing a "fabric" of CSS and (HTML) controls for unified look and feel of any app or add-in that made for Office environments. It provides a grid for responsive design, fonts, animations etc. to be used freely - but no one is forcing it either.

One thing the Microsoft people really emphasized: the old way is not going away; this new model simply enable more.

Dev Kitchen was a very social three day "training". Sure, Microsoft people were giving sessions on what they are working on, the technologies that are used and there were hands-on labs to try out the things in a test environment. However, there was also a lot of discussion of ideas and questions and priorities and wishes and whatnot. There were a lot of people already getting their hands dirty with the new stuff, trying out real life scenarios and showing their work in demo sessions. 

Now the team is ready to come out with the stuff, but this is only the beginning. A lot is brewing in the SharePoint Dev Kitchen and it will be truly interesting to see the outcome! 

Removing reusable SPD workflows completely

Recently I have been working on a set of different custom SharePoint Designer workflows for different customers. Sometimes the process is not so straightforward that you get things right on the first try and sometimes the errors result in the need to actually remove some trial workflows from the system. 

Reusable workflows are slightly more tricky to remove from the SharePoint UI than the list workflows. In SharePoint Designer, the main way of managing workflows is in the Workflows section. This may well tempt you to remove the workflow simply from that list and be done with it. This, however, will not remove it from the SharePoint UI, and thus an old depracated workflow is still available for users. 

The right place to remove the workflow from is to open the All files section, find the Workflows directory there and delete the whole workflow directory. 

But what if you already deleted the workflow in the Workflows list and now you have no directory for it anymore but it still shows up in the SP UI? This is what I was researching this morning. The place to go in that case is - surprise surprise! - the _catalogs directory. There you will find a folder named wfpub. And in that wfpub folder, you still have the directories for even those workflows that were deleted from the Workflows section listing. Delete these directories with all their contents and you're good.