We rebranded to wildcloud; formerly known as WPCS. 

Safely update WordPress database settings (e.g. plugins) for all your sites

Settings for plugins are part of the database #

“I use Advanced Menu Editor Pro to control what and where my customers see certain menu items on the back-end. Say I have 300 customers, and I add a new plugin to one of my plans, I realize I can push that plugin out to all 300 customers, but if I wanted to limit that plugin’s menu visibility via the menu editor plugin, would I have to do that on all 300 sites one at a time? I think I would because those settings would be considered part of their DB, yes?”

WPCS user

A quick refresher on multi-tenant WordPress sites with shared functionality but separate database #

WPCS hosts cloud-based, highly available websites with separated databases and shared functionality (code), making it possible to manage and develop these websites as one cohesive product. Using the WPCS Versioning System you can create low-code WordPress solutions like Website as a Service or fully-fledged WordPress-based SaaS.

How the Versioning System works #

Versions contain the functionality of the product you’re creating. It is the main space for all future development of your theme, plugins, and language files. For example, whenever a new update of a plugin is available, or you want to install a new plugin, it is done via the version. 

When you’re working on your version and you’re ready to offer updates or new features to customers, you create a Snapshot. This process is the same for launching new tenants and when you want to update and maintain your customers’ existing websites. No changes will be sent to any customer or tenant without the deployment of a Snapshot.

There’s a difference though regarding the type of information that is sent over when you make a snapshot.

  1. When a new tenant is launched, it will receive everything in the Snapshot: all code, plugins, themes, and the database. It’s a complete clone of the product you have built.
  2. When you update existing tenants with a snapshot, you only send over the code (plugins, themes, and language files). The database of existing tenants always remains intact. This is to make sure you can scale your business and not accidentally overwrite any of your customer’s websites:

How to centrally manipulate the database for all tenants #

The settings for Admin Menu Editor Pro are database-level settings, so they will not be automatically updated when settings are changed in a deployed snapshot. You could do this one by one, but that would be a lot of work.

At the moment we do not have an out-of-the-box solution to distribute database changes to multiple tenants. However, you can use Tenant Lifecycle triggers in a custom plugin to enforce certain database settings.

What you could do is run a WordPress site locally based on one of your tenants of versions (using our CLI connecting to something like LocalWP), and set it up the way you like it. Then, you can read out the settings as you have them, either in the database directly or through so get_option. With those values, you can in a custom plugin, register an action on the tenant moved lifecycle hook that uses set_option. If you add that plugin to your current version and enable it for all tenants, you can create a new version and move over tenants to that new version. This will trigger the lifecycle hook and patch the options.

Something you can do to make this operation safer is to have your plugin copy the current values of the option in a “backup option”. You could add a check in your custom plugin that lives in your “old” version to restore that option value when a “tenant moved” event happened on the old version. This way you could go back and forth between the two versions minimizing the impact if the changes would break anything.

It is a bit of a roundabout way, but, options, due to a lack of defaults, guidelines, and standards, are so diverse that a general solution does not exist for this problem. Having a custom plugin in which you can manipulate this kind of thing through the lifecycle hooks is quite useful. Using the WPCS versioning system and having updates for the custom plugin in new versions also allows you to test with a few tenants before updating all tenants.

Another way to do this is by using our API. The API allows you to update a tenant’s WP Options and PHP Constants. You could create a small script that sets the option to the right value. Although this seems like less work, we advise against in-place updating of tenants. Yes, it can work, but it does not allow you to reverse the operation.