Lewis' Blog Tales from the trenches of information technology

Conditional menus for WordPress with the Suffusion theme and mega menus

The Rosenthal & Rosenthal site is undergoing a major revamp, moving from a static, all-Flash (yech) accumulation of static pages and compiled Flash objects to WordPress 3.8.1.

In addition to rebuilding on a stable platform, the redesign plan involves a number of new features, some of which I'll document here on my personal blog to try to contribute to the community ¹.

One of the must-have features of the new site is some type of client portal functionality. As accountants, we constantly must handle sensitive data, whether it pertains solely to financial records or includes Social Security Numbers and/or other personally-identifiable informaiton. We've taken to password-encrypting pdf documents, but of course, that's only one-way, and only addresses a portion of the problem ².

So, for client portal functionality, I selected the WP-Client plugin, which is quite feature-rich. It's not a panacea, and does not (yet) address all of our needs, but it's a big step in the right direction. I'll probably have more to post about this component as I get farther into it. For now, suffice it to say that this became the central part of the site design, rather than WordPress or even the public content itself.

I've worked with Sayontan Sinha's Suffusion theme before, and have been extremely pleased with it. It is remarkably flexible, and the coding is quite elegant. In short, it's about as close as one can get to a theme framework like StudioPress' Genesis without, well, building an entire framework.

I knew I wanted to base the new site on Suffusion, and incorporate some elements of the original site, in terms of menu organization, colors, and such. Like WP-Client, Suffusion was a must-have piece of the puzzle.

Portal Ins and Outs

WP-Client handles access levels for clients and staff, which is a huge plus. The plugin does not, however, get involved in any way, shape, or form with actually securing the website itself ³.

There are a couple of possible ways to configure logging into the portal from the front (public, unencrypted) end of the site. Of course the standard WordPress Meta widget is an option, as is the WP-Client-supplied login/logout widget, and the old standby: adding a login option to the main menu.

Wrapping the submit button url in a widget with code to transmit the login credentials via SSL is not only a project unto itself, but any time one embeds secure elements in an unsecure page (the goal was not to force the entire site to HTTPS, but only the sensitive portions of it), the end user usually does not get any type of visual indication from his or her browser that the form data will be transmitted securely. Surely, I could add some text advising the user that the login credentials will be secure and skin the entire widget with some fancy yellow and black "caution" tape or something, but that still requires the end user to take my word for it ⁴.

So, my best bet, then, was to dump the widget idea and go for a menu item for the login page.

Well, okay. Using the WordPress HTTPS plugin (which I highly recommend), I was able to not only add a menu tab to Suffusion's mega menu main navigation bar, but set it to force SSL, thus rewriting the url to https:// for the entire login process. This is where my retentive nature kicked in.

Once logged in, the user is left with the same menu, including the "Client Login" tab. Yes, there is a logout link on the client's portal page ⁵, but it's rather counter-intuitive if the user is already logged in to have a login menu item instead of a logout option. Hmmm...

A Tale of Two Menus

WP-Client provides an option to specify a different menu for logged-in users. This seemed to be exactly what I was trying to accomplish, so I installed the Duplicate Menu plugin, duped the entire main menu, renamed the original "Public Menu," named the copy "Private Menu," and edited it to remove the login menu item and add a link to the logout page instead. I then went back to the WP-Client options and set this new Private Menu for logged-in users.

Unfortunately, while this probably works fine for the standard WordPress menu system, it had the effect in Suffusion's mega menu implementation of adding the new Private Menu right alongside the public one, wrapping to two lines; logged in or logged out.

I tried several variations on that theme before I realized that about the only thing I could use to swap menus was another user role plugin (which seemed not only horribly complicated fro all that I needed, but likely to conflict with WP-Client, as well). So, I sat back and looked at what I had, and what I wanted.

I realized that I didn't need to duplicate the entire menu, as the only difference I wanted when logged in vs logged out was that single menu tab. Javascript? No, because I still had (and have) no real understanding of how the mega menu code works, and I didn't want to have to pick it apart to find out, simply to swap a menu item (tab). CSS? Well, that's great, but one can't actually "swap" tabs conditionally with CSS...or can one?

Appearance vs Reality

I love CSS. I don't do enough with it, but every time I do, I find new and interesting things about the technology. In this case, however, there really wasn't anything new with the technology, just new with my perspective. I didn't need to swap tabs so much as hide the opposite one. Hiding we do with CSS all the time.

Now, if I had been using the plain WordPress menu system, I could have used something like this snippet (note the citation; this was not my original code):

.your-menu-item-class {
    display: none;
}
.logged-in .your-menu-item-class {
    display: block;
}

WordPress Answers, Conditional custom menu? - October 24, 2011, response #1, by Jessica

The essential logic here is to enable CSS classes in the screen options when editing the menu, and assign a given class to the menu item to be hidden when not logged in, and shown otherwise.

This doesn't quite work with Suffusion's mega menu, unfortunately, as the CSS class is assigned/overridden by the mega menu code. However, with a little snooping with Chris Pedrick's Web Developer Extension for Firefox, I was able to suss out the relevant classes for the two tabs, namely, #menu-item-348 for the Client Login tab and #menu-item-348 for the Logout tab. My resulting CSS was:

/* swap login/logout menu tabs depending upon user status */
#menu-item-348 {
    display: none;
}
.logged-in #menu-item-348 {
    display: block;
}
.logged-in #menu-item-290 {
    display: none;
}

I added the above to Suffusion's Back-end | Custom Includes | Custom Styles box and saved, after which I turned off all menu manipulations in WP-Client and deleted the Private Menu I'd created earlier. Problem solved. No plugin. No Javascript. No PHP. Ten lines of CSS including one comment and three closing braces.

The end result is in the eye of the beholder:

...and after logging in:

I purposely placed the logout tab all the way to the right (end) when creating the menu. None of the CSS addresses placement. When the login tab is hidden, Contact Us is automatically shifted to the left into that space.

Not bad for a couple hours of work, huh?

Last Updated on December 5th, 2014 by LewisR