When setting up your WordPress MU environment, it can be difficult to determine whether you want a plugin to go into the /mu-plugins or the /plugins folder. I’ve discussed the difference between the two locations in the past. At this point, I’m talking about deciding which to use based on the knowledge of how they work.

From my perspective, it makes no sense to include any more plugins than necessary across all blogs on your site. All you’re doing is front-loading the page load process and slowing the entire site down. Moreover, having to maintain code that not everyone uses makes no sense, especially if in doing so, you risk crashing your whole site with one bad upload. The best option for both efficiency and stability is to limit available plugins both as mandatory and optional plugins. » Continue Reading…

As I’ve continued to learn about WordPress MU, I have discovered a world which is surprisingly undiscovered, it seems.  The veterans at WordPress are already familiar with how things work, but the documentation isn’t there quite yet (in truth, there’s precious little on even plain WordPress).  Meanwhile, the site WPMUDEV.org has been assembled to help out developers, but that’s woefully incomplete and often inaccurate.

The funny thing is: the WPMUDEV people have recently announced a premium service for those who want to spend a bit of extra cash.  Well, given the inconsistencies of the publicly-available content, I have trouble understanding why anyone would pay extra, but to each his own.

Case in point: the Post Ratings plugin that has allegedly been retooled to work with WordPress MU.  I won’t bore you with the gory details, but suffice it to say, the plugin was most definitely not working on this very basic site.  I decided to take the opportunity to play around with it and see if I could get it to work, and in doing so, learn a little bit more about the way MU deals with plugins.  I’ve decided to go over some basic concepts here before eventually putting them into the WikiMU.

/plugins vs. /mu-plugins

One very confusing concept behind MU plugins is the difference between the two plugin directories.  This seems to be a fairly frequent subject of discussion on the MU forums, but really, it’s not that difficult when you get down to brass tacks.

Plugins stored in the /mu-plugins folder are site-wide, mandatory plugins that the Administrator of the site controls.  Administrators of individual blogs have no control over these plugins and do not see them except where they have an effect on the final product.

Plugins stored in the /plugins folder are available site wide, but Administrators of individual blogs can determine whether or not to include the plugin on their blogs.  Now, the tricky part about this is that there is an option under Site Admin that allows or disallows the “Plugins” menu for Administrators site-wide.  If you don’t check this box, plugins saved to the /plugins folder won’t be available to site Admins to use.

Well, now, hold on a minute. . .  What’s the point of the check box to enable plugin control?  I don’t know the answer to that, but it seems a bit superfluous.  Whatever is the case, none of this is at all obvious when you install MU.

A second challenge is the fact that plugins installed in the /mu- directory shouldn’t just be dropped in and forgotten about. You’d like to be able to set options for these plugins, but so far, I’ve not seen a single plugin that actually provides control panels.

Developing Plugins for MU

It is the lack of control panels that makes working with MU plugins so challenging.  In fact, as near as I can tell, it is precisely this barrier that is preventing me from working with the Ratings plugin in MU.  The plugin requires you to set a default rating icon (stars, bars or squares) and since I don’t have an Admin panel that I can see, I cannot set this option along with who-knows-what other options.

So going forward, I’m going to need to figure out how the Post Ratings plugin creates its panels and hack that to move the panel somewhere accessible.  Any other future plugins will also need to take this need into account.  I still don’t know how they do this yet; I asked the question in the MU Forums and was told that there are plugins on WPMUDEV.org that do this, so I should just check them out.  Well, considering the luck I’ve had with the crappy plugins on this page, I think I can be forgiven if I don’t care to keep pluging in stuff that doesn’t work until I find the right one.

I think perhaps I’m going to try to work on some sort of convention that allows for a plugin to be stored in either the /plugins directory or the mu-plugins directory, changing the admin panel appropriately to match.  But of course, this is all very far in the future.  I’m going to need to have more than an hour to sit down and play if I’m going to work on a project like that, which at the moment is all I have.

I haven’t seen a definitive list of WPMU actions like there is of WP Actions and WP Filters. So, while I don’t have diddly in the way of information for most of these, I’ll go ahead and give you the current list of actions that I’ve found. I’ve included what are my best guesses at the needed arguments, based on context:

switch_blog($new_blog_id, $old_blog_id)
make_spam_blog($blog_id)
make_ham_blog($blog_id)
add_user_to_blog($blog_id, $user_id, $role) /* Adds user to specified blog, assigns role remove_user_from_blog($user_id, $blog_id) /* Removes user from specified blog, does not delete wpmu_activate_user($user_id, $password, $meta)
wpmu_activate_blog($blog_id, $user_id, $password, $title, $meta)
wpmu_new_user($user_id)
wpmu_new_blog($blog_id, $user_id)
wpmuadminresult()
wpmueditblogaction($blog_id)
wpmublogsaction($blog_id)
manage_blogs_custom_column($column_name, $value)
wpmuadminedit()
archive_blog($blog_id)
unarchive_blog($blog_id)
activate_blog($blog_id)
deactivate_blog($blog_id)
unspam_blog($blog_id)
make_spam_blog($blog_id)
mature_blog($blog_id)
unmature_blog($blog_id)
manage_users_custom_column($column_name, $value)
Obviously, there’s not a lot to go on, here. But at least it gives you some idea of what actions are available and how to use them. The names are usually quite straight-forward and intuitive.

Do you know of any more? If you do, please share and I’ll update the list.

I’m playing around with WordPress MU, and will need to be doing a lot of hacking the MU code in order to get what I want out of MU.  So, as long as I’m working on projects, I plan to design around general concepts instead of site-specific requirements and post my projects and work here.

My first order of business is to determine how, exactly, I’m going to create the “classes” concept I’ve been toying with.  In terms of the dB, this shouldn’t be too taxing an undertaking.  But I’ve never bothered to create any Administrative plugins for WordPress before (I’ve written a few popular display plugins in the past).  So finding the hooks I need to get this done will be my first challenge.

Oh, yeah.  I think perhaps I’ll start a category exclusively for revelations concerning hooks, generally.  I find that other sources tend to be incomplete, so I hope I can at least add something to the conversation and help the next guy figure out his project.