User Role is Not Specifying in WordPress Multisite?

I want to use same user and user meta for all site meaning that
everysite will use same usermeta capabilities it will be more useful
for me because I want to use mycred plugin and I don’t want any
issues** ( More Useful )

This is the crux of the problem, specifically:

everysite will use same usermeta capabilities

Every site is already using the same user and user meta, the problem is that roles and capabilities are not stored in user meta! They have a separate table

So What if I shared the roles tables too?

That won’t work. If the roles table says you have editor status on site #3, we now have a problem because you have multiple multisite installs. Does it mean site #3 on sub1.domain.com? Does it mean site #3 on sub2.domain.com? There’s no way of knowing

The Problem Runs Deeper Though

Roles and Capabilities are not install-wide, they’re site/blog-wide. I can be an editor on a blog, but an admin on another blog within the same multisite install.

For example, WordPress.com is a giant multisite install. I can create a site and be an administrator of that site, but I don’t have admin access to your site.

By default, if I log into a site, I do not have a user role, which is intentional.

The Misleading Super Admin Functionality

Super Administrators aren’t roles. Each blog has an options table, but there’s another options table that exists across an entire multisite. Inside this is an option with a list of User IDs, this is what determines if you’re a super admin or not.

If your User ID appears in this option, you can do pretty much anything, and it will override and assume you have a capability. It’s a little more involved than that, but that’s a good approximation. You won’t find a super admin role in the roles table.

So How Do I Build A System Where I Give a User A Role That is Everywhere?

A universal role, that you set once, that’s set everywhere? This functionality doesn’t come out of the box, and is counter to how standard WordPress works ( and may have unanticipated side effects ).

At a fundamental level, what you’ve been building is single sign on, but through a fragile system of shared user tables.

So you will need:

  • Somewhere to store the role set for the user
  • Code to read that and set it programmatically, ignoring the user table
  • Code to provide a User interface for setting the role
  • A list of what roles you want, if a plugin adds new roles then those will not be usable unless it’s added to all sites across all installs

I would suggest storing the role in user meta, and using the user edit profile screen. You will also need code to check the roles and capabilities to prevent users changing their own roles. Pay very careful attention to this code as it will be a critical security failure point.

Sadly, doing this may be either difficult, or expensive:

  • The WP_User object doesn’t provide easy filters, it may be necessary to note down a role and all its capabilities and provide your own WP_User replacement, this could well cause compatibility problems
  • You could check on every page load if the users role matches what it’s meant to be, and set it if it isn’t. This would be more expensive, but more reliable and more compatible

I would note though, that all of this is going to be costly to maintain. Your setup has pushed you into a corner of high technical debt, and this is one of the costs.

How Other People Do It

When you rebuild the system in the future, consider a SSO/Single sign on system. Federated login such as those provided by OAuth or SAML is the longterm answer here. IN that scenario you would provide the authentication level to the site when the user logs in ( the login may be a seamless redirect if the user has already authenticated with the SSO provider ), then set the appropriate role when the user is passed back to the site.

It is true, that you would no longer be sharing user tables across installs, but any information that needs to be synchronised would be set at the central SSO provider and pushed to the relevant sites.