johnc- said in IRC the other day, regarding the use of get_option API for WordPress “our standard practice is to use get_option to enable site specific features, if the feature needs to be unavailable for other sites then it gets broken into a separate plugin for clarity”
So to explain this for those who blinked a little we need some examples, and really this depends what you’re writing.
We got to this point in the conversation while folks were watching my “Don’t Use WordPress Multisite” presentation from WordCamp SF. During the presentation, I mentioned that generally, when I want to write a function for a specific site on Multisite, I wrap it around a ‘If site 1, then …’ and put it in it’s own plugin file in mu-plugins. That leaves me with files like halfelf-functions.php so if I ever split the site out (see? I’m always thinking ahead) I know what file to copy.
But that’s not the only way about it. Another way is to put all the functions in a file, and then wrap the actual filters and actions around a get_option call. Why would I want to do this instead of a separate function file? The question of portability comes up primarily. Exporting site options is not the easiest thing in the world on a Multisite, but there are cases, like my Capital H Dangit! function, where this would make sense. In general, I always want DreamHost to have a capital H, so since 99% of my sites have that on, I could, instead, use an option, since if I ever moved the one site that doesn’t use it, I just won’t bring the function over!
Currently have wrapped that function around an ‘if site 2, then don’t run’ check, which works fine. But if I wanted to move that to options, it would go like this:
// Add the default option of capital h to yes, and autoload
add_option( 'helf_capital_H_dangit', 'yes', '', 'yes');
if ( get_option( 'helf_capital_H_dangit' ) == 'yes' ) {
foreach ( array( 'the_content', 'the_title', 'comment_text' ) as $filter )
add_filter( $filter, 'capital_H_dangit', 11 );
}
function capital_H_dangit( $text ) {
[... code here ...]
}
This is pretty basic. It adds an option called helf_capital_H_dangit, auto-loads, and defaults to on for everyone. That was the easy part. The hard part is determining how to control it.
One option is an interface where I can check a box on, say, General Settings > Writing > Formatting (right under the smilies check box would be perfect), but since I knew this was something I was going to want to control as the super-admin (that is, I don’t want the other people on my network to turn it off), I went in to the back end of my site at /wp-admin/network/site-info.php?id=2 (since this is site #2) and searched for ‘Helf’
I edited it to ‘no’ and saved. Boom. I can use DreamHost and Dreamhost here.
Now this isn’t something I’d do for everything. In fact, my actual halfelf-functions.php file looks like this:
global $blog_id;
if ( $blog_id == 2 ) {
remove_filter( 'the_content', 'capital_P_dangit', 11 );
remove_filter( 'the_content', 'capital_H_dangit', 11 );
// I Make Plugins Filters
}
All the per-site filters are right there turned off as I want them. It’s not a lot of effort that way, and it’s still easy to pick up a site and drop it somewhere else.
Which is better? I don’t know. The real test would be to do some hardcore speed checks and see if checking for the blog ID is faster than checking for an option. I think the speed benefit gains would come from only calling this when needed, but for the limited world in which this is used, it should be fine. Also, keep in mind what both johnc- and I are saying, but in different ways: remember the 80/20 rule.
In my opinion, if you’re making a feature that will be used by 80%+ of the sites on your Network, get_option is probably the easiest bet. If you’re making a feature that’s going to be used by 20%- of the sites, then a separate plugin (with a site_id check) is the way to go. Of course, you could do an option and default it to ‘no’ as well, but that brings up an interesting level of things to remember if you ever move a site.
If you’ve got a more efficient way of doing the same thing, or even just a different way, speak up! More options are always better.
Oh and no, we’re not going to sneakily install this on DreamPress, but if I did, it would also capitalize DreamPress, DreamCompute, and everything else out there. But I won’t.
You see, Multisite is great at some things, but breaking up is crazy hard to do. If you want to just 
When you’ve got a more complex situation, like a heavily customized and themed site, with lots of users and content, then you may have to do this the hard way. As before, make your new stand-alone instance of WordPress. Copy down all the plugins and the theme from your multisite, same as before. Instead of importing the content via an XML file, though, we’re going to import the following database tables as well as all the media images. Remember, no import, no media import, so you must SFTP them all over.
On the other hand, getting back Super Admin access is less straightforward, but by no means is it impossible.
