I have the following problem: the ribbon bar gets hidden by default for the users of a site collection, so they must enable it manually by using the "Show Ribbon" link on the site action menu.

This is only added noise for most of the user, and make the site unusable for user that cannot reach the "show ribbon" menu because they don't have access to the site action link.

I really hope that this behavior isn't the standard one (it would be very very lame if such).... so I am struggling in finding how to set the ribbon to stay open by default. Any idea?


Based on Oc3LoT answer about the limited access, I have made some more in-depth tests. It would seem that the ribbon starts closed for user that don't normally see the "site action" menu. In that case, the ribbon get hidden too (I remember reading somewhere that the site action link is actually IN the ribbon, or at last uses the same css classes) and the user won't have any way to display it.

This is indeed strange: if I navigate to a document lib the user has access to, the ribbon is displayed, but if I create a page with the out of the box document library web part the ribbon remains hidden - even if I select a file in the web part. This doesn't make much sense, so I am still wondering if this is standard behavior or if I am missing something somewhere...

NOTE: as a reference, this question Show Ribbon always to Visitors is indicating the same behavior/problem. Notice that this is not a duplicate. I am searching a way to always provide the show/hide functionality (at last when it is enabled in site setting), or at last make the ribbon visible by default (not always visible, I want user to hide it if they really want to).

Also, while a solution to the problem is indeed wanted, what I would really like is an explanation of what is the reason behind this misbehavior.

Almost found it. The show/hide ribbon buttons actually work by setting a cookie called ConsoleVisible[GuidOfTheSiteCollection]. After some attempt of setting it via JavaScript thru a content editor web part in the end I moved it to a control delegate built with a code based on this answer found on another site (link here).

I am posting the class code as a reference here, credit to the original finder. Notice that I had to make some minor editing to avoid some bad timing (now the logic runs OnLoad) in my solution.

public class SetRibbonDefaultVisibleControl : WebControl
   protectedoverridevoid OnLoad(EventArgs e)

   internal static void ToggleConsoleOn()
      var cookieName = CookieName;
      var current = HttpContext.Current;
      if (!current.Request.Cookies.AllKeys.Contains<string>(cookieName)
         current.Response.Cookies.Add(new HttpCookie(cookieName, "true"));
         current.Response.Cookies[CookieName].Expires = DateTime.Now.AddYears(1);
         current.Items[CookieName] = "true";

   internal static string CookieName
      get{ return ("ConsoleVisible" + ContextualSite.ID.ToString()); }

   public static SPSite ContextualSite
     get{ return SPContext.GetContext(HttpContext.Current).Site; }

Had originally posted this as an answer, but it seems that the cookie is totaly ignored for visitors. Basically if the site action menu is hidden the above doesn't work (image taken from the other post linked above, but it gives you the idea).

enter image description here

Now I am exploring yet another dungeon, (Master) sword in hand, to see if I can find the evil behind all this...

EDIT 2: I guess that I have found the class responsible for all the above.


Inside this class there are some method that seems to control the "console" visibility. Those method seems to depend on the "site action" menu visibility -> user permissions on the site. To cite 300 "This is madness!", but I guess that this kills any hope of displaying the ribbon via a codebehind script.

  • See answer to following question. [sharepoint.stackexchange.com/questions/21773/… [1]: sharepoint.stackexchange.com/questions/21773/… Commented Jul 1, 2013 at 0:16
  • I like your solutions and I don't care about the visitors for now - but I also have been in the debugging dungeon in the ConsoleVisibleUtilities for me the problem is that the status bar is hidden even though the page is checked out to another user. Turns out that the check f (SPContext.Current.FileLevel != SPFileLevel.Published) fails as the page is found out to not be checked out. I used your solution and it works flawlessly now - always have the status bar even if the page is checked out to another user.
    – Dennis G
    Commented Sep 12, 2014 at 12:50

3 Answers 3


Site Actions -> Navigation -> Show and Hide Ribbon Setting Make "Show Ribbon" and "Hide Ribbon" commands available to No should prevent the ribbon from disabling and requiring folks to enable it. It should also make it available all the time for everyone.

  • That was my belif too, but it seems that it simply disable that ui switch. The ribon then will start hidden, with no way to display it. Commented Dec 19, 2012 at 16:59
  • Is this a publishing site and/or does it have anonymous access enabled?
    – webdes03
    Commented Dec 19, 2012 at 17:02
  • Yes publishing site without anonymous access. I can add that it seems to be related to permission somehow -> I am trying to dertermine if some user always see the ribbon. Commented Dec 19, 2012 at 17:09
  • ... Seems that the user is in a group with Reader + Limited Access permission. Commented Dec 19, 2012 at 17:19
  • 2
    The Limited Access permission won't affect your ability to view the ribbon. All the Limited Access permission is is an indication that the user has a different permission level to something else within the site collection. Basically, if you break inheritance somewhere, you'll see Limited Access pop up. As far as the ribbon goes, you can always override it's visiblility within the CSS of the page. Commented Dec 19, 2012 at 19:51

As I posted in the question, the class Microsoft.SharePoint.Publishing.WebControls.ConsoleVisibleUtilities - which seems to control ribbon visibility - contains some check that require the user to have specific permission on the site. This means that server side the ribbon is already "removed" if the user fails to match certain requirements - thus giving no hope to fix that "client side".

The suggested option

Site Actions -> Site Settings - > Look and Feel - > Navigation -> Show and Hide Ribbon Setting Make "Show Ribbon" and "Hide Ribbon"

works only by disabling the ability to hide the ribbon. That means that user that can hide/show the ribbon will always see the ribbon, but an user that starts with the ribbon closed will remain with a closed ribbon. This is not optimal for my requirements, but can be sufficient for others. It is also worthy to notice that list pages seems to follow a little different logic - ribbon seems to be displayed even if the user hasn't got required permission (all command are disabled as expected).

For now I am using a surrogate solution by giving to all user a minimum permission that allows them to see the ribbon everywhere. Since I am working in an intranet context this could be done, but I fear that it can't be a valid solution for an extranet context.

For now I am accepting this answer to compensate accepted % stats (I'm not so glad-os of this, but no choice for now). If you have a better answer fell free to add here - I promise to have a look and reconsider accepting any solution you may provide.


Listed below is a possible surrogate solution as mentioned by SPArchaeologist that involves modifying the "Read" permission level and giving it the "Manage Personal Views" permission.

  1. Click on "Site Actions -> Site Permissions"
  2. On the ribbon select the "Permission Tools" tab and press the "Permission Levels" button under the "Manage" group on the far right
  3. Click on the "Read" Permission Level
  4. Scroll down to the "Personal Permissions" section and check the box for "Manage Personal Views - Create, change, and delete personal views of lists.
  5. Press the "Submit" button

After that your visitors should be able to see the ribbon and the only elevated permissions that you gave them were to be able to modify their own personal list views.

This solution was pulled from Bernado-Nguyen-Hoan's blog entry Visitors can't access ribbon on publishing pages in SharePoint 2013 but works just as well for SharePoint 2010.

  • Interesting. Seem worth checking. I will try to check this and the blog post you linked. Have my vote for now. Commented Dec 14, 2015 at 21:19

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.