Creating communication sites using Fiddler

Some SharePoint developers are still not familiar with how valuable Fiddler can be when developing applications. Some also would depend on other tools like Postman to get the job done, and others would find it hard to work with Fiddler and SharePoint at the same time​​ due to not being able to get authenticated to SharePoint from Fiddler. I’ll use this post to show the steps on how to use Fiddler with SharePoint online as well as show​​ the steps​​ to create communication sites using REST from Fiddler.​​ 

Obviously, first thing to do is to get Fiddler if you don’t have it already, you can get it​​ here.​​ The left pane in Fiddler is where network traffic is shown. Whenever you make a request or any program on your computer makes a request to any external server, Fiddler acts as a proxy and all traffic is passed through Fiddler as long as it’s running on your computer. You can notice that if you go to your internet options > Connections​​ tab >​​ Lan Settings, you’ll see something like this:​​ 



So now we know that Fiddler acts as a proxy and all network traffic is passed through it as long as it’s running. You can see all the traffic for your computer in the left pane in Fiddler.​​ On the right side, we have bunch of tabs, the only 2 we care about for now are the​​ Inspector​​ and​​ Composer​​ tabs.​​ Double-clicking on any​​ request will open the Inspector tab for you to see the Request (the top area), and the response (the bottom area). We’ll use the inspector tab first to get the cookies used to authenticate to our SharePoint online, later when we get the information about our cookies, we’ll use the Composer tab to make a request to post data to SharePoint to create a new communication site.​​ 


Let’s now get the cookies that are used to authenticate to SharePoint. Make sure you’re tracking capturing traffic​​ (remember all traffic info will appear in the left pane). To​​ verify that, click on the File tab and make sure that “Capture Traffic” is checked:​​ 




Next, open a SharePoint site in your Office 365 tenant, you’ll notice that Fiddler is going to capture that request:​​ 



Double-Click on that entry in Fiddler, and go to the Response section (the bottom right section in Fiddler) and click on the Headers tab:​​ 



You’ll notice​​ you have 2 cookies,​​ FedAuth, and​​ rtFa. Right click on the first one, and select​​ copy value only:​​ 



Open notepad, type​​ Cookies:​​ then paste what you copied, so you should have something like:​​ 


Cookies:​​ {CopiedValue}

Copy the second cookie value in Fiddler, then​​ in notepad​​ write​​ ;​​ afterwards​​ and paste the second value, so the full string you should​​ have​​ is:​​ 


Cookies: {FirstCopiedValue};{SecondCopiedValue}

Copy the whole text in notepad, and open the Composer tab in Fiddler, you’ll find it in the top right section. Change the HTTP request type to​​ POST​​ and paste the URL of your site in the next field and append​​ /_api/contextinfo,​​ then paste the string you had in notepad inside the Headers text area, so the composer tab should look like this:​​ 



Remember that the Cookie: … is the text you have as a result of what we did in notepad earlier when we captured the first request to our site. Again, it should be like this: Cookies: {firstCookieValue};{secondCookieValue}


Now click on​​ Execute, you’ll see that Fiddler captured the request in the list of requests on the left side.​​ Dobule-click on the request entry, you’ll see in the bottom right side (the response area)​​ in the​​ XML​​ tab there’s an entry for FormDigestValue:​​ 


Right click on this value and select​​ Copy, and head back to the Composer tab​​ where you were working, below the Cookies entry add this:​​ 

X-RequestDigest: {ValueofRequestDigest}​​ 

Change the URL to {YourSite}/_api/sitepages/communicationsite/create

So far you should have something like this:​​ 



So far so good! Now we have the Request Digest, we can make Post requests to SharePoint (Remember, you can make Get requests to SharePoint using only the Cookie entry without having to use X-RequestDigest. We only use X-RequestDigest to POST new data to SharePoint).​​ 

So, we got the Request Digest, what data do we need to POST to SharePoint? As we changed the URL to /_api/sitepages/communicationsite/create , that’s the end point to create new communication sites, so we’ll need to provide the info for this site in the request body (the bottom text area in Fiddler as shown in the previous image). Type this:​​ 



"Description": "Site created from Fiddler",​​ 
"Title":"Communcation from Fiddler",


Try hitting Execute now, you’ll see an error in Fiddler on the left side:​​ 

It will tell you that you need to add a Content-Type in the header which we didn’t do, let’s add that, so go back to the Composer tab, and add the content type header as:​​ 

Content-Type: application/json;odata=verbose



Now hit​​ Execute​​ and you’ll see that you’ll get an entry in the requests area in the left pane with a result of 200, which means that the request was successful, if you navigate to the site specified in the Url in the request body, you’ll see that it’s created and it’s based on the Topic site design.​​ 

Note if you need to create an empty communication site or if you want to create one based on the showcase site design, you’ll need to add the SiteDesignId to the request body like this:​​ 


"request": {
"__metadata": {
"type": "SP.Publishing.CommunicationSiteCreationRequest"

"Description": "Site created from Fiddler",
"Title": "Communcation from Fiddler",
"Url": "https://yourtenant/sites/CommFromFiddler",
"SiteDesignId": "f6cc5403-0d63-442e-96c0-285923709ffc"


The above snippet will create an empty communication site. Showcase site design ID =​​ 6142d2a0-63a5-4ba0-aede-d9fefca2c767 .. and omitting the SiteDesignId will create a topic communication site.​​ 


An error you might face making a request to SharePoint is:​​ 

The type of data at position 5 is different than the one expected.


If you see this, make sure the request body you have is surrounded by curly braces { } not starting right away with​​ “request” : ..


I hope this was useful for you and you learned something new! Happy SharePointing!​​ 

Exception calling “SaveAsTemplate” with SharePoint 2019

I was trying to use PowerShell with a modern site (Communication site in my case) to save a list/library as a template and getting this error:

Having the UnauthorizedAccessException can be little confusing, so what’s the catch?

To solve this, we’ll use PowerShell, code looks like this:

Microsoft introduced prevented custom scripts from running by default in SharePoint online, and now with the introduction of modern sites in SharePoint 2019, they’re prevented by default in modern sites in SharePoint 2019. With custom scripts feature enabled, saving the site as a template and saving lists/libs as a template won’t be possible, hence you get the UnauthorizedAccess error. When custom scripts is active, the DenyPermissionsMask propert of the site collection will be: “AddAndCustomizePages” .. in order to allow custom scripts, it has to be “EmptyMask”.

You’ll need to run this command:

$site.DenyPermissionsMask = [Microsoft.SharePoint.SPBasePermissions]::EmptyMask

Now you can save the list/lib as a template.

Hide Upload Button + CSS Tip!

At times, you want to hide something that’s rendered by default in SharePoint, for example some of the ribbon’s controls rendered right away with the page. I’ve seen some people going with the way of hiding the whole “New” group in a document library in order to prevent user from using the upload or new folder options.

For the new folder, everyone knows it can be easily disabled from the library’s settings, but for the Upload button in the ribbon, you can use pure CSS to do so, but you will need to find the right selector, and use it right. We all know how to use developer tools to pick the right css classes, so as can be seen below:


So you might be tempted to do something like this:

And.. that won’t work, you might be tempted as well to add !important to the end to force it to apply, but again.. it won’t work. It’s because CSS considers the dot character as part of the css itself to identify a class, and it won’t understand it’s part of the ID. In this case, you need to use escaping characters in CSS which is the backslash!

So your code should look like this:

Now you should end up with something similar to this:


Hope this will quickly help someone out there!

Why can’t you hide web part on a wiki page?

I saw this post on the MSDN where the user can’t hide the web part when he adds it on a wiki page. I thought he might done something wrong.. so I tried the same thing, and yes, you can’t hide the web part on a wiki page, then I tried to hide the web part on a web part page, and yes, it’s hidden, so what’s the problem here?

The point is that you can’t hide web parts unless you turn on the publishing feature, so when you turn on the publishing feature on the site collection, hiding web parts on any page will be possible.!

Getting started with troubleshooting Nintex Workflows!

Currently I have been helping a friend of mine fixing some Nintex Workflow 2010 issues, one of the issues he had was an error appearing in the workflow stating that:

The workflow could not update the item, possibly because one or more columns for the item require a different type of information”.

OK…! As can be seen; this error (along with other SharePoint generic errors) doesn’t give us much detail about the problem, you can’t start investigating this kind of problems without copying this error message and pasting it in Google and start Googling.

The purpose of this article is to know how to troubleshoot a workflow without needing to search on Google, and for sure to tell you what caused this error.

Nintex workflow is like any other workflow tool (ex: SharePoint Designer), it will provide you with a set of actions that you can use to construct the logic of the workflow and achieve what it is intended to do. Let’s take the scenario of an approval workflow, where the submitted document goes to the manager along with a custom notification email, upon approval or rejection, the document will be sent to the next manager, or to the initiator to tell him the reasons of the rejection, if the workflow consists of only one approval step, it would be easy to troubleshoot, because the scope of the problem is limited to only these few actions, but what if you have a workflow that consists of: Switch statements, foreach, state machine, long approval process (more than 5 approvers)? If you get an error in these steps, it will be tough to figure it out.

Here comes the need for something to trace the workflow and to know where the workflow actually went wrong, one way (easy way) is to use the workflow history diagram, you can get to this diagram from the item’s options menu, view the figure below:


When clicking this option, you will be redirected to a page with all workflows that are running on the current item, as can be seen, there are 3 categories where the workflow on the current item can be categorized:


As you can see, our workflow instance is classified as an erroed workflow, if you click on the workflow name, you will see where the workflow really stopped:


The yellow background means that the workflow stopped here, if the workflow passed the action, it will be colored green, but in our case it’s yellow, which means that the workflow has stopped at this action. If you click on the “Click here to show detailed view”, you will be transferred to a page detailing the workflow error, in our case, we didn’t configure the outgoing email settings in Central Administration, so the workflow errored on sending email action:


The problem with this kind of troubleshooting is that this diagram is not always accurate, it might be freezed on specific actions although the workflow has passed these actions. The better way to troubleshoot the workflow is to add your own tracing values, suppose that the outgoing email settings are configured in Central Administration, but you may also get an error in the workflow for some reason (your mission is to know what’s that reason), or the workflow ran without any issues but the logic that the workflow executed is just wrong!

In this case we can use the awesome “Log in history list” action, this action is useful if you are making some calculations in the workflow and you want to make sure that the result of these calculations are right, or if you are having an error in the workflow, but the workflow history diagram just got stuck (which sometimes happen), in this case it would be best to log to the history list before any major action that you think would cause an issue, like sending emails, assigning tasks, granting and revoking permissions, etc..

When the workflow is running or stopped, you can just navigate to the workflow history, by clicking on the workflow’s status column in the list view, and if you have logged for example: “Next action: Sending an email to Marketing Manager”, and it was the last log that was written before an error is occurred, you will know directly that the action responsible for sending an email to the marketing manager is making the trouble for you. This way you will guarantee you will know what the exact error is regardless the fact that the workflow history diagram may work or not.

Back to the error stated in the beginning of the article:

The workflow could not update the item, possibly because one or more columns for the item require a different type of information”. The workflow history diagram was stuck on an action, but in fact the workflow wasn’t really stuck, so don’t always trust the workflow history diagram. Placing a log to history action before main workflow actions, I could know what was causing the error, it turns out that the cause is done by “Set item permissions” action, in this case the action was misconfigured to break the inheritance from the library, AND remove all users permissions was checked, so on the next item edit, the workflow will throw an error, see the figure below:


As can be seen, the item was breaking the permission inheritance from the parent library, and it also removed the permissions that already existed on the current item, which will prevent the modification of the item.

After testing the workflow thoroughly; make sure to remove/disable the log to history actions because each action inserts a new item in the history list in SharePoint, which you should not do in order to avoid filling the list with arbitrary testing values.

Conclusion:  You can get away with a short process workflow without doing the extra effort of adding log to history list action, you can use the workflow history diagram but you can’t always trust it because it can get stuck sometimes and not show you the real progress of the workflow.

Creating Dynamic List Menu For SharePoint Foundation 2013 Navigation

Hello Everyone, today’s article is going to have an intensive information about how to style the navigation menu for SharePoint Foundation 2013, in this case, we’ll have some common requirements, and we’ll go through how to achieve them to deliver a nice looking menu for the top navigation.


The requirement that we have this time, is to create a menu which will include sub-items (dynamic items) that will appear when we hover over the static menu item.

We need all static menu items to have the following characteristics:

1- To be in uppercase format, meaning all letters in the sentence should be capitalized.

2- To have the white color, and a custom color: #f0b530 in case of anchor hover (Note that some of the static items maybe used only as containers for dynamic list items, and don’t act as hyperlinks).

The characteristics for the dynamic list that appears when we hover over a static item that contains sub-items:

1- To have the width of the maximum li that will appear inside the list, if you have a list item that will be 400px long, the ul should stretch to fit that size.

The characteristics for the dynamic items inside the list:

1- To have the “>” before each item

2- To have only the first letter in the sentence as capital letter, only the first letter in the sentence.. remember that!

3- On hover, to have a custom color, same one mentioned earlier: #f0b530

These are the requirements, so let’s get to the solution, shall we?!




First things first, for my example, I use the following css to set the background color for my menu:

.ms-core-listMenu-horizontalBox {

background-color: rgb(163,160,143);

text-transform: uppercase;


Now we will need to style the static menu items that act as a container for my ul, to give them a white bold text, use the following css:

li.static span.dynamic-childrenspan {

color: white;

font-weight: bold;


As you see in the image below, the background color gave us a nearly grey background, and all letters in the static items are uppercase as required, note also that they are bold and white colored which what the second css snippet does.


Now, what if we hover over the “RESSOURCES HUMAINES” item, ul should be displayed with all items inside, and we should have the ul width to equal the longest item inside, also all items should have the first letter capitalized, and prefixed with > character, so use the following css for that:

li.dynamic {

height: 25px;

width: 100%;

white-space: nowrap;


The style above, gives a height for each item inside the list for 25px, and a maximum width it can get, which is 100%, also the white-space: nowrap, it prevents the item from breaking to a second line when it gets to a specific width, this is a MUST USE.

Now we’ll add > before each link as follows:


width: 100%;

content: ” > “;


In this case we are using a pseudo class for the anchor to prefix it using the content property.

We need the anchor tag to have the white color by default, not the blue color:


font-weight: bold;

color: white!important;


And when hovering, to have the custom color:

li.dynamic:hover a {

color: #f0b530!important;


But what about having it all in small letters, and the first letter in the sentence to be capital letter? You might think you would get a way with Text-Transform: Capitalize, but wait a minute, this property will capitalize the first letter of EACH WORD, remember we want only the first letter of the first word, we’ll use the following snippet:

li.dynamic span {

display: inline-block;

text-transform: lowercase;


li.dynamic span:first-letter {

text-transform: capitalize;


The first style, will change the display for the span to inline-block, this is because in the second style we want to use the :first-letter, and this pseudo selector works on block elements only (span by default is not block), and we also transform all text to lowercase, in the second style, we get the first letter of the span, and capitalize it, nice ha?

To the last part, to style the ul itself to make it stretch, convert the display to inline-table, and give it a large z-index so it’s always shown when hovering:


display: inline-table;

z-index: 10000;


That’s it, now you should have something that will be similar to this:


Enjoy your SharePoint designing now!

M . D

Error deploying ContentType with FieldRefs

Another Problem-Solution post, and this time it’s going to be quick on a problem you may face deploying a SharePoint feature in Visual Studio.

The error this time states: “Error occurred in deployment step ‘Activate Features’: Key cannot be null. Parameter name: key”.

Again, the error here is not descriptive and doesn’t give us a clue on what the problem is. What will help us is using the output window in Visual Studio to track where the problem occurred (I followed this technique and applied it to workflows in Nintex to troubleshoot problems there, view this post to know more about troubleshooting Workflows).

So the output in Visual Studio provides us with a step by step details on the deployment process, in my case the deployment errored on activating a feature that included only content types, so I know where to investigate now.

What I noticed in my xml that deploys the content type, is that there is a specific content type that references the fields this way:

<FieldRef ID=”{9EDAB26E-CC44-4027-AB05-CB44EA3A6F72}Name=”EmployerName“/>

<FieldRef ID=”{8406B0D9-9302-4BCD-917A-404558F3C9A0}Name=”CustomerFullName” />

<FieldRef ID=”{395B72D8-90D8-4A68-ACDC-C423B205B276}”  Name=”CustomerFeedback” ></ FieldRef>

The way that the CustomerFeedback field was deployed was different than the others, as you can notice it has a separate tag as the ending tag, and the deployment process expects that something has to be inside this field reference, but there is nothing, so it throws the given error.

Conclusion: When referencing FieldRef inside ContentType project item, make sure you don’t have a separate closing tag for the FieldRef.

Hope this little quick tip would help someone out there!

Set the Title column to be required in document libraries (Programmatically)

This is a quick post, that may sound like a straightforward task at the beginning, but may take a long time to figure it out.

If you have ever tried to change the Title column to be required in SharePoint list, you know that all what you needed to do is to get reference to the title column, and set it to required, then update, it may look something like this:

SPField titleField=list.Fields[“Title“];

titleField.Required= true;


But it won’t be that straightforward in document libraries, after all, if you try to make it in the user interface, it won’t be straight forward also.

To make it clear, for example, try to create a document library, and try to create a custom list; in the custom list you will have the option of making the title either mandatory or not, but in the document library you will need to access the content type first, then making the title mandatory in that instance, but the purpose of the article this time is to how to do that programmatically. So here it is:

SPField titleField = list.Fields[“Title“];

SPContentType docCtType = list.ContentTypes[“Document“];

SPFieldLink fieldlink = docCtType.FieldLinks[titleField.Id];

fieldlink.Required =true;


This way you will update the properties for the title column inside the document library.

Hope that helps.

M . D

PowerShell Error When Restoring Site Collection

SharePoint doesn’t allow the backup of a site collection and restore it in the same content database. If you backup a site collection and restore it, it will give you the following error.

So you need to make a new content database in the web application (in case the replication of the site collection at the same content database) so that the backed up site collection and the restored one are in different content database, but be careful to put the first database offline before you restore the new site collection.


HTML6 .. Already?

There have been a lot of buzz on the internet about the release of HTML6,  and seems like it’s going to replace a lot of stuff we used to do with JavaScript (if it’s approved) .. more than HTML5 could do.

The idea is to have <FIXTURES> tag in the Head tag of the HTML page, this Fixtures tag is a repository of code, each code block is called a model, and this model can either be static or it can be retrieved dynamically from SQL. These fixtures are then referenced in the body tag. So in the body tag of your HTML page you can reference chunks of HTML content that was declared previously in the Head tag, which can be static or dynamic, without needing JavaScript. This seems to be the replacement of the Single Page Application model (SPA) that’s currently implemented using some JavaScript frameworks such as Angular. So each part that will be changed will be inside a model in the Fixtures tag.

To read the proposal for the HTML6, have a look here: