Admission: I am a tech-freak. My idea of Christmas presents this year? WEB SITES FOR EVERYONE! Now, I made this decision and just started purchasing domain names. As an afterthought (I know…great time to think about it), it occurred to me that I am the only web-minded person in the family. Great! Now everyone has a website that they are going to want help maintaining. Great planning, kruser! Then it hit me (again…my timing is impeccable), I have WordPress MU! Problem solved. But wait, there’s more. One of the sites was for my niece, a rather web-centric person as well. I wanted her to have full reign of her own domain instead of being bound to my themes and plugins. I figured making her an Administrator of her domain would solve this issue. NOPE! Well, damn…back to square one!
NOTE: If you are not well versed, or at least adventuresome with your hosting service and database management, just skip this article!

The Situation

I want to essentially create a role half way between Site Admin and Administrator. Surprisingly, there is not a way to do this that I can find. This role should include all menus and options except the ‘Users’ and ‘Options’ submenus of the ‘Site Admin’ menu. In my opinion, it would be simple to add this functionality to Toggle Admin Menus, but I am not a plugin-writer. I just need to ensure that I have Site Admin rights to all domains I own, for legal reasons more than anything. Not that my niece would be a concern, but in the future, when I have multiple domain admins, I want to be able to oversee all backend settings while still giving them the freedom to be an actual admin. In my opinion, the administrator role defined in WPMU is weak. Ok…enough about that. For clarity, we will use ‘domain1.com’ for the main site(s) and ‘domain2.com’ for the site you are wanting to assign a different user table for.

I am basically only doing this so that my niece can have the ability to install/update her own plugins and themes which, as anyone with WordPress can attest, is arguably THE most important part of making a site your own.

Step 1. Install the plugin.

As usual, I consulted my twitter friends for advice. Answers varied from, “No idea, bro!” to “Just install WPMU on her domain” and everything in between. Frustration. Anger. Fury. When all of a sudden, a ray of hope. @wpmuguru (of wpmututorials.com) replied with a touch of sanity. Out of left field comes a direction to go in…Simple Multi-Site Plugin. After some reading and emails, I decided to purchase the plugin (actually it is two plugins and two ebooks) and give it a shot.

The difference between Simple Multi-Site Plugin and MU Multi-Site, as I am told, is that Simple Multi-Site Plugin actually creates new blogs for new domain registration whereas MU Multi-Site only simulates it. While this helped with some of the permissions separation issues, it did not completely solve my problem.

I exported all of my blogs on all of my domains and backed up my database. I then deleted all of my blogs/domains and installed the new plugin, following the step-by-step instructions included in the ebook. Next, I re-added all of my domains and imported my blogs. I then logged in to domain2.com and created a Site Admin, expecting everything to have been worked out. While most of my issues were now resolved, two remained.

Problem One

The Site Admin for domain2.com still had the ability to delete users from domain1.com. Not acceptable. I still had some work to do. Again, I consulted the master, @wpmuguru. Together, we found a solution (I say together…really it was just that he told me what to do!). The issue is that when a user logs in to any of the domains on the WPMU installation, the same user tables are used: wp_users and wp_usermeta. Now, while the next steps solve problem one, problem two still exists.

NOTE:

The following steps are only advised if you know what you are doing. DO NOT PROCEDE if you do not. Neither I, nor thekruser.com or any of its affiliates are responsible for any issues arising from performing the following steps. You have been warned.

Step 2. Create copies of tables.

Login to your hosting provider and navigate to phpMyAdmin. Locate the wp_users and wp_usermeta tables. You will need to create copies of these tables and name them wp_X_users and wp_X_usermeta where “X” is the site ID of the domain2.com. You can get the site ID from the ‘Sites’ submenu under the ‘Site Admin’ menu. Copies can be created in the ‘Operations’ tab. Be sure you select ‘Copy structure and data’ when asked. This will create a complete copy of the tables and all the users defined within it. If you only copy the structure and not the data, you will not be able to login to domain2.com after completing step 3.

Step 3. Edit wp-config.php.

Using the editor of your choice, open wp-config.php (located in the root folder of the WPMU installation) and add the following code directly following the opening notes where “X” is the same number as used above and “domain2.com” is the domain in question (minus the quotation marks, of course). Make sure the domain name is surrounded by single quotes (‘).

if( strpos($_SERVER['HTTP_HOST'], 'domain2.com') !== false ) { define('CUSTOM_USER_TABLE', 'wp_X_users'); define('CUSTOM_USER_META_TABLE', 'wp_X_usermeta'); }

If you do not insert the above code before any of the existing .php code, it will not work. Found that out the hard way!

Step 4. Test.

I would not advise skipping this test. Login to domain1.com with the main Site Admin account and create a test user as an administrator. Log out. Delete browser history and cookies. Login to domain2.com with the Site Admin account created in Step 1 and make sure the test user you just created does not appear. If it does, verify that you have followed the above steps exactly and try it again. Do not proceed to step 5 until a test user created on domain1.com does not appear on domain2.com’s user list in the ‘Site Admin’ menu.

Step 5. Delete unneeded users.

You will notice that users listed have all of the sites they have permissions for listed to the right. By clicking on the links, it will take you the admin page of the specified domain, regardless of the Site Admin account used. Security problem. Delete all unneeded users (all except the main Site Admin account and the Site Admin account created in Step 1). If everything is done correctly up to this point, none of the deletions will effect the user accounts of any of the other blogs. We should now have domain1.com and domain2.com created with separate Site Admins.

Problem 2

Although the above solves the problem of the ‘Users’ menu issue, we still have the ‘Options’ menu problem. A Site Admin has the ability to delete all users except the ‘admin’ account created at the time of the WPMU installation. This is a feature of the Simple Multi-Site Plugin. This attempts to guarantee that the original Site Admin still has access to domain2.com through the ‘admin’ account. However, the password for the ‘admin’ account can be changed in the ‘Users’ submenu and by going into the ‘Options’ submenu, any Site Admin can remove the accounts from the Site Admin list. While all other domains are now secure, there is no way to completely ensure that the original Site Admin will continue to have unrestricted access to the backend. The only thing the original Site Admin can do if their account is deleted from domain2.com, or if their password is changed locking them out, is delete the entire site. Not a very good solution.

In conclusion, the above is more of a partial hack than a finite solution. I would imagine that I am not the only person experiencing this problem. If you have any info to add, or if my directions do seem clear enough, please leave a comment to help everyone. If you have a solution that does not entail all the above, PLEASE let us all know!! Thank you for reading. I hope to hear from you.

Multiple Site Admin Permission Solution in WordPress MU…Kind Of is a post from: thekruser.com

Those of us that use WP-Slimbox2 plugin for WordPress (by Transient Monkey) have the simplest Lightbox/Slimbox integration yet. All we have to do is include an image link in the post, and WP-Slimbox2 does the rest. There is only one problem with it: by default it only autodetects .jpg, .png, and .gif file extensions. This is fine, if those are the only file extensions you use. What if you have some .jpeg or .bmp files referenced? It does not autodetect those extensions. Luckily, there is a fix.

Open slimbox2_autoload.js.php in your favorite code editor. It should be located in wp-content/plugins/wp-slimbox2/javascript folder of your WordPress installation. The following code should be located on line 35.

return /\.(jpg|png|gif)(\?[\d\w=&]*)?$/i.test(this.href);

Add the file extensions you would like WP-Slimbox2 to autodetect inside the parenthesis. Make sure you separate the file extensions with a pipe (Shift+backslash key on most QWERTY keyboards), also called a vertical bar. To add .jpeg and .bmp file extensions, your code should look like this:

return /\.(jpeg|bmp|jpg|png|gif)(\?[\d\w=&]*)?$/i.test(this.href);

Once you have made the necessary additions, be sure to save the file. WP-Slimbox2 should now autodetect your additional file extensions.

Did this post help you? Be sure to send it to your friends. Did I get something wrong? Please let me know by leaving a comment below. I would love to hear from you.

Get WP-Slimbox2 to Autodetect Additional File Extensions is a post from: thekruser.com