Looking for some coding tips for creating multisite-aware plugins

I’m starting work on a plugin that needs to be multisite aware. In fact, it needs to be able to (a) communicate between the sites and (b) share network-wide data. I’m looking for some best-practice suggestions about how to make this work nicely inside WordPress. Here’s an example. Let’s say I have a multi-site install with ten sites named A through J. Only four of those sites needs to run my plugin, say B, C, D, and G.

First, I need to have a place to store the information about the sites that have enabled the plugin. Is that something I’d store in the base WordPress table options? And what’s the best way from, let’s say, Site C, to write to the options table in the base table?

In fact, what’s the best way to get and put data between the sites? Do I need to do a switch site, get the data, and switch site back? Or can I simply request data from each site? Obviously, things like getting recent posts is site-specific, but what if I just want my plugin running in Site C to get its sister plugin data from B, D, and G?

And then there’s the question of network enabling. Do I design this plugin to network enable, and do I build an options screen on the network dashboard? Or do I do all this on the first table (the first site) and then build my options there?

Anyway, hints, tips, best practices would all be appreciated.

Thanks!

  • Arnold
    • El Macho WP

    If you haven’t discovered it yet

    http://codex.wordpress.org/Category:WPMU_Functions

    Is the multisite specific function list. It’s best to use the functions provided so that if the backend changes it doesn’t break your code.

    Network wide options and setting are stored in the site_options table. Site specific options are in separate options tables and a number is added to the beginning that corresponds to the site blog_id. Typically wp_2_options.etc. Use the functions instead of doing things like addressing the tables by name because in particular the 1 blog doesn’t have a number because it would be the standard WP table and is handled differently. A number of plugins mitakenly try to use wp_1_options directly and it ain’t there. Use get_option() for site specific and get_site_option() fornetwork wide.

    When a plugin is registered Network activation goes in sitemeta, Site activation goes in options for the individual site.

    Most of the tables are duplicated and numbered for each site. Posts, options, links, comments etc. An exception is the user and usermeta table. There is only one and it is network wide. Users can be assigned different roles in different sites and if not assigned a role for a site won’t appear in a site’s user list.

    Those are the basic gotchas. The rest is attention to detail.

  • David
    • The Crimson Coder

    Awesome. So the only thing that I still need to know (and you gave me a few tips that just rock!) is there any time I’d build a plugin that would have a UI form in the Network area, rather than in each site?

    Why would anyone network activate vs. site-activate, or is it just to be able to decide when and when not to load code (or for customers who get goodies and those who don’t)?

  • Arnold
    • El Macho WP

    Sure, A Network level menu get added by add_menu.

    http://codex.wordpress.org/Function_Reference/add_menu

    Just check the is_network_admin() before adding so you know whether you’re in Network or site mode.

    Network activation would be if you want to give ALL sites the same functionality, Or if there was something it needed to do like manage communications.For example for IPN call returned from PayPal you want the piece that handles it to always be loaded even if it only applies to one site. so it can “pick up the phone”

Thank NAME, for their help.

Let NAME know exactly why they deserved these points.

Gift a custom amount of points.