Activate WordPress Plugins on Site Creation Using Multisite

Have you ever ran a WordPress multisite environment where you have users signing up for accounts and creating sites at the same time? Have you ever wanted to have different types of site level such as Bronze, Silver and Gold with different plugins activated for different levels? Recently I had a similar problem on a project I was working on and therefore set about to find a solution. Below is how I solved the problem of activating specific plugins when a new site is created in a WordPress multisite install.

The project involved users signing up for a site and user account and depending on the level of account or site they choose would depend on the functionality they would have access to. The functionality was provided as different plugins that would be activated for different site levels.

The signup process was handled by the Gravity Forms User Registration add-on, which thankfully also allows you to choose to create a site for the user at the same time. I won’t go into how this works in this tutorial, however there is plenty online and on the Gravity Forms Support site on how to get this setup. For this example we have a form on the front end of the site that allows the someone to sign up for a user account and a site.

One of the important points to this process is that the user must choose their site level. It is important however that this meta data is stored with the site, rather than the user as the sites will inevitably have more than one user. Initially this posed a problem as the signup form provided by the Gravity Forms User Registration Addon only allows data to be stored as User Meta and not in the sites options table. We will get around this later but your form must save the level of site as user meta. In this example our meta key for the site level will be mdw_site_level and the value would be the level of the site, in this case bronze, or silver.

The next stage was to create a function that takes that data processing it and activating the plugins necessary according to the level of site chosen. To do this we need an action hook to hook our function to, that runs right after the site is created. Also this action hook needs to pass the Blog ID of the created site and the User ID of the created user, to our function, so that we can make use of them.

After some digging around there are two hooks which can be used in order to do this. The first is the Gravity Form User Registration add-on hook named gform_site_created. This takes (among others) the site ID of the created site as the user ID of the created user.

The other hook that we could make use of is the WordPress core hook named wpmu_new_blog. This runs after a new site is created in multisite installs and passes a number of arguments but like the hook above it allows us to access to newly created blog ID and the newly created user ID.

So which to use? Well even though I was using the Gravity Forms solution to register the user and create the site, I choose the wpmu_new_blog simply because if I changed later on and used a custom form, the function would still run.

The next issue to resolve was how to activate a plugin programatically without the need to click activate on the plugins list in the WordPress dashboard. After some quick research this is actually very easy to solve. Active plugins are stored in the WordPress options table as an array with the option named active_plugins. Therefore if the plugins path (from within the plugins folder) is contained in that array it is active. Therefore all we need to do is manipulate that array in our plugin, adding the plugins we want to the array and they will be active.

The plugin created is below. See further down for a full explanation of what the plugin does.

Lets run through how our function, hooked to wpmu_new_blog, is going to work as Pseudo code written in plain English.

  1. Get the site type (in this case bronze or silver) from the user meta which was added when the site was created.
  2. Switch the database context to the newly created blog. If we did not do this then we would end up adding the meta data to the main site.
  3. Add an option to the WordPress options table for the newly created blog which is the actual value of the site level brought from user meta (step 1).
  4. Get an array of active plugins in the option active_plugins
  5. Create an empty array which we can put our a list of the plugins we want to activate depending on the site type
  6. Depending on the site type add an array of plugins to add to the empty array we setup in step 5 above
  7. Loop through each of the plugins that we want to activate adding them to the active plugins array we retrieved in step 4
  8. Update the options for active plugins to include our list of additional plugins to active for this site level
  9. Restore the database context back to the blog or site we started on.

So, there you have it a network activated plugin that allows you to control which plugins get activated when a WordPress site is created within a multisite network.

Introducing WP Broadbean

The WP Broadbean plugin has now been released on…

A while ago I wrote about integrating Broadbean with WordPress. This has proved to be a very popular post on this blog and has resulted in a number of enquiries with several people requesting assistance in this very task. With this in mind I have decided to package this work into a plugin named WP Broadbean.

For those not aware, Broadbean Technology runs a service known as Broadbean Adcourier multi-job posting. This enables jobs to be added to the Adcourier service and then broadcast to a number of popular job boards. On top of this, the broadcast and can setup to integrate with your own site. This means that users have to enter a job posting once and it is automatically published on a number of sites including your own.

A couple of years ago, working with Pixel Junction, we had a client who needed to integrate this with a WordPress site we had built for them. The solution I outlined in the original post was the method I took, however having had a number of further projects that needed the same, I decided it would be best to package this up into a plugin. Therefore let me introduce you to WP Broadbean.

The plugin is currently in the alpha stage, although I have integrated a version of it on a few sites. Before releasing it to the public (under the GPL license) I need to make some changes to make it much easier to use “out-of-the-box”. Below is a quick summary of what the plugin will do:

  • A Jobs custom post type
  • Custom taxonomies for job type, job location, job location tags and job categories
  • Custom post type for applications
  • A shortcode for embedding an application form onto your website, which integrates with the jobs custom post type, to allow people to apply for the listed jobs
  • Integrate with your current WordPress theme without creating template files, however you can override these in your theme

If you run a WordPress website that deals with recruitment and you use, or are thinking of using the Broadbean service, please take a look and get involved. I will need beta testers in then next few months! Meanwhile check out the new WP Broadbean holding page and keep an eye on progress on WP Broadbean Github repository.

WordPress Multisite Locally Using MAMP

Recently I have been working on a large WordPress multisite project. After working for a while it was clear that we needed a more robust development environment to work with, including local, staging and production. I use MAMP for local development and therefore I needed to get MAMP working with WordPress multisite and sub domains. Here is how I went about this.

For this I am assuming that you have MAMP installed and that you are comfortable using MAMP. The first thing to do is to make sure that MAMP is using the default Apache and MySQL ports (80 and 3306 respectively). To do this click on Preferences from the MAMP window and click the button titled “Set to default Apache and MySQL ports“.

The next thing to do is to edit your Macs hosts file. To do this enter the following into the Terminal:

sudo pico /etc/hosts

When prompted enter your password and you will then see the hosts file with a list of hosts defined. Use the arrow keys to move to the bottom of the list and then enter the domain you want to use locally for this Multisite install. For this example we are going to use As this is going to be a sub domain install you will need to add any sub domains in here too that your sites in the multisite are going to use. Here we will just add some examples. The following provides an example of what to add:

If you add additional sites to your multisite install in the future you will need to add these subdomains to the hosts file before setting up the site in WordPress. The next task is to edit the apache config files to create a virtual host. The file to edit (just use textedit) is located in the following location:


In this file find the following:

# Virtual hosts
# Include /Applications/MAMP/conf/apache/extra/httpd-vhosts.conf

Remove the hash in front of the “include” line to include the virtual hosts extra. The next step is to edit this file with can be found here:


At the bottom of this file add the following, obviously replacing the domain name to the one you want to use.

<VirtualHost *:80>
    DocumentRoot "/Applications/MAMP/htdocs/"
    ServerAlias *

The above uses the default MAMP document root although you could place you files elsewhere should you wish too. You could also create a folder in the htdocs file and then use that.

Restart MAMP by clicking “Stop Server” and then “Start Servers” in order to activate the virtual host changes.

Now all you need to do is install WordPress and activate WordPress multisite and you are ready to go with running a WordPress multisite install locally.