WordPress MU

How do I make all or some plugins active by default for new users?

put them in the mu-plugins folder.

That doesn't seem to work. For example, with Akismet. I put it into the mu-plugins/akismet/ folder but it's not active.

well, not all plugins work out of the box from the mu-plugins fodler, some have to stay in plugins folder or need to be modified to work from the mu-plugins folder.

Akismet requires either an enterprise key to activate or else your users will have to register at wordpress.com to get an api key.

Plus, you can't just drop a dir into the mu-plugins dir. They don't work like that exactly. There has to be a file in the mu-plugins dir for it to work. If that file calls a subdir, that's cool. But the main file has to be in mu-plugins.

@lunabyte, thanks for the tip. mu-plugins is different than plugins in this areay.

@corourke that's true, however each user can signup for their own key, putting it into mu-plugins just activates it for all blogs

True, it does make it available to each blog, but be careful of what you put in mu-plugins.

Every plugin you stick in there will be loaded and parsed on every page load, whether a user is actually using it or not. Not good unless it's something that is actually used for each blog.

Me personally, I'm pretty selective about what I put in there. Things like my default post title (to kill blanks) is an example of something I'd stick in mu-plugins. SK2 is another example.

I also have plugins that I only want for my main blog/site, so I put in a mod to add another special plugin directory that works like mu-plugins, but is only called for blog_id 1.

With akismet, I'd (again, personally) leave it in the plugins directory unless you plan to get an enterprise key. Other than that, not every user is going to want to get a key for it.

From looking at wp-admin/plugins.php, it looks like WPMu does a:

do_action('activate_' . $plugin);

When a new plugin is activated. I would think adding that but with the name of the plugin into the empty blog script in wp-includes/wpmu-functions.php like we do for extra links would do it.

Doesn't work for me. I do:

$ekoplan_plugins = array('wikimap/WikiMap.php');
update_option('active_plugins', $ekoplan_plugins);
wm_install();

in the function "install_blog" in the file "wpmu-functions.php".

"wikimap/WikiMap.php" is the plugin file. "wm_install" is the installation function of the plugin (wikimap in this example). find this function by searching for "add_action('activate" in the plugin file.

buzink could you explain this a little more, I had a look at the wpmu-functions.php file, but I'm not sure where to put your code. Sorry I'm not a php programmer, but given some hints of what's going on I can figure out what's happening, and I'm learning by doing. Does a new line need to be added for each plugin? Sorry for my ignorance of php, but as I said, I'm learning as fast as other responsibilities allow.

Does it matter where your code goes in the install_blog function? Could this be made into it's own plugin so that we wouldn't have to edit the wpmu-functions every time we add a new regular (not a muplugin). I'm thinking that if this was done as a plugin it could call up the "Premium Blogs" plugin that seems to be in the making and then plugins could be activated by whether the new blog is a regular blog, a premium blog or there could even be different levels of premium blogs. My interest in this aspect is not for paying customers, but for different ages of students. Younger and less sophisticated students get fewer options to confuse them, but I'm rambling.

Also, I don't know if this is the place (you can never say thank you too many times), but a great big thank you to the Wordpress and Wpmu programmers and everyone in the forums who keeps helping those of us who are programming challenged, but want help others who are even less sophisticated with computers find their voices online. Thanks

I use WP MU 1.2.3 and I hope I worked around way how to make certain plugin active by default for every new blog, and it is quite simple.

Just edit file wp-includes/wpmu-functions.php and find function "install_blog_defaults"

and I put after line:

$wpdb->query("UPDATE $wpdb->options SET option_value = '$user->user_email' WHERE option_name = 'admin_email'");

this line:

$wpdb->query("UPDATE $wpdb->options SET option_value = 'a:1:{i:0;s:29:"cryptographp/cryptographp.php";}' WHERE option_name = 'active_plugins'");

this make active plugin "Cryptographp".

This code

a:1:{i:0;s:29:"cryptographp/cryptographp.php";}

is copied from Mysql DB, where was this plugin already active. Hope this will help somebody.

Thanks, I'll give it a try.

I installed http://www.cimatti.it/blog/2007/02/12/cimy-user-extra-fields-for-wordpress-21/
into mu-plugins. I got a ton of errors:

Warning: in_array() [function.in-array]: Wrong datatype for second argument in …/blogs/wp-content/plugins/Cimy_User_Extra_Fields/cimy_user_extra_fields.php on line 885

So I installed in plugins rather than mu-plugins. Same error. I then deactivated and activated in plugins. The error went away.

When plugins are run from mu-plugins they are active, but are they ever activated? i.e. there's likely setup code hooked into the activate action that was not run.

from my experience, theyarent activated. any process that relies on actual activation i.e. database changes, page creation - are lost. that fouls up a lot of plugins for me.

Plugins are promised as part of the API that they will be activated. This promise should be honoured.

WTF are you talking about?

If you use a plugin as its author intended, in the plugins directory, then it's fine. Any decision on your part to deviate from that is your choice and not something the developers should be responsible for.

Mu-plugins is for special, limited cases.

Plugins work just fine, as promised.

So, I am missing something? I was under the impression that mu administrator should place a plugin in mu-plugins if they want that plugin to be active on every blog.

For certain things, yes.

It isn't like "auto activation", it's more like "auto execution".

For example, you want a common footer across all blogs. OK, so you make a function with the output in it, hook into wp_footer, and there you go.

Back when widgets were not part of the WP core, you could stick the main widgets plugin file in there, as another example.

However, if it's just a regular type plugin (one mainly targeted at WP), which hooks into the plugin activation process, then you'll either have to recode how it hooks into being activated, or keep it in the plugins directory as its author intended.

There are some plugins that MU admins want active for all users. Many plugins need activating.

The plugin's author doesn't know that "activation" will not happen, instead the plugin's just starts running. MU does not follow the startup sequence of wordpress.

Now, I agree that each of us can code around it. But having every MU admin recode how the plugin gets activated seems wasteful, and putting it in plugins directory doesn't achieve the goal of having it active for all users.

Is there a reason MU can't be modified to activate plugins installed into mu-plugins?

So an author that doesn't make an MU compatible plugin that can run without the activation hook is now a problem of the developers?

IMHO, that's insane.

You're suggesting an unintended use for something that doesn't work that way. So just how would something that is automatically loaded, be turned on, when to "activate" it you simply have to drop it into a directory?

If anything, the logical path would be for the plugin author to make adjustments for their plugin so that it could be used in that manner.

mrjcleaver, why not submit the code to do this?

Gotta admit I just have a quick plugin where the database tables are created upon blog creation via a hook.

Reasons I'm not likely to submit code:

1) Comments like the ones above: "WTF are you talking about?" and when I explained "IMHO, that's insane." There's a protocol (i.e. sequence) of calls that WP makes to plugins, WPMU should honour the same sequence. If someone tells me definitively, or worse, ridicules a suggestion, it's going to discourage my contribution.

2) Last time I submitted code was 11/04/06:
http://trac.mu.wordpress.org/ticket/109 (http://mu.wordpress.org/forums/topic.php?id=2265&page)
If I submit code and its not even acknowledged, it's going to discourage my contribution.

3) In http://mu.wordpress.org/forums/topic.php?id=2685&page&replies=6#post-35961 I asked "If we contribute code ... will our changes get rolled in..."

drmiketemp> Honest answer though - I'd say no.

If I ask, and there's no hope of it being incorporated, this is going to inhibit my contribution.

Now, I do appreciate Dr. Mike's honesty and the fact that the response was for a particular case.

But, putting together (1), (2) and (3) I wonder whether there are things we can do to get more contribution?

I'd mention the wiki http://mu.wordpress.org/forums/topic.php?id=748&page&replies=12 to consolidate what needs to be done but for some reason this community is beyond wanting one. Quite why, I just don't understand.

I'm not submitting code either anymore.

"1) Comments like the ones above: "WTF are you talking about?" and when I explained "IMHO, that's insane." There's a protocol (i.e. sequence) of calls that WP makes to plugins, WPMU should honour the same sequence. If someone tells me definitively, or worse, ridicules a suggestion, it's going to discourage my contribution."

MU-PLUGINS IS NOT THE PLUGINS DIRECTORY.

MU-PLUGINS IS NOT THE PLUGINS DIRECTORY.

MU-PLUGINS IS NOT THE PLUGINS DIRECTORY.

It's a special directory for simply having auto-executed files. Nothing more, nothing less.

If you want a plugin automatically activated, code it. That isn't "exactly" what mu-plugins is intended to do. It runs/parses files within it.

MU DOES honor the same plugin calls, within the PLUGINS directory.

That's the facts, Jack.

If you would like to break out of those particular parameters, feel free to recode a plugin to your liking.

Really... please get a grasp of what the provided features of each directory are.

As it doesn't honour the plugins interface, including activate, mu-plugins is badly named then, isn't it? It's not providing a full "plugin" interface.

I would check the facts but the facts are sprawled all over the forums. These "facts" are duplicated and inconsistent.

Please. Get a grasp on what poor documentation is doing to this project.

*chuckle* Poor docs are typical for most Open Source projects.

Wordpress is reasonably well documented. MU is not.

Laughable, but the joke is on this "community".

So why are you here then?

There's an old saying, I guess.

Those who can, do. Those who can't, teach, bitch, moan, and whine.

No, mu-plugins is NOT badly named. Just because you can't grasp the concept doesn't mean it's wrong.

Wordpress is reasonably well documented.

Actually I disagree with that statement but not enough to start a discussion on the topic. Most of the docs are written for someone with a decent background in internet theory and PHP. A soccer mom would have a lot of trouble working out the codex. Heck, many times I've had to sit there and think about what I had just read.

*chuckle* And we tell folks that mu is the one that requires the expansive background....

The difference between the two plugin directories should be in the readme.txt file though. Someone care to open up a trac ticket, maybe with an explaintion between the two please?