This was my original WordPress specific blog but alas I never really had any time for it and only a few posts ever gained any traction. As a result it has been all but abandoned and most of it has been merged into my main blog at https://dav3.net/ (please visit my blog there).
I have left this subdomain functional as a few posts did gain some traction and usage, however, as they are mostly old, they are likely not to be very relevant today.
I have posted before about a menu CSS snippet I found to only show menu items to logged in users. I have been looking for a suitably elegant way to reverse this and have a menu item ONLY visible to users who are NOT logged in.
Today I have arrived at a solution. This is not the only solution, and by all means, it’s not the best. But for my needs, this is perfect (see notes in the Conclusion).
This needs to be done in three parts and this will give you the option to have menu item(s) displayed for ONLY logged in users, as well as having them displayed for ONLY guests. The choice is yours and can be changed at anytime easily in the dashboard of wordpress single blog sites, or blogs a part of the multi-site setup–although some of the setup process might not be available to you in a multi-site setup if you are not the super-admin.
Insert the following code into your functions.php file:
add_filter('body_class','not_logged_in_class');
function not_logged_in_class($classes = '')
{
if ( !is_user_logged_in() ) {
$classes[] = 'not-logged-in';
}
return $classes;
}
Add the following CSS to your style sheet:
#menu-mainmenu li.logged-in-nav {
display: none;
}
body.logged-in #menu-mainmenu li.logged-in-nav {
display: list-item;
}
body.not-logged-in #menu-mainmenu li.logged-out-nav {
display: list-item;
}
#menu-mainmenu li.logged-out-nav {
display: none;
}
IMPORTANT: The menu I use for my primary menu is called “MainMenu” ergo my CSS markup above includes “#menu-mainmenu”. Where I originally obtained the inspiration for this source used “#nav”. It may be prudent to first determine what your theme throws out as an ID for the navigation menu. Just check the page source and find out what it is. You want the name of the ID associated with the unordered list that is associated with the list items of where your menu is to be displayed. For example, if you named your primary menu “MyPrimaryMenu”, you should change the above code to “#menu-mymainmenu”. Values I have seen from various blogs include: #nav, #menu, #menu-MENUNAME (without commas of course). DON’T FORGET TO CHANGE THIS.
Create your page, and make sure it appears in your menu. Drag it to the desired location within the menu structure and open the the drop down to the right (downward pointing triangle). On the right under “Title Attribute” there is a text field with the heading “CSS Classes (Optional)”, insert “logged-in-nav” or “logged-out-nav” as appropriate into this box, and save the menu. For something to be visible to only logged-in users, use “logged-in-nav”. For something to only be visible to guests, use “logged-out-nav”.
Since the object of this exercise was to have a menu item displayed for only guests, let’s test it out now. View your blog/website and confirm that the menu item is NOT there when you’re logged in. Log out, and check that it DOES appear. If it’s not behaving as expected go back and check your steps. Also, there are some quick things to check listed below in Troubleshooting.
Once implemented, this setup gives a simple way to chop and change menu items visibility dependant on whether a user is logged in or not. This has not been tested in an environment where user access management is in place. I have tried various plugins for access management, but none gave me the option to SHOW ONLY to guests.
WARNING: There is one downside to this method. The end-user does not SEE the menu item, because the CSS “hides” it from them. It doesn’t altogether remove it from the page source and screen readers may in fact read the menu item–I have no personal knowledge on this. Anyone viewing the source will see these links — whether logged in or not. So unless you have the destination pages “controlled” in some other way, then maybe this method isn’t the best solution. This suits my purposes, but it might not suit yours.
I hope you find this snippet as useful as I did.
Troubleshooting:
Other notes and advice:
References:
For users who use multi-site and found the url redirects on logout don’t work, here’s the solution I found today. It involved a little digging into the mu-plugins directory and a small addition to the code, but it’s not too hard.
It involves editing domain_mapping.php and adding the two lines immediately after the comment (and before the echo statement):
function redirect_login_to_orig() {
if ( !get_site_option( 'dm_remote_login' ) || $_GET[ 'action' ] == 'logout' || isset( $_GET[ 'loggedout' ] ) ) {
return false;
}
$url = get_original_url( 'siteurl' );
if ( $url != site_url() ) {
$url .= "/wp-login.php";
// INSERT AFTER THIS COMMENT - finzend: make sure the redirect keeps working on logout?
if ( ($_GET[ 'action' ] == 'logout') && (!empty($_GET["redirect_to"])) )
$url = $_GET["redirect_to"];
echo "<script type='text/javascript'>\nwindow.location = '$url'</script>";
}
}
This is not my solution, I originally scored this little tidbit from the wordpress support forums. The original appears here. Posted here for reference.
UPDATE: I have now determined how to extend this to show menu items to ONLY guests. Something I’ve been looking at for a while.
I have been searching for a simple way to show particular menu items to only logged in users. I know there are ways of achieving this in php by hardcoding your menu structure within the template for your site, but this involves delving into the source code (which I don’t like doing), and then makes the menu less dynamic to changes. That is, if you later add a page, you have to re-edit the code to have the menu updated…
Until now!
I found this the other day (credit reference below) and with a little CSS injection and associating a class with the menu item, we can have the same end-user effect.
Firstly you need to determine the name of the ID associated with your menu. What you are looking for is the name of the ID of the unordered list, or the div immediately prior to this, that contains your menu items. It will be some derivative of your primary menu’s name. View your source, grab this info and change “#nav” below to “#menu-MYMENUNAME”. It will be all lowercase.
Once you have that, now you need to add some code to your style sheet:
#nav li.logged-in-nav {
display: none;
}
body.logged-in #nav li.logged-in-nav {
display: list-item;
}
Then, simply add the “logged-in-nav” class to the optional CSS Classes field for the menu item (as per the screen cap on the right).
It’s really that simple!
Now any menu items that have this class added to the CSS will only be visible to the end user if they are logged into the site.
If only I could make this work so that a particular menu item was ONLY visible to a guest! Now THAT is my next goal. Unfortunately there is no body class associated with users who aren’t logged in.
Reference: I originally found this snippet and give all credit to Bill Erickson at:
http://www.billerickson.net/customizing-wordpress-menus/#logged-in
Thanks Bill!
NB: There is one downside to this method. The end-user does not SEE the menu item, because the CSS “hides” it from them. It doesn’t altogether remove it from the page source and screen readers may in fact read the menu item, or anyone viewing the source will see these links — whether logged in or not. So unless you have the destination pages “controlled” in some other way, then maybe this method isn’t the best solution. However, for what I want, this is perfect.
I wanted to create an account for my wife, her name is just three letters and so I dug around the interwebs and found this little gem Thanks very much to Lew Ayotte of FullThrotleDevelopment.com.
Supports Multi-sites perfectly. Simply copy the code (below) and place it in a file name of your choosing in the wp-content/mu-plugins directory. Don’t forget to enclose the function (the whole code selection below) in php tags (<?php … ?>)
<?php
function remove_username_char_limit($result) {
if ( is_wp_error( $result[ 'errors' ] ) && !empty( $result[ 'errors' ]->errors ) ) {
// Get all the error messages from $result
$messages = $result['errors']->get_error_messages();
$i = 0;
foreach ( $messages as $message ) {
// Check if any message is the char limit message
if ( 0 == strcasecmp("Username must be at least 4 characters", $message)) {
// Unset whole 'user_name' error array if only 1 message exists
// and that message is the char limit error
if ( 1 == count($messages) ) {
unset( $result['errors']->errors['user_name'] );
} else {
// Otherwise just unset the char limit message
unset( $result['errors']->errors['user_name'][$i] );
}
}
$i++;
}
}
return $result;
}
add_action('wpmu_validate_user_signup', 'remove_username_char_limit');
?>
Please note, this is not my code, I have provided a link to the original source above. I have posted the code here in the event it is no longer available on the original site.
cross post from dav3.net post on this subject
The other day I upgraded my wordpress sites using the backend upgrade and I lost all permissions to access ANY admin area. Any guest could use the site as normal, there were no problems there, but I couldn’t login. It took a few days searching on the web (without luck) and eventually, I jumped back into cpanel, and phpmyadmin and started digging.
The solution was a lot simpler than what I had envisioned.
During the update process, one of the plugins caused havoc in the backend, and when trying to display the dashboard, the plugin was breaking privileges. First I had to work out, which plugin it was, and if in fact if it was a plugin that was the cause. As it turned out, it was, and this is how I found it:
1. created a new folder called “old_plugins” *
2. moved all the plugins from the “plugins” folder to the “old_plugins folder” *
3. logged in – sweet – I was allowed and all appears good
4. visit the plugins page (you will get a warning that your plugins have been deactivated since they can’t be found.
5. put the plugins back into their original directory *
6. reactivate each plugin until you find the faulty one. For me it was a google reader plugin for the dashboard, which I never used anyway – so it’s now gone!
Once you find the faulty plugin, you’ll get the permission error again, simply go back to your ftp or file manager (I just used cpanel) and move the faulty plugin out…
* You could probably have just renamed the plugins folder, visited the plugins page, re-renamed the plugins folder, and gone through the reactivation process that way, this is just the way I did it.