WP Dev – Plugin conflict… no problem!
I am the author of the WP Welcome Email editor plugin. I wrote it a few years ago to solve a problem in WordPress.. something which has yet to be solved although various plugin alternatives are available. My plugin allows editing of the WordPress welcome email and a few others as well (reset password etc..). I seem to have a small percentage of people who generate a lot of support work for me due to plugin conflicts. Frustratingly the way that WordPress works with some of it’s ‘pluggable’ functions is like this:
<?php
if (!function_exists('function_name')) {
function function_name() {
//code here
}
}
?>
The issue with this is that if a plugin wants to ‘override’ (declare their own) then they need to declare their own function before the pluggable.php file is run. Sounds simple you think but some plugins cause pluggable.php to be prematurely called which means that we lose the opportunity to override any of these functions.
We also have the added level of frustration of plugins conflicting when fighting to declare their own function to override the same piece of functionality. For instance if you were to install a plugin which allows the customisation of emails within WP and you installed my WP Welcome Email Editor then both will want to do the same thing but only one will work. This is primarily down to the name of the plugin and/or the order in which plugins have been activated. Annoying right! It’s the luck of the draw and of whether you like to prefix your plugin names (such as my adding sb_ before most of mine).
The simple solution is to rename your plugin so a-sb_welcome_email_editor.php for instance. Then reactivate it. Yes this does work for a while but the next time the plugin is updated it will be renamed based to the original file name and then no longer work.. therefore making it not a sustainable solution.
Luckily WordPress has a database ‘option’ which stores the currently active plugins and the order they will be loaded in (whether intended for the latter function or otherwise… someone has to be first!). I have developed a small chunk of code which runs on a page load to essentially find the plugin it’s being called from and move it to the top of the queue. A coding queue jump if you like.
Before posting the code I shall add this this should ONLY be used when you actually need your plugin to load first. This really is only when we are registering methods as overrides to integral WordPress ones. Or if you need to get ahead of a plugin that causes your override to be unsuccessful. Mostly you can get around plugins loading first using the priority system with add_action or add_filter.. just pass a priority less than 10 and your method will load first.. actions and filters default to a priority of 10 so it’s nice and easy to define where you need to be in the queue.
So add this to your plugin with your own prefix. This was taken from my welcome email plugin hence the sb_we_ prefix.
function sb_we_priority_load_plugin() {
$wp_path_to_this_file = preg_replace('/(.*)plugins\/(.*)$/', WP_PLUGIN_DIR."/$2", __FILE__);
$this_plugin = plugin_basename(trim($wp_path_to_this_file));
$active_plugins = get_option('active_plugins');
$this_plugin_key = array_search($this_plugin, $active_plugins);
if ($this_plugin_key) { // if it's 0 it's the first plugin already, no need to continue
array_splice($active_plugins, $this_plugin_key, 1);
array_unshift($active_plugins, $this_plugin);
update_option('active_plugins', $active_plugins);
}
}
add_action('init', 'sb_we_priority_load_plugin');
Good luck.. please code responsibly 😉
About this site and Sean Barton
0 Comments