WordPress Pluggable Functions

Have you ever heard of WordPress Pluggable Functions? If not, then this article should draw your attention. In two words pluggable functions are WordPress core functions that you can override. All these functions are located into one single file: “wp-includes/pluggable.php“. Pluggable functions were introduced in WordPress 1.5.1, but in the most recent versions of WordPress this method isn’t used anymore. Recent functions now use filters on their output. But you can still override pluggable functions, and this is what I would like to cover in this post.

How to Override Pluggable Functions

Well this is pretty simple, all you have to do is to create a file within your plugins containing an “if ( !function_exists() )…” statement and then re-define the function. I strongly recommend you to copy and paste the original function when you start. This is way you’re sure that the function will work. Here is an empty example:

I’d like to talk about the “wp_notify_postauthor()” function. This is the one responsible of sending an email to post’s authors when a new comment is added. In one of my plugin, the WordPress Issues Manager, i needed to disable this notification, but a specific custom post type only. So, i copied the whole function, and simply added this:

That’s simple, but that works great without having to make huge changes or to create a full custom function hooked to a custom action.

wp_mail()

As you saw in the pluggable functions list, wp_mail() is a pluggable function. This function is the one used for sending emails. Anywhere in WordPress when an email is sent it uses this function. That’s why customizing it can be very interesting. For example you could use an html default template for all emails sent from your WordPress install.

You could also send an hidden copy of every message to a specific email to have a kind of backup (trust me this can be useful when someone tells you he did not receive the message!).

wp_authenticate()

You could also modify wp_authenticate() and add some extra parameters to enforce security on your site (brute force attacks for example).

auth_redirect()

This function is the one that checks if a user is logged in, and if not it redirects them to the login page. That would be pretty easy to override the function and redirect the user to a custom page, instead of the default login page (for example if you want to hide the wp-admin folder).

wp_generate_password()

This function is the one that auto-generates passwords. Honestly you don’t really need to modify it, but now that you know what brute force attacks are, you could be interested in creating stronger passwords. Well, this is the function to improve.

Conclusion

To conclude this short post about WordPress pluggable functions, I’d like to point the fact that new functions don’t work like that anymore. As I wrote above they are now using filters. But pluggable functions are important functions in particular when creating really specific plugins. But be careful when using pluggable functions. If the newly created function isn’t working perfectly it can break a part of your website (in terms of functionality), so please test them in all conditions.

Remi is an expert WordPress developer that coded many great free and premium themes and plugins. His experience on WordPress allows him to produce great stuff and to propose advanced tutorials. (remicorson.com)

How do pluggable functions apply to simply creating functions in a Child Theme’s functions.php file. I’ve also done it as a standard practice to wrap any function I put into a Child Theme inside the ‘if ( function_exists() ){}’ construct. My assumption is that it safeguards the function from breaking anything else that may or may not already exist.

Moving forward, is using the filter hook a more stable approach to applying custom functions inside a Child Theme?

Because a child theme is meant to override a parent theme and plugins, then there really isn’t any need to create “pluggable” functions, I mean you won’t be creating a child child theme to override the child theme

Wrapping in if ( function_exists() ){ } is a good habit, but it’s unnecessary if the point of a child theme function is to override a parent function.

Regards to the filter hook…it really depends on what you are accomplishing. In some cases you can’t override a function with a filter and you must duplicate the function.

I’m getting that a child theme has top priority in overriding functions. And that if a function needs to be overridden in the parent, it can happen in the child only if the original function is in a pluggable construct. However, that’s not necessary the best practice. And that’s where filter hooks come in. But as you said, filter’s don’t always necessarily override the function, so you must duplicate it.

As far as organization of the global namespace is concerned, the pluggable construct, as well as proper naming conventions, is just a good idea to keep everything playing nicely together.