2 comments

1. Directly from source for pluggable.php:

   <?php
   /**
    * These functions can be replaced via plugins. If plugins do not redefine these
    * functions, then these will be used instead.
    *
    * @package WordPress
    */
   ?>
   

   So, there’s your answer, the functions in pluggable.php are intended to be overridden by Plugins.

   Re: load order:

   See this post by Konstantin Kovshenin. The relevant points (10-15):

   1. wp_get_active_and_valid_plugins() retrieves the list of all active plugin files for loading and includes them. This is the point where your plugin code gets executed, functions, classes defined, etc.
   2. Includes wp-includes/wp-pluggable.php and wp-includes/wp-pluggable-deprecated.php which include functions (and deprecated functions) that can be redefined by plugins. Like wp_mail() for more advanced mailing, wp_authenticate() for alternative authentication methods, etc.
   3. wp_set_internal_encoding() is called to set the internal encoding according to the blog_charset option.
   4. wp_cache_postload() is called if object caching is enabled.
   5. At this point a plugins_loaded action is fired. This is the very first action (after muplugins_loaded fired before loading the non-multi-site WordPress plugins) that you can hook into, it comes before the init because WordPress has not been initialized yet, at least not fully.

   So, simplified:

   1. Plugins are loaded
   2. pluggable.php is loaded
   3. plugins_loaded action is fired

   Which is the expected order.

   (Note: this all takes place in wp-settings.php.)

   Log in to Reply

2. Don’t use pluggable functions!

   Please note that you can never be sure, that a later plugin doesn’t override your pluggable! I wrote on wp-hackers mailing list about this some time ago.

   There’s also another thread on wp-hackers that talks about that there’s no fallback implemented. Please also read the related trac ticket.

   Log in to Reply