Plugin Development: WPMU or WP?

0 Views

I was thinking, what kind of issues might I face if I port a plugin from WPMU to WP or vice versa.

Say I developed a plugin from scratch and wanted that plugin to be compatible with both, should I begin with WPMU or WP?

Post Views: 0

Related posts

Leave a Reply

3 comments

  1. You’ll need to test in both setups, because they behave differently in a lot of situations. Some of the most notable differences are:

    1. If you register an activation callback, you need to check if the activation was network-wide. If it was, run the activation logic for all the blogs instead of just the current one.
    2. If the plugin is network-activated, the regular activation callback won’t fire when new blogs are added, so you’ll need to create an additional callback that hooks into the wpmu_new_blog action. It has to switch to the new blog, do the activation logic, and then restore the current blog. The $id of the new blog is passed in to the handler as the first parameter.
    3. If you’re creating a custom post type and want the Set Featured Image meta box to show up, you’ll need to ensure the Media Upload Buttons setting has the Images checkbox enabled. You can use get_site_option( 'mu_media_buttons' ) to check it and update_site_option() to set it.
    4. The path to the uploads directory is different, but you’ll be fine as long as you always use wp_upload_dir() instead of the constants.
    5. Each blog has it’s own copy of most of the database tables, and they’re prefixed with the blog ID. You don’t typically need to do anything special, though as long as you’re using the API to interact with the database — which you should, whenever possible.
    6. The users and usermeta tables are the exception; they’re shared across all blogs.
    7. There have recently been a few WP-Cron bugs[1, 2] that only affected jobs on MultiSite installations.

    You can use switch_to_blog() if you need to temporarily access another blog’s data with API functions, and then restore_current_blog() to switch back.

    You can see a complete example of the activation functions by browsing the source of my plugin skeleton.

  2. There is no difference.

    From http://mu.wordpress.org/

    WordPress MU is no longer a separate project; it is continuing development as part of the main WordPress branch under the name multisite or MS.

    While developing use a multi-site installation, because sometimes file handling and paths are a little bit tricky.

  3. If you’ve never built a plugin before, and you’re planning on releasing one to the WordPress repository, then you’re going to have a hard enough time fixing all of your WP bugs to even worry about WPMU compatibility.

    Go with WP first and learn it inside and out. Then you can start learning about what makes a WPMU plugin different from a WP one.

    A WP plugin is a plugin that is incompatible with WP Multi-sites. There’s actually a lot of things that you need to understand about plugins to even begin to understand the WPMU dev requirements that you’ll face.