Must-Use Plugins and Drop-Ins

Just two simple questions: What are must-use (mu) plugins and what are drop-ins? I’ll answer both right away:

Must Use Plugins

The MU or Must-Use Plugins is a principle that has moved from WordPress MU into WordPress core long before the 3.0 merge. These are standard wordpress plugins files, that are loaded regardless if they have been configured in your blogs backend or not. They only need to be placed in a specific directory, the mu-plugins folder: wp-content/mu-plugins. That feature is available since WordPress 2.8 if I remember correctly. At least since 2.8 it can be configured with the WPMU_PLUGIN_DIR and WPMU_PLUGIN_URL constants.

The plugin files do not need to contain plugin headers, so you just need to create a PHP file and that’s all.

Drop Ins

This term is not that well known. Some core functionality of the WordPress core can be replaced by so called Drop-Ins. Those are PHP files on specific locations that get included if they exist. The inclusion is done for a specific task, for example db.php get’s loaded to replace the default PHP database class. So you can replace it with one that is faster, more stable and secure for example. Drop-Ins exist since various versions, depending on them. The Multi-Site since 3.0 naturally.

List of all WordPress Drop-Ins

File Type of Plugin Loaded Context
advanced-cache.php Advanced caching plugin. on WP_CACHE value Single
db.php Custom database class always Single
db-error.php Custom database error message on error Single
install.php Custom install script on install Single
maintenance.php Custom maintenance message on maintenance Single
object-cache.php External object cache always Single
sunrise.php ‘Executed before Multisite is loaded on SUNRISE value Multi
blog-deleted.php Custom blog deleted message on deleted blog Multi
blog-inactive.php Custom blog inactive message on inactive blog Multi
blog-suspended.php Custom blog suspended message on archived or spammed blog Multi

Source: Data taken from global function _get_dropins() in wp-admin/includes/plugin.php.

All files need to be placed in the wordpress content directory (wp-content by default, defined in constant WP_CONTENT_DIR). Drops-Ins do not need to be full plugin files, they can be just standard PHP files.

WordPress 3.0 will ship with a better plugin listing by the way. It reveals which of those non-standard-plugin extensions are loaded.

Advertisement
This entry was posted in Hacking The Core, Hakre's Tips, Plugin Plugout and tagged , , , , , , , , , , , , , . Bookmark the permalink.

9 Responses to Must-Use Plugins and Drop-Ins

  1. Pingback: I’ll Miss You Mu!! at bavatuesdays

  2. Pingback: Force Plugin Settings for All Sites in Multi-Site | Big Big Technical

  3. Really nice writeup, very helpful, just what I needed today.

    One thing to note is that the Must Use Plugins don’t work like regular plugins which are typically each stored in their own directory with one file that contains a plugin header. With MU plugins WordPress only looks in the mu-plugins directory for .PHP files and not for files in subdirectories so if you want to move regular plugins over to the MU plugins directory you’ll probably need to create a proxy .PHP file. That file should contains a PHP require_once() to include the plugin’s main .PHP from its subdirectory, or you can create a single .PHP file with a require_once() for each of the plugins you have in the mu-plugins directory. That’s why I just had to do when I moved the plugins over.

    Hope this helps.

    -Mike

    • hakre says:

      Yeah. I have some that contain complete library folders in there. Works flawlessly with a require. Combined with php autoloading does a quite decent job.

      I use mu-plugins mostly for incubation, like to test some stub-plugin and if it grows, extend it to a “full” plugin later on. Speeds things up so far.

      The other scenario is, that I copy over some support script in there so I know it get’s automatically executed w/o the need to go to admin and enable it first. One is a hook tracer and the other one is for better error reporting.

  4. Pingback: How to Debug Redirect Problems in Wordpress | hakre on wordpress

  5. Pingback: Zajímavé články o WordPressu (v angličtině) « Fórum podpory WordPressu

  6. Pingback: How to Filter the Genesis Sidebar Defaults

  7. Pingback: WP Engine Support Garage » Debug Mode Warning

  8. Pingback: Un plugin para poner un entorno multisitio de WordPress en modo de mantenimiento

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.