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
The plugin files do not need to contain plugin headers, so you just need to create a PHP file and that’s all.
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
|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
|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
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.
Pingback: I’ll Miss You Mu!! at bavatuesdays
Pingback: Force Plugin Settings for All Sites in Multi-Site | Big Big Technical
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-pluginsdirectory 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-pluginsdirectory. That’s why I just had to do when I moved the plugins over.
Hope this helps.
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.
Pingback: How to Debug Redirect Problems in Wordpress | hakre on wordpress
Pingback: Zajímavé články o WordPressu (v angličtině) « Fórum podpory WordPressu
Pingback: How to Filter the Genesis Sidebar Defaults
Pingback: WP Engine Support Garage » Debug Mode Warning
Pingback: Un plugin para poner un entorno multisitio de WordPress en modo de mantenimiento