A great developer once said to me why take 30 minutes to do one thing when you can spend hours automating and never have to spend those 30 minutes again. He had just completed developing a theme template, it had taken months but now our theme development speed had doubled.
This was the approach I took to a recent challenge. We are migrating our clients’ sites from WPEngine to WPMU DEV, this in itself was a process that took some time to research and learn, but that is for another time. As part of this migration I had taken some time to learn about the different plugins offered by WPMU DEV and the white labeling that could be done with the WPMU DEV plugin and the Branda plugin.
I was going through documentation on how to design and implement the white label, we were looking to create a seamless white labeling that would elevate our hosting and promote our company on our hosted sites.
While going through all this a problem arose with permissions, an issue that a fair few developers might face who offer hosting on WPMU DEV. We want to offer our clients the freedom to access their site, to add, edit, update and remove items as they see fit. To add users they want to add, to improve their site, to continue developing and growing their site.
To do this they need to be an Admin and this is where we came into our permissions issues. As many of the sites were already setup with clients having admin privileges we needed to find a way to setup and configure the WPMU DEV plugin and Branda plugin so that only our developers could use and access it, without constantly having to fiddle around with settings and to somehow hide it from only certain admins and not all admins.
Permissions could be added manually but we often have different developers on different sites, so any site could have 1 – 7 developer users on the site. To go through all the sites we were migrating and checking each one for the sites for developer users would have been a labour intensive task. What we needed was a solution that would automate the process as much as possible.
Our Plugin Stage One
I began by looking into the WPMU DEV plugin, this plugin linked out sites to WPMU DEV and provided users with access to all the WPMU DEV plugins, as well as white labeling, debugging and many more features. After reading documentation and talking to the WPMU DEV support team I had the define(‘WPMUDEV_LIMIT_TO_USER’, 1, 2, 3);
This bit of code created a variable that, if defined, would overwrite the normal permission functionality and just provide permission to access the WPMU DEV plugin to any users whose ID was entered in the list. This was better but would still have taken to much time as we would need the ID of every dev user, this was not going to work as the final solution but we had taken a step closer.
To get the ID’s we needed to create loop that would go through the users and locate the ones we wanted. One idea was to do it by email but sometimes we have freelancers and they would need access to. This is when we decided to create our own custom role called Pie Admin.
The Pie Admin would have all the same privileges as a normal admin and we could use the role to loop through all users and find those with the role Pie Admin and add them to the list as such:
$users = get_users(array(
'role' => 'pie_admin'
));
$pie_admins = wp_list_pluck($users, 'ID');
if (!empty($pie_admins)) {
define('WPMUDEV_LIMIT_TO_USER', implode(',', $pie_admins));
}Fortunately, WPMU DEV already has logic that hides the plugin if you are not a defined user, as such this is all we needed to hide the plugin from our users and ensure it was never accidentally removed by a client. Now when we wanted someone to be added to the list we just had to assign them the role of Pie Admin.
Now you may be thinking but won’t you have to go through every site and make all the developers Pie Admin you would be right. To automate that, another loop was created but this one searched for anyone on the site with the company email, the user would then have the Pie Admin role added to their roles and be granted permission for the WPMUDEV plugin.
The Second Phase
One of the things that had drawn our attention to WPMU DEV was the white-labeling, allowing us to customize the client experience on a website we hosted and we wanted to take full advantage of that.
The issue was that the Branda plugin was by default available to all users with admin privileges. This again was one of the reasons we had decided to add the Pie Admin user, but unlike the WPMU DEV plugin there was no hook to add the users, and no hook to change the default settings for permissions, so we found a workaround.
What Branda did have was the ability to ignore all permissions connected to the user roles, this meant that only defined users would be able to see the plugin in the admin menu. However, this left us with the issue of adding or defining every single Pie Admin user in the permissions for the plugin, as unlike WPMU DEV there was no hook to add users.
To overcome this we added a check for the Pie Admin role in the current user roles, if the user did not have the Pie Admin role then the filter hook was run returning an empty list of allowed roles.
add_action('admin_menu', __NAMESPACE__ . '\hide_plugins_from_side_bar');
add_action('network_admin_menu', __NAMESPACE__ . '\hide_plugins_from_side_bar');
function hide_plugins_from_side_bar()
{
$current_user = wp_get_current_user();
if (!in_array('pie_admin', $current_user->roles)) {
add_filter('branda_permissions_allowed_roles', '__return_empty_array');
}
}What this did was ensure that any admins who did not have the user role of Pie Admin would not have permission to see or use the plugin. The reason the if statement was required was because it meant that any Admin who was also a Pie Admin would be able to finish the setup and configuration of the plugin which was to simply click the permissions for all Pie Admins.
We later added two WordPress remove_menu_page functions for the tip post type we added from the Branda plugin and one for the WPMUDEV Videos, which is video tutorials to teach users how to use their wp site.
add_action('admin_menu', __NAMESPACE__ . '\hide_plugins_from_side_bar');
add_action('network_admin_menu', __NAMESPACE__ . '\hide_plugins_from_side_bar');
function hide_plugins_from_side_bar()
{
$current_user = wp_get_current_user();
if (!in_array('pie_admin', $current_user->roles)) {
add_filter('branda_permissions_allowed_roles', '__return_empty_array');
remove_menu_page('edit.php?post_type=admin_panel_tip');
remove_menu_page('wpmudev-videos');
}
}The Third phase
This was all working well on single sites but we hit a snag when we tested the functionality on multisite installs. We were unable to find a way to create our own version of super admin with the pie admin instead so the only solution seemed to be adding the pie admin to the super admins’ roles, this way our code would not need to change too much.
To achieve this we added a new field to the user page on multisite installs, a dropdown which allowed you to select an additional role for the super admin. To this, we added the Pie Admin user and then ensured that when the user was edited, updated, or changed the user would have the role Pie Admin added to their user roles.
function custom_user_role_meta_box_callback($user)
{
$selected_role = get_user_meta($user->ID, 'custom_user_role', true);
echo '<h3>Custom User Role</h3>';
echo '<table class="form-table"><tr>';
echo '<th><label for="custom_user_role">Select Custom User Role:</label></th>';
echo '<td><select name="custom_user_role" id="custom_user_role">';
$selected = selected($selected_role, 'pie_admin', false);
echo "<option value='' $selected>Select Role</option>";
echo "<option value='pie_admin' $selected>Pie Admin</option>";
echo '</select></td></tr></table>';
}
// Save the selected custom role when the user profile is updated
add_action('personal_options_update', __NAMESPACE__ . '\custom_save_user_role');
add_action('edit_user_profile_update', __NAMESPACE__ . '\custom_save_user_role');
function custom_save_user_role($user_id)
{
if (current_user_can('edit_user', $user_id)) {
$selected_role = sanitize_key($_POST['custom_user_role']);
update_user_meta($user_id, 'custom_user_role', $selected_role);
}
}Phase four
With the functionality sorted now came another issue, the plugin itself was still readily available for users to deactivate and remove. This would remove all our clever hiding, remove our special user roles, and stop some of our team from accessing the WPMU DEV plugin and the Branda plugin.
Our initial idea was to hide the plugin in a similar way to how the Branda plugin had been hidden, this way we could run updates like a standard plugin but not have to worry about it being deactivated or deleted. However, this seemed like a less secure option than using it as a MU plugin. As an MU plugin, we would be able to ensure it was never accidentally deactivated or deleted.
This became the new plan but came with its own issue; new releases. If all the logic was to be stored in a single MU plugin then we would need some way of ensuring that the file was replaced whenever a new update was launched.
To solve this issue we added a version option to the WP database, tracking the version of the current plugin, if the version on the install is higher than the mu-plugin, then the file would be replaced. This ensured that we could update the plugin in a standard fashion, creating new versions and running the update through the WordPress plugin page.
Conclusion
While the process was more complex than installing and configuring the individual plugin, due to the amount of times we would have to re-do the process it would have made the process exhausting.
The plugin allowed us to create an expandable and evolving solution that will allow us to continue improving the process of migration and also develop our hosting experience on WPMU DEV. We already have thoughts on how we can improve the staging environment and move the site between staging and production more easily.