One of the reasons WordPress is so successful, and used so widely, is because it can do almost anything you need, particularly through the use of Plugins. Plugins add new features to a website by extending the core functionality of WordPress. However, not all plugins are created equally, and it’s impossible for even the best plugin authors to predict and account for all possible conflicts a plugin may have with other plugins.
The Problem
Where I work, we use User Role Editor Pro, WordPress MU Domain Mapping, and Redis Cache plugins on WordPress Multisite. We recently realized we were having some odd behavior and eventually determined it was a conflict between the three of these different plugins. Each of the conflicts we were experiencing revolved around features of the User Role Editor Pro plugin not working properly. I was about to contact the plugin author for support, but I tested the plugin on a clean WordPress Multisite and found that none of the problems existed. So, I knew the problem was either caused by our Must-Use Plugins or regular Plugins that we have installed.
WordPress MU Domain Mapping
The conflict we had with WordPress MU Domain Mapping was showing up on individual blogs (sites) when going to the User Role Editor admin page. Attempting to change any capability for a given role would not save. This was because the form action was incorrect (didn’t match the hostname in the address bar) and when the form was submit it would immediately redirect (302) but not pass any of the form POST data and was thus the equivalent of refreshing the page. This was caused by User Role Editor Pro loading before WordPress MU Domain Mapping, and when User Role Editor Pro loads it immediately defines a few constants (in the user-role-editor-pro/includes/define-constants.php file), specifically this line here:
define( 'URE_WP_ADMIN_URL', admin_url() );
The problem with this is that the WordPress MU Domain Mapping plugin filters the admin_url to change it to be the desired domain (which may differ from the original domain), but it hasn’t been loaded yet so it’s unable to do so. Worse yet is that this is a defined constant so it cannot be changed.
There were three possible solutions that came to mind: modify the User Role Editor Pro plugin to not load the define-constants.php file until all plugins have loaded, contact the plugin author to request that they modify their plugin to do so, or force the WordPress MU Domain Mapping plugin to load before the User Role Editor Pro plugin. It made the most sense to go with the third option because it would resolve potential conflicts of this nature with any of the other plugins that we use and it didn’t involve modifying a plugin.
In order to force the WordPress MU Domain Mapping plugin to load first it was simply a matter of manually loading it using one of our Must-Use Plugins. This is a very advanced, and infrastructure-specific, thing to be doing so I’m not sharing the code for that, but I basically ran the same code that’s in WordPress core settings.php file (where plugins are regularly loaded). However, this did fix the problem and we were able to change capabilities in the User Role Editor settings page, on individual blogs/sites.
Redis Cache
The conflict we were having with the Redis Cache plugin was showing up when attempting to “Update Network” in the User Role Editor Pro network admin settings page. What would happen is that the user role capabilities would be updated in the network admin page and on the main site in the multisite network, but the capabilities wouldn’t update on any of the other sites in the network. What tipped me off to the problem was when I looked at the raw database value in an individual sites options table and realized that the capabilities I was modifying were in fact actually set, but weren’t taking effect.
This was the result of Redis Cache not updating the database cache accordingly for each site in the network to reflect the changed user role capabilities. To test this theory it was easy to make a change to user role capabilities, “Update Network”, and then flush the cache in Redis Cache settings and then check if the capabilities were correct on individual sites in the network, which they were.
Knowing the solution was as simple as flushing the cache was easy enough to do, however even with good documentation this procedure was likely to be forgotten several months in the future, or if another admin needed to change user role capabilities. So, I took it one step further and added to one of our Must-Use Plugins some code to automatically flush the redis cache when the User Role Editor Pro plugin updates the network with new user role capabilities.
function my_ure_direct_network_roles_update() {
global $wp_object_cache;
// Check if the redis_status method exists (Redis Cache is installed and active)
// Check if redis_status returns true, which means that Redis Cache has a connection
if (method_exists($wp_object_cache, 'redis_status') && $wp_object_cache->redis_status()) {
wp_cache_flush();
}
}
add_action('ure_direct_network_roles_update', 'my_ure_direct_network_roles_update'); This was a simple solution that automated the process and guaranteed less frustration in the future.
At the end of the day, having these wonderful plugins has saved way more time that I’ve spent in troubleshooting, but it serves as a great example of how plugins can conflict with each other.
Leave a Reply