Ribbon gets hidden by default. How to fix that?

Question

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?

EDIT:

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)
   {
      ToggleConsoleOn();
      base.OnLoad(e);
   }

   internal static void ToggleConsoleOn()
   {      
      var cookieName = CookieName;
      var current = HttpContext.Current;
      if (!current.Request.Cookies.AllKeys.Contains<string>(cookieName)
              &&
          !current.Response.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).

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.

Microsoft.SharePoint.Publishing.WebControls.ConsoleVisibleUtilities

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.

Answer 1

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.

Answer 2

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.

Answer 3

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.