TWD

Dang! You are right.

Need to get my eyes checked.

Thanks bruh.

I see, so the JavaScript will just replace the existing “nav a” element, right?

If so, BOTs will still find the “Register” link since they are crawling the DOM before JS kicks in.

Hence it would be better to add it to the page via JS AFTER the link was removed, no?

We cannot deactivate “Register” because we still need people to register user accounts on the site as part of a membership signup checkout process, but NOT from the Login page.

I’m not sure I follow.
Don’t you mean that I should CHECK the “Hide Register / Lost Password” link?

Because your Javascript is adding it back to the page, yeah?
So that would make sense if it was removed to begin with.

Same for me on Plugin version 4.3.4 WP 5.5
PHP 7.2
Apache.
SiteGround hosting.

Notice: register_rest_route was called incorrectly. The REST API route definition for instant-images/test is missing the required permission_callback argument. For REST API routes that are intended to be public, use __return_true as the permission callback. Please see Debugging in WordPress for more information. (This message was added in version 5.5.0.) in /home/site/public_html/mysite.com/devel/staging/wp-includes/functions.php on line 5225

Notice: register_rest_route was called incorrectly. The REST API route definition for instant-images/download is missing the required permission_callback argument. For REST API routes that are intended to be public, use __return_true as the permission callback. Please see Debugging in WordPress for more information. (This message was added in version 5.5.0.) in /home/site/public_html/mysite.com/devel/staging/wp-includes/functions.php on line 5225

Notice: Undefined variable: suffix in /home/site/public_html/mysite.com/devel/staging/wp-content/plugins/instant-images/instant-images.php on line 88

Yeah thanks. But I still need users to be able to “register” as part of a subscription signup workflow.

I just don’t want them registering on the Login Page.

This is my question as well.

Does it work with Gravity Forms?

Resolved.

Thanks again for everyone’s help.
This is the final code.

add_action('init', function() {
  if (function_exists('is_user_logged_in')){
	if (is_user_logged_in()) {
		add_filter('body_class','add_role_to_body');
		add_filter('admin_body_class','add_role_to_body');
	}
        function add_role_to_body($classes) {
          $current_user = new WP_User(get_current_user_id());
            
          if (current_user_can('manage_network')){
             $user_role = 'super-admin'; 
          } else {
             $user_role = array_shift($current_user->roles);
          }
            
          if (is_admin()) {
              $classes .= ' role-'. $user_role;
          } else {
              $classes[] = 'role-'. $user_role;
          }
              
          return $classes;
        }  
  }
});
/* Add logged in user role as a body class for front or back end*/
/* Note - the class is added as part of a string for backend, array for front */

Check the link.
If you contact the firm behind Code Risk and verify that you are the
plugin maintainer they will fill you in on the code vulnerabilities.

So would this work?

if ( current_user_can('manage_network') ) { do_something(); }

• This reply was modified 4 years, 8 months ago by TWD.

following

OK. Thanks. This plugin makes sense now.

fyi I needed to add a space in front of the “string” version otherwise
the role class name gets concatenated to whatever class name was at the end of the string.

QUESTION: On a WordPress MultiSite situation, it seems like it still returns “role-administrator” for a network super admin.

Is there anyway to adjust the code to add a DIFFERENT body class for Super Admins?

STill no answer ?

Facebook gonna facebook. ??

Does it work on MultiSite?

Update:

I tried to simplify this:

if (is_admin()) {
            $classes .= 'role-'. $user_role;
          } else {
            $classes[] = 'role-'. $user_role;
          }

into this:

$classes[] = 'role-'. $user_role;

which throws a fatal error while logged in as Admin.

Fatal error: Uncaught Error: [] operator not supported for strings

So I am left wondering why the $classes variable is a “string” when logged in as admin but an “array” when not??