WordPress Multisite, introduced in version 3.0.0, gives site owners the ability to easily create and manage several WordPress blogs with a single installation of WordPress. The most famous use of WordPress Multisite is the popular blogging website WordPress.com. There are so many potential uses of such a setup, including departmental websites within a corporation, project management within a group, or a site owner that wants to host several blogs at once while keeping them easy to maintain and expand. However, unless your plugin was specifically built to work with the Multisite feature, your plugin is missing out on potential users. You never know, your plugin could be very helpful to site owners using WordPress Multisite.
What you will need to do is not incredibly simple, but not overly complicated. You will need basic PHP skills and an understanding of how to work with the core functions of WordPress. The most important changes to be made will be finding which functions and hooks will need to be changed, and modifying your plugin’s code to use the correct function or hook in case your plugin is being used in a Multisite environment. Two different types of network-wide functions and hooks include some that are specific to plugins, and others that can be used by all extensions in a similar, communal fashion. Both are likely to be used by plugins, so both will be covered.
Specific for Plugins
There are some functions and hooks that are used in a Multisite environment that are meant to replace the standard functions normally used by plugins. Just swapping the normal functions and hooks for the Multisite equivalents will not work, since your plugin would be useless for everyone not using WordPress Multisite. What needs to be done is your plugin should detect the environment, and apply the correct function or hook based on if Multisite is active or not. The main difference for plugin-specific functions are the functions that are used for activation, deactivation, and uninstallation.
Activation, Deactivation, and Uninstallation
You would normally use register_activation_hook(), register_deactivation_hook(), and register_uninstall_hook() for working with a change in a plugin’s state. These are the same functions that you would encounter within a Multisite environment, but what your functions should accomplish differs.
Normally, your activation function may just add options, register some options pages, and prepare itself to work with WordPress. However, due to the way that WordPress Multisite is set up, you will need your activation function to apply itself to every site operated within the Multisite environment if activate on the entire network. To accomplish this, your plugin will need two separate activation functions. One, which will be called by register_activation_hook(), will determine the environment and run the appropriate function. The other will be your old activation function, and will do what it did before. The first activation function will need to use an “if” clause with is_multisite() and $network_wide.
Your plugin’s activation routine should resemble something like the example below. For the sake of this tutorial, assume that this plugin’s namespace is “wphub.”
The code in the previous example determines if it is running inside a WordPress Multisite environment. If so, the code gets all of the current blogs and activates the plugin on each one before returning to the current blog for further processing. If not within a Multisite environment, the code assumes that this is a single installation, and activates the plugin normally. Similar code may be used upon deactivation and uninstallation.
There are some functions and hooks that are specific to plugins in a Multisite environment, but there are plenty more to be used by all. They are not relevant to just plugins, meaning that they are considered communal to all software being run within a network.
For working with individual WordPress installations, your plugin would use functions similar to get_option() and get_transient() for retrieving stored information. Those functions would still work in a Multisite environment, but only for individual blogs. If you want to store and retrieve information on a global (network-wide) scale, then you need to use functions similar to get_site_option() and set_site_transient(). Their name may be slightly confusing, since one might assume that the word “site” means that they apply to individual sites, but WordPress has decided to call the entire network a “site” and individual members of the network “blogs.”
Site-wide options may be useful for storing information about the network at certain intervals, such as the blogs IDs that your plugin is currently installed on. With that information, you can check to see if any new blogs have been created, and install your plugin on them. The example below demonstrates how this can be accomplished.
Site transients can be useful for information relevant to the network, but can be deleted after some time. Some examples of some useful site transients include the last time a Super Admin modified one of your plugin’s settings, when a blog was last added, and the last time a Super Admin logged in to any networked blog. These pieces of information could have an expiration date, so a transient can be used to detect if enough time has passed between user interaction. This enables your plugin to prompt Super Admins on regular intervals that their attention is needed.
Administration Menu Actions
Only one new hook relevant to the administration manu has been added in a Multisite environment, and it only applies to pages for viewing by Super Admins. When making an options page for only Super Admins, you can use the same functions as you would for any other site or blog. All you need to do is hook into the network_admin_menu action. For example, you may need to collect some information from a Super Admin about how your plugin should interact with the network. The following code demonstrates the beginning of how to create an options page for only Super Admins.
Three new functions in a WordPress Multisite environment help you to determine the location of certain folders. They are closely related to their non-network counterparts, and work in a similar fashion. They are network_admin_url(), network_home_url(), and network_site_url(). These are needed because WordPress Multisite uses a single installation of WordPress to operate. All plugins reside in one location, and each must know to use the site’s address instead of an individual blog’s address when linking to certain content. The following example demonstrates how to use the new functions. While it is true that you could always use the network functions and let them fallback to their non-network counterparts in case of a single site, the example below guarantees that your code will work if that fallback is removed.
When writing or modifying a plugin to be compatible with WordPress Multisite, there are several functions and hooks that differ from a single site being run by WordPress. There are a few differences for just plugins, but plenty of new common functions can be used by all software running within a Multisite environment. As a developer, you need your plugin to realize when it is confronted with multiple sites, adapt itself to use different methods for this, and still have all of the features it would normally posses. Now that your plugin is ready to work with WordPress Multisite, you can now place “Network: true” into your plugin’s metadata (where the name, description, and version number reside in the main plugin file).
– Link: Create a Network in the WordPress Codex