Solving ‘The Ribbon Tab with id: "Ribbon.Read" has not been made available for this page or does not exist. Use Ribbon.MakeTabAvailable()’

Update: Now with its very own Codeplex project:

I came across a problem a couple of days ago, which may be years in the past, or theoretically millennia in the past, if, for some reason, this blog survives and is discovered by future archeologists, in which case: Hi future creatures! I hope we kept the world more or less intact and I do hope that you can find a professor in ancient languages able to decipher this and other texts from our century. You see, I think we had a pretty interesting time, which I’m sure you do too, having advanced probably far beyond anything we can even imagine.

Oh, and if you want to pick up something else from our time, try searching (or asking your data retrieval minion robots or whatever you use in the future) for Dilbert, which is a cartoon. I’m sure it won’t make sense in a future where the cultural references are very, very different, but it’s what I use these days to make me laugh (which may be another thing I hope you haven’t abandoned).

In case, however, that you are an invading alien race who, some time in the future, conquers earth and now go through the loot to see what the extinct human race did: I hope you all burn in hell, you miserable sons-of-bitches (the latter is an insult and you should take it personally and be very sad).

There. Now I’ve pissed someone off in this blog post too.

In any case, the problem:

SharePoint 2010 has a nifty dialog framework that allows you to pop up pages in what seems to be a small window over the rest of the page. I say that it seems to be so, because in essence it’s not a separate window.

That’s not really important at the moment, what’s important is that you have a dialog framework, and you can tell a page to think it is in dialog mode by appending ?IsDlg=1 to the query string. When you do so, and you can do so to any page, albeit with varying success, you get a trimmed down interface without all the extraneous navigation stuff like menus, site actions, and so on.

In the image below, you can see what happens if you do this with a default calendar view.

Solving 'The Ribbon Tab with id Ribbon.Read has not been made available for this page or does not exist. Use Ribbon.MakeTabAvailable()' Figure 1

The problem, however, is that this really doesn’t work for Wiki pages. That’s a shame, because I find that wiki pages are pretty nifty when it comes to editing content.

OK, granted, I hardly use them as wiki pages per se, I just prefer the editing experience to the fixed-layout web part pages.

If you try putting IsDlg=1 to the end of a query string that addresses a Wiki page, you get an exception:

Solving ‘The Ribbon Tab with id Ribbon.Read has not been made available for this page or does not exist. Use Ribbon.MakeTabAvailable()’

Actually, what you get, at least in the user interface is a nice “An unexpected error has occurred.” as you can see below, but digging through the log files using the correlation ID yields the above exception.

Solving 'The Ribbon Tab with id Ribbon.Read has not been made available for this page or does not exist. Use Ribbon.MakeTabAvailable()'  Figure 2

If you Google this term, at least prior to me writing this article, you get squat. OK, you do get the usual suspects, a few people and at least one SharePoint MVP telling you “Just don’t use wiki pages in dialogs”, which is about as useful as telling a kid before Christmas “just don’t be too excited then”. I _want_ to use wiki pages, and I’m not going to let some random bug keep me from it.

So, here’s what I do in situation like these. I Google. Then I get depressed that nobody hands me the solution on a silver platter. Then, I get annoyed, and finally I fix it, usually resulting in one or more of either a blog post, a solution on CodePlex, a USP Journal issue, or a book.

In this case, you’ll get this blog post and a WSP solution you can use to deploy to your farm. No, I can’t be bothered to make it into a sandbox friendly solution, simply because I don’t like Office 365 and because that’s 95% of the reason people want to work with sandbox solutions (which, in development terms, is like sorting peas by size while wearing boxing gloves and a blind-fold).

If you’re the impatient type, or nothing related to development makes sense to you, feel free to just grab the WSP solution now, or, if you’re impatient but understand development, you can get the entire Visual Studio solution.

Solution Walkthrough

I want to make this solution a DelegateControl. DelegateControls have several advantages:

  • You can plug them in on virtually any page
  • You can run .NET code as part of the page life cycle
  • You can activate and deactivate them as features
  • They are dirt simple!

What that means is that you should be able to build a DelegateControl feature on your own. If you can’t, then scroll back up a couple of lines and just grab the completed WSP or Visual Studio solution. Or, if you’re in the mood to learn, check out one of my previous articles on delegate controls.

In fact, I’m not going to detail how you do any of the core SharePoint development stuff. My first instruction will be: Build a basic assembly-based SharePoint delegate control feature. If you can follow such instructions without your head exploding, good for you.

Oh, and this solution is only applicable to SharePoint 2010. That’s right, this solution is explicitly made to not work with SharePoint 2007, and I can guarantee you that no matter how hard you try, you will not be able to solve this problem in SharePoint 2007. If you have this problem in SharePoint 2007, well, you have far more serious problems than this one.

Note 1: I don’t want to force your hand in any tool choices here, but I’ll say this: You’re stupid if you don’t use WSPBuilder, unless you have absolute impeccable reasons to do otherwise.

Note 2: The particularly bright of you will also have realized that the reason this solution wont work in 2007 is that the dialog framework doesn’t exist in 2007.

Let’s get down to business.

Build a basic assembly-based SharePoint delegate control feature.

That shouldn’t be too much of a surprise.

OK, OK, that may be too much for some, but again, I urge you to either download the completed solution and follow along, or pick up on that previous article on what delegate controls are.

The key part here is what happens inside the code that runs, and I’ll be a bit more specific on that. I’ve built my delegate control class to override the OnPreRender method, and although the order of things may matter, I haven’t done extensive testing to discover any benefits or drawbacks from adding overriding earlier methods.

In any case, my base class, augmentet by a few Using statements, looks like this:


using System;
using System.Web.UI;
using Microsoft.SharePoint.WebControls;
using Microsoft.SharePoint;
using Microsoft.SharePoint.WebPartPages;
namespace WikiDialogFix
    public class WikiDialogFixDelegateControl : Control
        protected override void OnPreRender(EventArgs e)
          // We add code here.

I’m not going to detail the usings, but I’m going to let you know that in addition to the standard SharePoint dlls, you also need to add a reference to the far less frequently used Microsoft.Web.CommandUI.

So, add a reference to Microsoft.Web.CommandUI.dll, found in the global assembly cache.

Also note the “We add code here” comment. From this point onward, I’m just going to detail what goes on inside there. In fact, let’s add the first, and actually the only line of code you need, to that method.

Add the following code to your overridden method:


That’s it. Enough to stumble at least one SharePoint MVP and the entire MSDN forums. And, guess what, the solution was written in plain text all along.

I’ll go into a bit more detail in a moment, but first, let’s test what happens now.

Build, deploy, activate, and go to a wiki page before appending ?IsDlg=1 to the query string. In the image below, I have done so on the wiki home page of a standard team site.

Solving 'The Ribbon Tab with id Ribbon.Read has not been made available for this page or does not exist. Use Ribbon.MakeTabAvailable()' Figure 3

I’m certain that this isn’t the most exciting thing since SyFy renewed Haven for a third season, but hang on, because this is potent stuff.

Notice that compared to a non-dialog version, there’s no QuickLaunch menu, nor is there a top navigation bar, a search box, any of the Tags and Notes (if you’re into the SharePoint Server scene), no personal menu, no title area, no site actions. In fact, the only thing that remains is the browse and page tabs in the ribbon.

All in all, a much cleaner interface with far less disturbing elements to distract the user’s attention.

But hang on, this isn’t extremely useful, now is it? I mean, how can the user navigate? How do they do all the stuff that’s now not visible anymore?

I agree, this may not be very useful for the front page, but it can be extremely useful in other situations. Before I get to that, however, there are some problems we need to solve.

Problems and More Solutions

First of all, forcibly adding the Ribbon.Read tab may cause a problem. Behold, for example, what happens to the before mentioned calendar view on the left compared to the unaltered dialog view on the right; you now get an additional Browse tab.

Solving 'The Ribbon Tab with id Ribbon.Read has not been made available for this page or does not exist. Use Ribbon.MakeTabAvailable()' Figure 4

So, to solve this issue and also make our code a bit more impressive (in case you’re paid by the code line), let’s add some logic to control how our tab appear.

First, let’s expand that single line of code into manageable chunks. Update your method to look like this:

Page currentPage = this.Page;

SPRibbon ribbon = SPRibbon.GetCurrent(this.Page);

SPContext context = SPContext.Current;

ribbon.MakeTabAvailable(SPRibbon.ReadTabId); //Notice the use of a static variable rather than static text

I’ll tell you why I grab the context in a moment, but first, notice that what we’re doing is exactly the same as before, just over several lines. It makes it a bit easier to read, I think.

Now, I want to add the Ribbon.Read tab only if the current page is a wiki page. After all, that’s the only page that causes the original problem and we don’t want the Browse tab added on pages like the Calendar view.

Unfortunately, I haven’t found a sure-fire way of detecting whether a page is a wiki page. The test I’ve used in the downloadable solution is to check the base type of the class of the current page, but that may not be accurate if you have created your own classes that derive from the WikiEditPage class.

My test, after moving the MakeTabAvailable method call inside the test, looks like this:

if (currentPage.GetType().BaseType == typeof(WikiEditPage))

// OK, not elegant… Feel free to modify.




This solves the problem with the all pages getting an extra Browse tab where one wasn’t before. However, we’re still not quite there yet.

The next issue is that we actually do get a Browse tab on the dialog wiki pages.

Solving 'The Ribbon Tab with id Ribbon.Read has not been made available for this page or does not exist. Use Ribbon.MakeTabAvailable()' Figure 5

Most of the time, that’s not a bad thing. The Browse tab is the only way to get back to ‘normal’ view mode if you go into the Page tab.

However, what if we don’t want that tab there? Since we’re already messing with the tabs and the Ribbon, we might as well go all the way and see how we can remove the tabs completely.

Even more importantly, at least to me, it will let me tell you why I added that context variable earlier. You see, we can’t just indiscriminately remove the tabs on every wiki page. That will cause all sorts of problems on non-dialog views of the pages.

Luckily, Microsoft has been kind enough to add a test to check whether SharePoint thinks we are in dialog view, and that test is a boolean value in the SPContext class. See how it all fits together now?

Add the following test to your code:

if (context.IsPopUI)


    if (currentPage.GetType().BaseType == typeof(WikiEditPage))




This will check whether we are currently in PopUI mode (which, for unknown reasons, means the dialog framework) and only make the tab available if we are in dialog mode.

Once we have done that, we can now hide the Browse button by addin gthe following code, just after the MakeTabAvailable method call:


You’d expect this to cause all sorts of problems. After all, not having the browse tab was what cause the problems in the first place. However, and I’ll happily admit I haven’t dug into the code to see why, this works. As long as you first make the tab available, you can trim it afterwards, and the dialog mode will work for wiki pages.

In the image below you see the result, a dialog framework view, without the Browse tab.

Solving 'The Ribbon Tab with id Ribbon.Read has not been made available for this page or does not exist. Use Ribbon.MakeTabAvailable()' Figure 6

While you’re at it, and because not having the Browse tab makes the Page tab very annoying (remember you can’t exit Page edit mode with no other tabs present), you can remove the Page tab as well, by adding the following line.


Oh, and once you’ve done that, you might as well remove the entire Ribbon, and you do that by setting the Visible property of the ribbon object as such:

ribbon.Visible = false;

The result of this is in the image below, an extremely slick view, with no disturbing elements outside of the page content.

Solving 'The Ribbon Tab with id Ribbon.Read has not been made available for this page or does not exist. Use Ribbon.MakeTabAvailable()' Figure 7

Which reminds me, I promised to give you a couple of examples of when this might be useful.

First, though, let’s quickly take a look at the completed method in the DelegateControl. To achieve the result above, with no ribbon at all, this is the method:

Page currentPage = this.Page;
SPRibbon ribbon = SPRibbon.GetCurrent(this.Page);
SPContext context = SPContext.Current;
if (context.IsPopUI)
    if (currentPage.GetType().BaseType == typeof(WikiEditPage))
    // OK, not elegant... Feel free to modify.
        ribbon.Visible = false;

In the downloadable solution, I have commented out the removal of the tabs so the solution only adds the mandatory Browse tab. However, if you’ve reached this stage of the article, with your mind intact, you’re probably capable of modifying or building the code yourself :-)

Now, let’s talk usage scenarios.

Usage Scenarios

Can you say mobile?

A dialog based interface is much less cluttered and takes far less space than the corresponding normal interface. For mobile devices with smaller screen real estate, that’s good news.

Of course, a successful mobile implementation depends on other navigation options being available. If you simply remove the navigation that’s already there, well, you aren’t going to be navigating a lot, now are you? *tsk*

By checking the IsPopUI context variable you should be able to create navigation components that only show up in dialog based views. However, that’s another show.

Another useful scenario is for appliances, where you want your users to focus on a very small portion of the overall capabilities of SharePoint.

For example, consider a tablet used by an inspector to track boxes passing by on a conveyor belt. You don’t need to full browsing experience, the site settings, the multi-tier navigation options; you want a simple form or even a button to track or perform whatever task the inspector does. However, the inspector may also want to have the option to get the full experience, for instance to read up on a company policy regarding what to do when one is sick and tired of filling in a form or clicking a single button all day.

Using the dialog framework, combined with customized wiki pages for data entry or information visualization, you can create smooth and highly efficient interfaces that does not take away or prevent features, and you don’t even need to leave the web interface.

As if that were a good thing, but I’m digressing…

I hope you enjoyed this little experiment. Feel free to leave comments to let me know how you’d like to use this solution or how you use wiki pages and the dialog framework to build interesting user interfaces on SharePoint 2010.


(Oh, before I forget, future archeologists, or alien invaders, SharePoint is what I use these days to make me cry).

Found this article valuable? Want to show your appreciation? Here are some options:

a) Click on the banners anywhere on the site to visit my blog's sponsors. They are all hand-picked and are selected based on providing great products and services to the SharePoint community.

b) Donate Bitcoins! I love Bitcoins, and you can donate if you'd like by clicking the button below.

c) Spread the word! Below, you should find links to sharing this article on your favorite social media sites. I'm an attention junkie, so sharing is caring in my book!

Pin It