jethin

You’re right BC. I had actually tried many different permutations of the different WP role/capability methods (some actually typed/scoped properly) and nothing seemed to work properly on the administrator role. As you mentioned, I think there are some “certain exceptions” when dealing with the administrator role. In addition to problems with meta caps like edit_users, my experience was that the administrator role was tied in with super admin capabilities on individual network sites. (Super admin was essentially acting as a regular admin on network sites).

In any case I ended up writing a plugin to set the roles/caps for our network sites. It was a more complicated process than I expected, but I believe the plugin works well. If it’s helpful to anyone else, some of the issues I needed to address were: setting capabilities by role on activation/deactivation, adding meta capabilities separately, checking permissions on particular pages/routines, and filtering editable roles.

As far as I know my plugin cannot be network enabled to work across all sites. It has to be activated on each individual site.

So if you’re not stubborn like me I’d recommend skipping this whole process and using a readily available plugin.

Thanks for your help, but I’m still not able to solve this issue. According to my tests, using “remove_cap” on admin role (via plugin) does not succeed. For instance admins can still remove users despite running the function below:

function remove_theme_capabilities(){
global $wp_roles;
$role->remove_cap( ‘admin’, ‘remove_users’ );
$role->remove_cap( ‘admin’, ‘create_users’ );
$role->remove_cap( ‘admin’, ‘delete_users’ );
$role->remove_cap( ‘admin’, ‘list_users’ );
}
add_action( ‘admin_init’, ‘remove_theme_capabilities’ );

I also tried creating a new default role using “add_role” in a plugin that was network activated. This create the role for the first WP site (wp_options table) but the role was not visible to any other sites in the network.

These are the two ways I’m attempting to solve the issue of setting capabilities for a role across an entire network. Anyone else?

OK, thanks. One more question if anyone is still reading: Is it possible to add a new custom (default) role that is available to all sites on a particular network?

FWIW, I wasn’t able to resolve this issue. I eventually installed a fresh WP and ported/recreated our 8 network sites to it. This was not an enjoyable task. In the end I think the problem may have had something to do upgrading our db from mysql 4 -> 5, but I really can’t say for sure. No v-host settings were changed during the process so I don’t think the error was on the server side.

DB tables wp_site and wp_sitemeta both contain the non-www master domain URL. But I think we’re on the right track here. I think it’s something with domain configuration and/or ‘www’ domain check in the admin somewhere. One other possibility: we don’t have an entry for the master domain in the domain mapping plug-in. (As the master domain it shouldn’t need to be mapped, right?)

PS: if it’s helpful, https://www.domain.com/wp-admin/network yields “Server Not Found” error as expected on current, pre-upgrade 3.0.4 production site.

I can’t try that right now — we’ve rolled back to 3.0.4 until we can try to upgrade again next week. However, there’s no v-host entry for the ‘www’ version of our master domain so Apache shouldn’t resolve it. I’m pretty sure I tried to access the /network/ dir minus the ‘www’ and the browser hung up, just like all of the admin pages beneath the master domain.

Perhaps the simplest way I can say it: Our upgrade seemed to work, but we have no access to 1) any of the super admin options in non-master domain site admins nor 2) any admin pages beneath the master domain, which exists only at (no ‘www’) domain.com.

So perhaps WP admin backend is not recognizing our master domain at all? Or maybe there’s a check for a ‘www’ master domain somewhere that is preventing proper authentication of master domain and/or granting of super admin privileges? Perhaps this is somehow related to a no-www master domain set up?

OK, sorry, terminology is not my strong point. Here’s the lowdown (#1 is the main problem):

domain.com/wp-admin – admin doesn’t work/load . live site domain.com displays.

seconddomain.com/wp-admin (which points to domain.com/site3/wp-admin) – admin works except for network/super admin/domain mapping plugin pages/options. domain.com/site3/wp-admin was not tested and my guess is that it wouldn’t have worked/loaded, as it uses the master domain.

domain.com/site2/wp-admin I don’t believe this URL was tested. My guess is that it would have been the same as above.

One other thing: if it’s helpful, we are using WP network with subfolders, not subdomains. When I say “subdomain” above I mean a non-primary, network site with a domain mapped domain.

Hi. WP is using https://domain.com. The subdomains are set the same, but include a virtual host alias for the www address. There is no ‘www’ alias for the main WP site (ie no https://www.domain.com). I wonder if this might be the problem somehow? htaccess is set to remove ‘www’ from URL on the fly.

The live sites all mapped/displayed fine after the upgrade. The problem was I couldn’t access *any* admin pages through the master domain. I could access admin pages through the subdomains, but had no access to the network pages or the domain mapping plugin settings. I think this may have been because those pages require access through the master domain?

Thanks for your help.

OK, thanks for the tips. However, I tried to remove *all* of my custom entries from the .htaccess file and still experienced the same problem. I’m going to try to update again next week, but does anyone have any other suggestions/thoughts on this? I *think* we may be experiencing the infinite loop problem mentioned by others in the forums. If this is the case, can anyone suggest possible fixes?

FWIW I ended up redirecting the www prefixed site to the non-www domain in our .htaccess file. I might recommend that a feature to handle domain aliases be added to the plugin in the future.

OK. So then to clarify, the best way to map both the “www” and non-www versions of a domain name to the same non-primary, domain mapped site is to create separate records in the plugin for each address?

This is a simple and regularly done convention on the web. I certainly don’t want to “make one blog look like 20 different websites.” I just want a simple way to enable my domain mapped sites to resolve properly whether a user types in an address with or without a www prefix.