7

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?

1
  • 1
    if the answers have helped you, then you should accept one of them. It doesn't look like you've accepted answers for any of the questions you've asked, but it's an integral part of the process on this site and something you should be doing. If none of the answers have helped you, you can post comments asking for more specific info.
    – Ian Dunn
    Jul 9, 2011 at 16:51

3 Answers 3

8

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
  • No opinion on current activation mechanics, but 2,3,4 should make absolutely no difference if proper APIs are used. Otherwise it's problem of doing it wrong, not problem of differences between MS and non-MS.
    – Rarst
    Jul 2, 2011 at 9:47
  • Well, yeah, I mentioned that twice ;) But people don't always use the API, even if they should, so it still needs to be said. Also, it can make a difference in edges cases, like if you need to create your own database table or use a custom upload folder for certain files and the default upload folder for others. There are still some scenarios where using the API is like trying to fit a round peg in a square hole, albeit few-and-far-between.
    – Ian Dunn
    Jul 2, 2011 at 18:45
4

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.

1
  • 1
    -1 because, while technically correct, the answer is misleading. Just because they're part of the same codebase doesn't mean they have identical paths of execution; they don't. Also, testing on only WPMS is insufficient because there will be bugs that only show up in standard WP that don't show up in MS. If this were at 0 I wouldn't have downvoted it, but I think sitting at +4 gives the indication that it is a correct answer, and I don't think that it is.
    – Ian Dunn
    Jul 9, 2011 at 17:36
-1

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.

3
  • Is there even such thing as "WPMU plugin" nowadays? It's same WP, the only difference would multisite-specific functionality and it doesn't seem like question is about such. Any (properly coded) plugin should work in multisite just fine - A WP plugin is a plugin that is incompatible with WP Multi-sites statement makes no sense to me.
    – Rarst
    Jul 2, 2011 at 9:43
  • I'm sorry that, that statement makes no sense to you. Being that I develop hundreds of plugins a year, I tend to think I know what I'm talking about. You can easily develop a plugin that will crash a WPMU install and work just fine on a WP install. Yes these two systems are now merged, but the function completely different. You don't just have to lack WPMU specific functionality. italic Any (properly coded) plugin should work in multisite just fine italic Even you say it SHOULD WORK because you have no idea. Jul 2, 2011 at 17:47
  • 1
    I agree with Jonathon, and I'm speaking from personal experience as well. Making a plugin work with WPMS takes extra effort to fix specific issues in the WPMS environment. Depending on your plugin, that might just mean handling network-wide activation, but it could also include other tasks, like enabling media buttons that are turned off by default in WPMS (and on by default in WP). Also, there are edge cases where bugs only show up in WPMS, etc. @Rarst, I'd challenge you to download 10 random newly-released plugins from the repo, network-activate them, and check how many function perfectly.
    – Ian Dunn
    Jul 2, 2011 at 18:58

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.