Choosing a WordPress Plugin

Here at Stratagem, we’re big fans of WordPress for many reasons.  The developer-friendly ecosystem, the open source community, and especially the ready availability of thousands of plugins.  54,805 as of this writing!  That’s just in the WordPress plugin repository!  There are many more for-pay plugins as well! In this article, I’ll show you what to look for when choosing the right WordPress plugin.

Side note: What’s the difference between plugins in the WordPress repository and those outside of it?  Well, the plugins in the repository are much easier to add from within your WordPress installation. You’ll have to upload plugins that aren’t in the repository yourself, but that’s not hard!

We’re big fans of keeping as much extra functionality in our themes and hand-crafted plugins as possible, but there are a slew of plugins that can do a lot more than we can hope to do for a smaller site.  With well over 55,000 plugins available, how do you go about finding the one you’re looking for?


Yep.  Google is your go-to solution for all web problems.  It typically does a better job than the WordPress search, and it’ll find the ones which don’t live in the WordPress repository as well.  The Contact Form is one of the most commonly requested features on client sites, with good reason. Without a way to convert a website visit into a contact, what’s the point of your site?

Let’s start with a basic search, “Wordpress plugin contact form”  What do we get?

Google search results for contact form

Holy clickbait Batman!  We’ve got some research to do.  The two that are actually WordPress plugin results are Contact Form 7, a long-time fan favorite, and Contact Form Builder, Contact Widget.  That’s a really long and awkward name!  Let’s take a look at these two:


The quickest way to weed out a sub-par plugin is to take a quick glace at the ratings.  Here is Contact Form 7:

And here is Contact Form Builder:

Both of them are 4 1/2 stars.  I typically try to avoid anything below 4 stars, however, if a plugin is providing functionality you can’t find elsewhere, click on the word “1 star” to find out the reasons for the bad reviews.  Sometimes the plugins don’t provide what they claimed, but sometimes the plugin just works differently than expected.  Negative reviews are not always indicative of a bad plugin.

Plugin Information

WordPress plugins in the repository contain a lot of valuable information at the top right side of their page.  Here is Contact Form 7:

I’ve highlighted in pink the main area I’m looking for on this page.  And here is the same info for Contact Form Builder:

Contact Form Builder

And here’s their info together:

Information Contact Form 7 Contact Form Builder
Version: 5.0.1 1.4.4
Last updated: 1 month ago 3 weeks ago
Active installations: 5+ million 10,000+
Requires WordPress Version: 4.8 3.4.0
Tested up to: 4.9.5 4.9.5
Languages See all 46

What does that tell us?

Well, for the version, I’m generally looking for a plugin that’s been around awhile.  5.0.1 definitely sounds better than 1.4.4., but 1.4.4 isn’t disqualifying…anything that’s above 1.0.0 is worth looking at closer.

We want to make sure that the plugin has been updated regularly.  WordPress is the most popular publishing platform on the web, and with great popularity comes great security risks.  We want to make sure that our plugin hasn’t been abandoned, and that it doesn’t look like it will be. They’ve both been updated in the last month, which is great.  You generally want to be more wary when a plugin hasn’t been updated in, for example, a year. There are exceptions…some plugins barely interact with any of the new functionalities that WordPress have introduced, so they haven’t needed to be updated.  Without further information, though, more updated is better.

For the WordPress Version, you’ll want to make sure that your current WordPress version is supported.  (You are keeping your WordPress install up-to-date aren’t you? Definitely, do that!) Both of these are tested up to the most recent version of WordPress (4.9.5 as of this writing).  The fact that Contact Form Builder works with older versions of WordPress tells me that it may not take advantage of some of the newer functionality, but should work fine.

You’ll notice I skipped one row.  Active Installations. Contact Form 7 is an absolute monster here.  Over 5 million installs vs. 10,000 for Contact Form Builder. This is enough to push me into the Contact Form 7 camp for a few reasons.

5 million installs mean that there are a lot of security companies looking at the security of that plugin.
If security issues are found, they will most likely be patched quickly due to pressure from the 5 million strong user-base
If 5 million people are using it, there’s probably a good reason!


Next, make sure to check out the Support for the plugin.  You can get an idea of how responsive the developers are, how many things are going wrong, and a general idea of the community’s opinion of the plugin.

Contact Form 7 has a lot more activity due to the higher user base.  This means that the developers have more work to do, but also they have more help from their user base.  Neither support forum concerns me.

At this point, I’m firmly in the Contact Form 7 camp.  I’m reassured that the large installation base will be helpful, that the plugin is supported, and that the plugin won’t drop off the face of the web.

As I’m in charge of a few hundred WordPress sites, I want to make doubly sure that I’m choosing correctly.  So, let’s google Contact Form 7 Security.  That does take me to a JetPack page called, “Is Contact Form 7 Safe?”  I’m a little concerned that there are insecure versions in the past, but, again, the developers seem to keep everything up to date.  So, at this point, I would choose Contact Form 7.

Twist Ending

You actually made it this far?  Congratulations!

From this article, I hope that you take the general philosophy of choosing a plugin.  The goal here was not to show the best Contact Form plugin, but the process I go through to evaluate plugins.

In a real-world scenario, I would have read several of those “Top X WordPress Contact Form Plugin” pages, and done more searching on my own.  For the free plugins, I would have installed them on a development version of WordPress to see how the plugin interacts with my theme.

After having done that, and because many of my sites require many forms, not just a contact form, I actually use Gravity Forms which wasn’t even on the first page of Google.  It turns out because Gravity Forms does so many other things, it’s overkill for a contact form, but great if you need more customized forms that interact with other technologies.

That being said, if you just need a simple contact form, Contact Form 7 is the way to go!  If you’d like more information, please Contact Us!

What do you mean by WordPress Multisite Migration?

Part of my responsibilities involves creating and maintaining sites within many different WordPress Multisite networks.  Recently, I ended up doing a lot of Googling for WordPress Multisite migration. It’s pretty easy to find a lot of results for going from a multisite network to a single site, but I was having a hard time finding anything which involved migrating from one multisite network to another.


Generally, I’d prefer having thought out my multisite needs enough so that I don’t need to migrate sites. One of my preferences is to keep sites with similar functionality together, but recently I had a client that started selling pizzas.

They weren’t sure which plugin they were interested in using. WP-Pizza and GloriaFood are the two contenders right now, but they’re still exploring options. They had five sites on one of our networks, and we decided it would be cleaner to create a separate network for them to use exclusively. They’d be able to use plugins which we wouldn’t want to have available to other clients, as well as compartmentalizing their sites, making it easier to migrate them in the future.


Google “WordPress Multisite Migration” and you’ll find a lot of options, but most people are migrating a multisite to a single site. I wanted to get the “multisite site to different multisite” migration down so I would be able to do it again in the future.

Step 1 – Export the old site’s database

First thing’s first. You’ll want to use WP-CLI for this. You’ll want to be familiar with your Linux command line to get it installed, and for most of the tasks, we’ll be working on here. I’ll write more on WP-CLI later, as it’s one of the most useful tools to have in your pocket.

wp db query "show tables"

This should return a whole bunch of tables. Here’s a snippet:

| wp_36_term_relationships |
| wp_36_term_taxonomy |
| wp_36_termmeta |
| wp_36_terms |
| wp_38_commentmeta |
| wp_38_comments |
| wp_38_links |
| wp_38_options |
| wp_38_pmxe_exports |
| wp_38_pmxe_google_cats |
| wp_38_pmxe_posts |
| wp_38_pmxe_templates |
| wp_38_postmeta |
| wp_38_posts |
| wp_38_rg_form |
| wp_38_rg_form_meta |
| wp_38_rg_form_view |
| wp_38_rg_incomplete_submissions |
| wp_38_rg_lead |
| wp_38_rg_lead_detail |
| wp_38_rg_lead_detail_long |
| wp_38_rg_lead_meta |
| wp_38_rg_lead_notes |
| wp_38_term_relationships |
| wp_38_term_taxonomy |
| wp_38_termmeta |
| wp_38_terms |
| wp_39_commentmeta |
| wp_39_comments |
| wp_39_links |

If you’ve worked with multisite very often, this will look familiar. If you aren’t as familiar with multisite, it should seem familiar seeing all of your tables starting with wp_ as that’s the WordPress default. In this case, the tables are all named:


This only helps if we know our site ID. WP-CLI to the rescue!

wp site list
| blog_id | url                   | last_updated       | registered          |
| 36 |   | 2018-02-17 17:48:13 | 2018-02-01 15:05:19 |
| 38 | | 2018-03-13 22:05:58 | 2018-02-07 13:49:07 |
| 39 |   | 2018-03-13 22:05:35 | 2018-02-13 15:59:39 |


This is helpful! I found the site I was looking for, 38, So, I know that I want to get all of the wp_38_ tables. Turns out WP-CLI is a great way to do this.

wp db export --tables=$(wp db tables 'wp_38*' --format=csv)

This is telling WP-CLI to do a database export, but not the entire database (which would contain all of the tables for the entire network) but rather just the tables starting with wp_38*. The command within the $() is another WP-CLI command which just provides a comma-delimited list of all of the tables starting with wp_38. This will export all of those tables, and save it in a file with a name like site_79ae8bf.sql. If you look at it, you’ll see that it includes something like this:

-- Table structure for table `wp_38_commentmeta`

DROP TABLE IF EXISTS `wp_38_commentmeta`;
/*!40101 SET @saved_cs_client = @@character_set_client */;
/*!40101 SET character_set_client = utf8 */;
CREATE TABLE `wp_38_commentmeta` (
`meta_id` bigint(20) unsigned NOT NULL AUTO_INCREMENT,
`comment_id` bigint(20) unsigned NOT NULL DEFAULT '0',
`meta_key` varchar(255) COLLATE utf8mb4_unicode_ci DEFAULT NULL,
`meta_value` longtext COLLATE utf8mb4_unicode_ci,
PRIMARY KEY (`meta_id`),
KEY `comment_id` (`comment_id`),
KEY `meta_key` (`meta_key`(191))
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci;
/*!40101 SET character_set_client = @saved_cs_client */;

Step 2 – Create our new site

Great! We have all of our Posts, Pages, Comments and Options from our old site. Time to create our new site:

Add site to multisite

Once we’ve done this, we can either get the Site ID by running our wp site list command again or, since we’re already in WordPress, if you click on All Sites and hover over the site, you can get the ID by looking at the URL:

Get WordPress Site ID

The ID for this site is 2.

So, we need to ensure that everything in the old site, which had an ID of 38, needs to point to the new site, with an ID of 2.

Edit our SQL

Fire up your trusty text editor (my choice is VS Code, but we aren’t doing anything fancy here. Open up the SQL file you exported earlier (site_79ae8bf.sql, or something similarly cryptic) and we need to do a few find/replace.

Find: wp_38_
Replace: wp_2_

This will drop all of the tables the new, clean network site had, and replace them with the tables from the source multisite site.

Find: uploads/sites/38/
Replace: uploads/sites/2/

Now, we need to ensure that all of the media that was used on the old site is linked to the new location. That’s what this search does.

Wait…what media?

Indeed. We’ll lose out on all of the uploaded images, videos and documents from the old site unless we copy them over. If you’re familiar with scp, that’s probably the quickest way to get it all over, but here I’ll show Transmit, my sftp client of choice.

In this case, we’re copying all of the contents from /wp-content/uploads/sites/38 into the new network, under /wp-content/uploads/sites/2. This step preserves all of the links that exist in the database, so all of your posts and pages should have the same content and appearance.

Cleaning up, and a few caveats

Now, we just need to go into the multisite network’s Sites page:

and edit our new site to make sure the URL matches the old site. At this point, the site should be transferred!

There are a few things to note here:

  1. Users and Plugins do not get transferred over. I’ll write later on how to semi-automate that process, but in the meantime, just ensure that every plugin active on your Source site also exists in your Destination Multisite Network. Transferring the database, as shown above, should automatically activate them.
  2. My site only had three users, so I manually recreated them on the Destination Multisite Network before doing the database transfer. This kept Posts and Pages attributed to the correct people. There are better, automated, ways to do this if you have more users. I’ll write about that later.
  3. You’ll need to point your domain to the new server, using Cpanel, Virtualmin, or however your servers are set up.

Was this helpful?  Let us know!  Need some help?  Contact Us and we can help with your multisite needs!