Important steps to take if you’re running multilingual variations in SharePoint Online

The other day I described an issue where all of your Web Designer Galleries disappear. That article also suggested how to address this issue but the solution was short terms for me as I got the same problem next morning exactly at 10AM, and the morning after, and after … luckily I was able to “fix” the issue with my handy PowerShell script I wrote in the previous post. But what is the root cause?!?!?!

Well, the root cause is this;

-My site is running English and French variations
-This created two sub sites under root, one for English and one for French

The key to further discovery was the fact that the issue occurred exactly at the same time, therefore it must be a timer job.

Then someone sent me this article: Turn scripting capabilities on and off

Which basically says that there is this new cool feature allowing you to disable whole bunch of authoring functionality on the site with a simple toggle. It also says that this runs as a scheduled process every 24 hours.

You guessed it … I went down and turned off the default setting and things didn’t break the next morning.

1. Go to Admin Center | Settings:


2. Next turn off the Self-Service-Created sites toggle to “Allow”

step 2

Turns out that variation sites are Self-Service-Created sites and this settings messes them up. So, we’re down to either not using this new setting or not using variations. Well there is always an option for MS to fix the issue – but I’m not going to hold my breath for that – however, I have reported the issue to Premier Support so we might be getting some action.



Want to update your SharePoint app site logo without code?

With SharePoint 2013 and SPO, you get apps and often apps have their app site.
When you update your site custom look – all the apps get the same look and feel, there is just one problem – the logo you update on the root site doesn’t get updated on the app site.

Here is my custom logo on the root site:

main site logo

Here is how does one of the app site look like:

app site logo

There is no settings menu to change that but here is what works:

1. Navigate to the root of your site and click on “Title, Logo ….” under “Look and Feel”
2. Copy the URL of the settings page (second part as shown below) … /_layouts/15/prjsetng.aspx

app url

3. Change the logo on the page there and save the settings, result ….

new logo on the app site

Now your apps match your site, duh ;)



Quickly turning your Content Query Web Part display into a jQuery tabs

In summary, the goal is to turn something that looks like this:

content query default display

to this:

jquery tab links

There are many ways to do it, and I very deliberately said “quickly” in the title of this post, implying that you won’t need to mock around XSL of the Content Query Web Part.

Here are the steps:

1. First we’ll create a list which is going to hold our data

The list data structure will be:

  • Title – Single line of text
  • Link Description – Single line of text
  • Link Grouping – Single line of text
  • Link – Hyperlink or Picture

Here is how this list looks like, hopefully yours is more useful than my list of cities:
list of cities

2. Next, we add a Content Query Web Part to the Page with the following configuration:

  • Source set to my list
  • link source

  • Grouping set of my special column which holds groups (countries)
  • link grouping

  • Display are defaults with few columns you may want to display
  • renderign columns

3. Save the configuration and verify that your display looks similar to this:

content query default display

4. Add a Script Editor Web Part on the page where your content query resides with the following code in it:

<link rel="stylesheet"

<script src=""></script>
<script src=""></script>
$(function() {
var tabCount = 0;
$(".dfwp-item div.groupheader").each(function() {
$("#tabs ul").append("<li><a href='#tabs-"+tabCount+"'>" + $(this).text

$("#tabs").append("<div id='tabs-"+tabCount+"'>"+"<p>"+$(this).parent

tabCount = tabCount+1;

<div id="tabs">

5. Save the web part and the page and ….

jquery tab links

6. If you want to be a good practices developer – you need to download jQuery tabs and upload jquery and jquery ui artifacts into the library on your SharePoint site rather than referencing them as I did from …

What the code above does is that it takes the content of the Content Query Web Part and wires it into tabs; then hides the original CQWP content.

There, wasn’t that easy?



Have your Web Designer Galleries been all of the sudden gone in SharePoint Online?

I ran into a really annoying issue recently, here were the symptoms:
-Users with full control and even site collection administrators were not able to add content editor web parts onto pages
-Administrators were not able to see “Web Designer Galleries” in their site collection settings


If you have publishing features enabled – then this section was showing up with the only option of “Master pages and page layouts”

I won’t spend much time explaining how I got to the solution – I will just give you the solution and then add some speculation at the end on what might have caused this.

If you’re using SharePoint Online as I was using run the following commands in SharePoint Online Management Shell:

$userName = ""
$password = "MyPassword"
$siteCollectionUrl = ""
$siteAdminUrl = ""
$securePassword = ConvertTo-SecureString $password -AsPlainText -force
$O365Credential = New-Object System.Management.Automation.PsCredential($username, $securePassword)
Connect-SPOService -url $siteAdminUrl -Credential $O365Credential

$rootsite = Get-SPOSite("")


If the response you get from the last command is “Unknown” or “true”
Then run this command:

Set-SPOSite -Identity "" -DenyAddAndCustomizePages $false

Here is a bit more details:
First off, this post ( sent to me by Fred Downing got me thinking … what if Microsoft intrioduced a new property on a site collection and didn’t set the default – so the code that runs and checks for property block update if the property is not set to $true.

After digging around and finding the undocumented property, I switched it’s value and it worked.

Hopefully it will save someone long hours, Enjoy!


Important tips on customizing SharePoint Online Suite Bar

There is a lot of debate on whether SPO suite bar should be customized or not … this video puts things into a single, very important tip – best viewed in HD … enjoy!


Frequent Suite Bar customization nightmares in SharePoint Online are here to stay

Today on a SharePoint Branding webinar (thanks everyone who could attend, btw), among other things we talked about customizations to SharePoint Online component such as Suite Bar and how unreliable this can be. Well, perfect timing, to prove this point, I’ve noticed subtle Suite Bar change in Excel Online (part of SPO).

Before the suite bar looked pretty useless and thick for Excel Online and other web apps; now it looks like you can change the mame of the file right the suite bar just by clicking on it; you can also share the file:


Those are pretty handy functions but I bet there is markup change; luckily this change is not the same in regular sites such as team sites etc, so no need to panic. TO prove this, I’ve checked the DOM and here is how it looks in Web Apps:

web apps

Which is completely different from team site suite bar:

team site

Moral of the story: stop customizing Suite Bar people :)!


Gearing up for SharePoint Online project

Having several different SharePoint Online projects completed over the last couple of … years really; several bigger ones still ongoing, I thought I would share few things with you that might help you from a technical perspective to avoid things that can’t be done.

In no particular order – here they come:

1. SharePoint Apps are not your typical web parts, there are limitations related to functionality and branding
Ok, so you still have web parts in SharePoint Online but everyone out there says “no more web parts, build only apps”. So you might think, well apps are new web parts. Not quite.
Some of the limitations of SharePoint hosted apps include:
-Only client code is supported in apps
-Where you need it or not – each app gets an app site
-Each app needs to request set of permissions which users just allow otherwise you app won’t work
-Apps parts in apps run on host sites as iframes – so you can’t access or manipulate DOM of a parent

2. Be careful with promised custom functionality in your workflows, you are limited to out of the box workflow actions

SharePoint Online allows you to build workflows in SharePoint Designer – this is old news. However, you can also build workflows in Visual Studio and deploy it to SharePoint Online; just use the Visual Studio 2013 workflow template. The limitations of such workflows are to actions already deployed within SharePoint Online. In other words, you can’t run your own custom actions. Having said that, out of the box actions are quite extensible and there is a lot you can achieve.
Be careful when promising your customers that you can run out of the box workflow on the app site – limitations on that site break workflow initiation even for out of the box workflows

3. Sites created by apps (aka app sites) are limited in functionality, for example tools such as SharePoint Designer and many 3rd party migration tools are not able to connect to them.
Despite the fact that apps sites should be just sites – they have a limited functionality so make sure you test your typical assumptions and test scenarios since some of them may fail. Here are few examples:
-Connecting to an app with SharePoint Designer Fails
-Many third party migration tools are not able to connect to the app site to deploy or read data
-Limited workflow initiation functionality for out of the box workflows

4. Deployment of site artifacts (master pages, layouts, images) should be done with Sandbox Solution; using apps makes it clunky.
Even though there is a theoretical option to deploy your branding and other site artifacts (master pages, content type etc) to a host/parent site using app framework – due to lack of proper support in apps to deploy those artifacts, practical implementation is beyond reasonable.

5. Have old PowerShell to deploy and configure your solutions to SP On Premise? reusing it for SPO will require tweaking
Many of us use automation to deploy site artifacts, solutions etc; I have quite a few PowerShell script that do a lot of magic in SharePoint on-premises. Don’t assume those will work seamlessly in SharePoint Online. Test them, there is a very high chance you may need to do some tweaking. In some cases, functionality is not going to be supported. The reason being, is that SharePoint Online supports Remote PowerShell which has a limited subset of functionality.

6. Be careful with customizing SPO core elements: Suite Bar, navigation, etc – things tend to break when MS pushes out an update

Suite Bar, showing on the very top of any SharePoint Online site is by far the most dangerous place to put your customization into. Many customers will ask you to add their custom links, remove out of the box links and many other requests. Most of such customizations may work at first, but there is a very high risk of this functionality breaking when Microsoft updates UI and Suite Bar is their favorite place from my experience.

I have had several instances when Suite Bar HTML rendering was changed resulting in anything that relies on it break and cause multiple errors on the page. Microsoft doesn’t provide any release schedule on such elements so you might get a nasty surprise one evening. Therefore, best is to stay away from customizing core elements such as ribbon and suite bar in SharePoint Online.

7. Your SPO tenant shares some services with others – remember that when creating solution that use search, user profile, translation etc

There are many clever solutions out there which use Managed Metadata, User Profile and Search Service. Remember that those services run in multitenant environment and latency of those is significant comparing to on-premises system.
To give you some examples:
-Search crawl can take several hours for the new search properties to be picked up
-User profiles take a while to be created manually; even the user profile property page takes few minutes to load up
-Multilingual capability in SharePoint Online which uses timer job can take up to an hour to create a translation package depending on the volume of pages

8. Avoid big bets on solutions that are not officially supported since you never know when those will be officially discontinued (example is BCS support for Kiosk users)
SharePoint Online is evolving and licensing is evolving with it. Depending on how you put together your solution – you may want to sell your customer certain level of licensing (say kiosk user license) based on availability of certain features (such as BCS) when tested the product. Although some features are available, licensing clause may explicitly or implicitly say otherwise. Avoid solutions which are built on limited availability of some features, especially if there are strong indications those features should not be there. You never want to have a core feature to disappear one day because technical hole has been patched and now you have hundreds of thousands of disappointed users.

9. Remember, the storage is now in the cloud: test migration of large volumes of data – you might need to migrate weeks worth of data without realizing it initially
This lessons learnt speaks for itself – when migrating – don’t assume this is going to be fast. Even the most ingenious migration tools out there can’t do much when it comes to transferring data across internet. Test your migration and establish baseline.

There are of course may more lessons and depending on the type of the solution you’re building – you might find several more. Above are the most common when building typical intranet or extranet solution and I hope it will save time during planning and execution of your next SharePoint Online project.



Content Targeting with SharePoint Content Search Web Part

Who wouldn’t want to have targeted content in SharePoint?
Seems like such a logical ask and yet it’s seems like it’s a pain to implement. This post will try to demystify this implementation.
Here is the scenario: You have people in your organization and they’re using their User Profile to describe their interests, say they’re using Ask Me About field:
ask me about user profile property
Wouldn’t it be nice for anyone who is writing articles on that topic to “tag” their content with this tag … then surface in Content Search Web Part on the home page only the stuff that this particular user cares about?

Sure … let’s see how it’s done (I’ll be using SharePoint Online since all of the plumbing is already set up there):

1. First, you need to create a user profile property or use an existing one. I will use an existing User Profile property called “Ask Me About”.
2. Next you will need to extract the “real” name for out of the box properties, as you can see my property is actually named “SPS-Responsibility”
To get to this screen you need to go to SPO Admin -> click User Profiles -> click Manage User Properties -> find your property and click [Edit]
real property name
3. Then you create a new or use an existing managed metadata tree, here is my example
managed metadata terms
4. Next, we associate this tree to a column in a list … nothing complicated here.
5. Now, you need to create at least one piece of content that uses your new column which has managed metadata tree associated with it. That’s not a problem with existing columns and data but for a new column to be picked up by search – you may need to wait till next full crawl and in SPO it may take an hour for a newly created column.
6. Navigate back to your SPO admin center and this time go to search -> Manage Search Schema, since we need to grab exact managed property name created by the search crawl. In my case the name is: owstaxIdTestx0020Column since I named my column in the list as “Test Column” and Sharepoint converted it to taxonomy column
7. Now, we have all of the components, let’s create a query. Add a Content Search Web Part to the page and edit it’s query properties … switch to Advanced Mode.
8. Type in the following query substituting your column names etc … of course:

path:"https://[your site URL]" owstaxIdTestx0020Column:{User.SPS-Responsibility}

Remember to replace owstaxIdTestx0020Column to the managed search property representing your list column. Also, SPS-Responsibility would be whatever you chose for your user profile property.

targeted sharepoint search results

As a result, you will get targeted results as you can see if the preview panel; in my case I am seeing one piece of content tagged with “SharePoint” since it’s in my user profile.

Now what if I have multiple values stored in my user profiles?? like this:

multiple profile values

Well, you need to adjust the search syntax to be bitwise OR, like this:

path:"https://[your site URL]" {|owstaxIdTestx0020Column:{User.SPS-Responsibility}}

Result? …Voila:
multi value targeting

Happy targeting!


SharePoint Apps versus Full Trust or Sandbox solutions

Pressure is on and more and more companies are moving to SharePoint Online for the intranet and extranet and whatever else they have running in their server room. So, Few people asked me, what is the difference between developing apps versus on-premise solutions. The short answer is , a lot and since this is not really a helpful answer I will start a long list of gotchas :) and will add to it as I go along

In here we’re discussing SharePoint Hosted apps just to be clear.

General Stuff

-There is no C# or any other compiled code in apps … everything happens through a JavaScript. If you need to customize anything you need to write JS which calls SP API. The API is powerful but there is a learning curve even to an experienced SP dev.

-When you delete an app which has been installed on the site – your app site gets deleted too … so if you stored some data in the app site and you find it valuable – make sure you backup that data first. This is different from Sandbox or Full Trust solutions in a way when you delete the solution lists and libraries created by that solution live on unless you redeploy the solution and chose to overwrite the list. Not so with apps.


-You can create custom workflows and even build those in Visual Studio, not only in SharePoint designer but those will have to use only out of the box actions available, you can’t create your own workflow actions and deploy them you have to play around with what’s configurable out of the box

-Out of the box approval workflow can be added to any of the lists on the app site but initiation or association form will not load for the list so basically you can’t initiate a workflow.

SharePoint Designer

-You can’t connect and edit the apps site created with an app – you just get an error. This is probably a limitation in SPD (they probably don’t want you to ruin the app site or find out how it works ;)) but nevertheless

Site templates

-You can’t provision your site template as an app similar to what you can do with Sandbox solutions

You own apps versus apps you bought in the app store

-There are certain things which you (as an app) can’t do if you’re in the app store. One of which being that app that is being sold in the app store can’t have Full Control on the parent site – this is actually a huge limitation in a way that app store apps will never (unless MS change it) have a full potential capability of the app that has been developed by a dev and uploaded to the corporate catalog.

Pages and other Assets

-Page, CSS, JS, Image, MasterPage etc provisioning to the parent site using the app involves hacks and not really robust

App Parts – they’re kind of like web parts but not really

-App parts that you build run in an iframe on the page, so it’s not like you can emit some CSS, JS, or HTML that will have access to the parent DOM

-For the same reason as above, you can not style or add JS interaction to app parts by adding your styles or JS to master page since those run in an iframe of the app site and therefore are not really inheriting your master page for the main site

-If elements on your app part take a certain space, and you place the app part on the page which has a limited space – you will end up with scroll bars in the app part because – yes, you guessed it, it’s running in an iframe. This is a huge issue for example if your app has a flyout (for ex a menu) and typically a flyout would fly over other elements on your page – well now that it’s an app part – you can’t – it will just be flying in the constraint of the iframe.

-You can’t really take a third party app part and “wrap it” and pass parameters dynamically. This is my favorite thing to do with we parts that is not possible with app parts. You can wrap a third party web part into your own with a purpose of feeding parameters to web part. This is helpful for example when you have a weather web part that has a web part parameters passing the location name but you want to dynamically pass that data at the time of rendering. You could just wrap a web part in your own custom web part and do that logic – doesn’t work like that with apps parts – it just doesn’t.

-App parts can’t be placed on a master page like controls. So traditional web parts are just user controls or web controls wrapped in a magical web part wrapper which means that you can hardcode your web part into masterpages so that users can’t remove them – there are few valid cases for this. Well, you can’t do that with app parts.

-App pages are not web part pages, so users can’t edit the app home page and customize what they see there. Once you define the app landing page – it is what it is.

More to come, stay tuned …