Updating Your WordPress Based SaaS (WaaS)

Last month, we wrote an article on the differences in updating the files for the three common architectures used to deploy WordPress based SaaS’s.

Understanding what you need to do to update your WaaS is an important consideration when deciding what deployment architecture you will use to deploy it.

In this article we’ll flesh out our thoughts and cover all the different types of updates that needs to be done in order to maintain a WordPress based SaaS.

Update Types and Options

Below are the different architectures along with the update options for each type of update you’ll need to conduct for your WP SaaS.

Generally, there are three types of updates that you need to handle:

• Files: eg: updated plugins and themes or new plugins and themes.
• Database: If you add new plugins or themes, you might need to use something other than the default settings. Or remove onboarding screens. Or make similar tweaks. All of these items ultimately end up as settings in the database. Even updates to existing plugins and themes might introduce new screens, options etc. that might need to be changed.
• Configuration Files: Primarily updates to wp-config.php.

Let’s explore how each of these three items can be handled for each type of deployment.

---

Multisite

Updating Files

Adding or updating plugin and theme files in a Multisite based WaaS is simple – just upload the new or updated files or run the WP update process. All subsites in the network will automatically be served the updated files.

Database Updates

There are a number of reasons you might need to update the database. These reasons apply to all deployment types (so we will not repeat them later as we cover other architectures below:)

• Existing plugins and themes have added screens or options that need to be changed, removed or hidden.
• You have added new functionality – either via commercial plugins / themes or custom plugin / themes and all sub-sites need to be updated to have default or custom values.

For these types of updates you only have two choices in a Multisite deployment:

• Write a custom database updater or
• Manually log into each subsite and make the changes.

Manual updates tend to be prone to user error so you will likely need to use a custom updater once you have more than, say, 25 subsites.

Unless you are a developer, custom database updaters are likely too expensive, especially if you’re trying to update options for a commercial plugin or theme. For commercial plugins/themes, you have to spend the time to reverse engineer their code to figure out what database records and fields to change to get the results you want.

Configuration Files

You might have plugins or themes or custom code that require values in wp-config.php or other configuration files. For wp-config.php, you only have to make the entry once so no need for a custom updater.

If you have other config files – e.g: a file for each subsite, then you will either have to update each manually or write a custom updater.

Luckily, custom updaters for these types of files are usually a lot easier to write than database updaters.

---

Standard (Individual) Sites

Updating Files

To update files on all your standard sites in your WordPress SaaS you have the three options mentioned earlier:

• MainWP (or similar): All sites are registered to this tool and you can update all or a subset of them from inside the dashboard. You can even add new plugins (especially your custom plugin) to all sites. And, if MainWP (or similar) offer special support for a plugin you might be able to push configuration changes to the sites as well. The only drawback here is that the platform(s) sometimes do not detect all updates and it’s quite common for different sites to show different sets of updates for plugins even if they’re all running the same plugins.
• Custom Updater: For larger SaaS deployments this is our recommended approach. A custom updater can push files from a central server or force sites to download files from a git repo.
• Manual Updates: Of course, there is always the option to log into each site individually and apply updates, add new plugins/themes etc.

Database Updates

If you’re just updating themes and plugins you might not need to update the database. Most themes and plugins will update the database themselves when they detect that they’re running a new version on a site.

In the instances where you need to execute database updates:

• MainWP (or similar): As mentioned in the Updating Files section earlier, if MainWP (or similar platform) offer special support for a plugin you might be able to push configuration changes and update the database that way. Otherwise you’ll have to use one of the other methods below.
• Custom Updater: If you have a lot of sites, this is likely the approach you’ll need to take. You’ll probably write this as part of the custom plugin in your template site. When you update the site files, the new custom plugin version will run and apply the database updates.
• Manual Updates: This is always an option but, as with anything manual, you can expect it to be tedious and error prone. But, it’s a good way to get started when the number of sites you’re managing is small.

Configuration Files

• MainWP (or similar): Most management platforms don’t allow direct mass updates of wp-config.php and none allow for updates of custom config files. So using this is not an option when you need to apply configuration changes in files.
• Custom Updater: If you have a lot of sites, this is likely the approach you’ll need to take.
• Manual Updates: This is always an option but, as with anything manual, you can expect it to be tedious and error prone. But, it’s a good way to get started when the number of sites you’re managing is small.

One thing you can consider is writing custom modules for your MainWP (or similar) platform. That module can push out changes and run custom code as needed. The MainWP (or similar platform) child plugin might not support all operations though, so that’s something that needs to be researched to see if it presents obstacles to what you need to do.

---

Multi-tenant

Updating Files

To update files on all your tenant sites in your Multi-tenant WordPress SaaS you only have two options. Of those two options, only one is recommended. MAINWP (or similar) cannot update your read-only tenant files.

To update files, you will need to create a new version of your template with the updated files and push them out using the standard rollout process provided by your WP Multi-tenant vendor.

• Manual Updates: In the case of WPCD, you can also update the tenant files on each server manually. BUT we do NOT recommend this!

Database Updates

As with individual sites, if you’re just updating themes and plugins you might not need to update the database. Most themes and plugins will update the database themselves when they detect that they’re running a new version on a site.

In the instances where you need to execute database updates you only have two options:

• Custom Updater: If you have a lot of sites, this is likely the approach you’ll need to take. As with the individual sites approach, you’ll probably write this as part of the custom plugin in your template site. When you update the site files, the new custom plugin version will run and apply the database updates.
• Manual Updates: This is always an option but, again, as with anything manual, you can expect it to be tedious and error prone. It’s a good way to get started when the number of sites you’re managing is small but it simply does not scale.

Configuration Files

With a Multi-tenant configuration you only have two options here. MainWP (and similar) is not really useful in this environment.

• Custom Updater: If you have a lot of sites, this is likely the approach you’ll need to take.
• Manual Updates: This is always an option but, as with anything manual, you can expect it to be tedious and error prone. But, it’s a good way to get started when the number of sites you’re managing is small.

---

Wrap Up

When planning your WordPress based SaaS, you need to consider how you will update existing customer sites. That will factor into which architecture option you choose for deployment.

Most articles and discussions of WaaS’s don’t think past the initial site deployment. That is a critical mistake and one that will come back to bite you in the rear-end.

So, chew on the above carefully before you choose your deployment strategy!