Lately Microsoft released the new and long awaited modern site template for publishing sites in SharePoint Online (Office 365). The site templates is named “Communication Site” and is the second template released after the modern “Team Site”. This site template can be created if you have permissions from the SharePoint Home page using the “Create a site” form:
This approach is fine if you have permissions to create sites and are happy with the default setup. For my case this is almost never the case. Often the tenants I work with have restricted who can create new sites/groups, and also requires additional configuration after it has been created. This can be accomplished for the new “Team site” template, so I was curious how this can be done for the Communication site.
At the time of writing Microsoft have not released any documentation on how to do this, so this was done by re-creating the steps of the “Create a site” wizard (found by using Fiddler). I assume and hope that we sooner or later will find official documentation from Microsoft on how to do this. They might provide us with a bit more elegant way to use their API’s. But if you are familiar with using general REST API’s, this is pretty straight forward as soon you get authenticated with SharePoint.
UPDATE (30.10.2017): This documentation have now been released, and this method is now a supported approach to provision new Communication Sites.
PowerShell script for creating a Communication site
This script requires the “SharePoint Online Client Components” to be installed.
With the modern sites Microsoft has created several new REST based API’s used in their own wizards. These API’s can be used as long as you have a user authenticated context.
This code demonstrates how you can create the new Communication Site from code. After the site have been created you are free to connect to the site and apply customizations using in example the PnP PowerShell framework.
In document libraries it is possible to enable ratings, both likes and average score (1-5). In this article I will cover how to enable “Likes” on the Pages library in a publishing site.
When configuring libraries manually, this is enabled from the “Rating settings” in the library:
But when we follow the remote provisioning pattern to create new sites by using PowerShell and CSOM, there is currently no available function in the API for this. This pattern is the recommenced approach when working with SharePoint Online or SharePoint 2013/2016 without access to server side PowerShell or code.
To understand what is required to programmatic enable ratings I had to, as always with SharePoint, inspect the code behind with a reflection tool like DotPeek.
How to enable likes ratings
This show the procedure to enable ratings with Likes on a Pages library. To enable “Star rating” (1-5 average) this would be similar, but not covered in this post.
- Add the required fields to the library
- Add “LikesCount” to default view
Add “Ratings_VotingExperience” to RootFolder’s property bag
Use PowerShell to enable ratings
Note: This function requires the Office Dev PnP PowerShell library to be installed and loaded in the current PowerShell session. I recommend using this library for working with PowerShell and SharePoint (both Online and On-Premises).
Example: How to use this function with a site
Using this with subsites within the Site Collection would require some extension to the function, as the Fields always are loaded form the RootWeb, but the library reside in the subsite.
When we have run the “Enable-CustomLikesRatingsOnLibrary” function on the desired library, we can see that Likes now are available:
Using this function it is now possible to provision new sites with PowerShell and CSOM and enable likes rating on libraries.
Scheduling is easily enabled through the web interface when configuring the “Pages” library, but when deploying solutions using PowerShell, this must be automated as part of the configuration. Unfortunately, as many other sources also state, this is not directly supported in the Client Side API (CSOM).
The solution is to manually set up the Pages library the same way Microsoft does by adding two event receivers, changing some columns from hidden to visible and adding them to the default view.
Note: This example uses commands from the Office Dev PnP PowerShell library, ex. “Get-SPOContext”. I recommend using this library for working this PowerShell and SharePoint (both Online and On-Premises).
Function to enable Scheduling on a library on a given web site:
On line 11 an additional function is needed to create the parameters for the “Load” method:
How to enable scheduling:
This is a summary of an issue we have had with publishing pages not being indexed, and then unable to build the search-driven pages we wanted using for example Content Search Web Part. This occured in SharePoint Online (Office 365) and we have only had this issue with a couple of tenants. So my guess is that most tenants are working fine, but if you should come across this strange behavior, I hope this post can help you save some time.
- Created a Publishing Site
- Added a Content Type and a Page Layout, created a few test articles
- Added a Content Search Web Part and set up a query to return articles for the Content Type created above
- Waited a long time (normal)
- No results (oops)
- Tried to reindex the library (curious)
- No results (worried)
- Retried all the steps (scared)
- No results (desperate)
- Got coffee (calm)
- No results (called support)
I guess you get it. Something was very wrong and I was stuck on not getting any results back. On-Premises this would probable been one of those situations a full crawl, or at worst a index reset, had fixed it. But running in Office 365 we don’t have these abilities.
After some trial and error I understood what was causing the issue, and got this workaround:
- Go to “Site Settings”
- Select “Navigation” under “Look and feel”
- Uncheck these options:
- Add new pages to navigation automatically
- Create friendly URLs for new pages automatically
All pages created and published after making this change was indexed and showed up as expected. Unfortunately all the pages created before doing this change was a lost cause. Believe me, I tried a lot but unable to get them indexed.
As being on Office 365 this issue was addressed with Microsoft Support, and after a while they released a fix.
Unfortunately I suspect this error can still occur in some scenarios, and to make sure we don’t run into this trouble again, a recommendation is to avoid using the Managed Navigation set up as shown above just to be safe.