Lifecycle hooks and custom (must-use) plugins enable you to programmatically trigger actions in your tenants after you’ve made changes in your versions, which would normally have to be performed manually in the database.
The goal here is simple: use as much code as you can to keep your life simple. that being said, that doesn’t mean that YOU have to write this code. That’s why we’re here to help.
Intro: access the power of scalable SaaS solutions with WordPress #
One of the main advantages to leveraging multi-tenant WordPress is that you can introduce proven SaaS methods for scaling web applications to your WordPress development. The WPCS platform is useful for any developer who wants to streamline a development workflow for scaling many websites, but one of WPCS’ core audiences is the WordPress Multisite community. Especially those that build SaaS and WaaS (website as a service) offerings.
WaaS and WordPress-based SaaS builders have often used WordPress Multisite as it enables you to manage multiple subsites from a single WordPress dashboard. However, the downsides of Multisite are frustrating and unsolvable on a WordPress level. The problem with this is that not all information is available to everyone: if you don’t know about multitenancy, then Multisite indeed seems the only way to manage SaaS-like websites at scale.
Multi-tenant WordPress is the innovation that solves the limitations of Multisite and WPCS is the first to introduce the dominant cloud infrastructure of SaaS to the world’s largest open-source ecosystem, WordPress.
Here’s how WPCS’ multi-tenant Versioning System works:
The WPCS Versioning System and database changes #
WPCS’ WordPress multi-tenant cloud platform enables users to provision highly-available tenants (websites) with shared functionality but separate content to develop and distribute changes like a SaaS. With the WPCS WordPress multi-tenant cloud platform, the shared functionality of the WP installations is stored in the Version and only pertains to the themes, plugins, and language files.
The thing that makes WPCS so powerful and scalable is that changes between versions always maintain the integrity of the database. As a rule, you don’t want to mess around with the database after your customer. After all, we can’t know what customers do with the website. For example, it could very well be that they create pages or posts that create conflicts if you add one also.
“With the WPCS WordPress multi-tenant cloud platform, the shared functionality of the WP installations is stored in the Version and only pertains to the themes, plugins, and language files.”
Better yet, you want to give your customers a safe space where they can make changes and customizations that aren’t at risk of breaking the uniformity of your stack when you do an update or introduce a new feature. In turn, you need to create a process where the changes that you make don’t affect your customers’ customizations.
Just like any SaaS, the database should be their domain and stay intact. That means that if you want to make changes to themes, pages, post types, etc. – do it with code. If you’re unfamiliar with writing code, so was I. Fortunately, I have amazing co-founders that showed me that it’s really not as hard or daunting as it may sound.
Don’t forget: you’ve got a high incentive. Doing it this way guarantees scalability from 1 to 1000s of tenants.
How to deploy changes that normally affect the database #
You can create a custom plugin, which could be a must-use plugin (more on that later), to insert PHP snippets to activate plugins, insert license keys automatically, and much more. In any case, you want to write code that you can store in the WP-content. This code now becomes part of your versions, as opposed to becoming part of your tenant database, and can be easily changed or swapped out as you make iterations.
As a side note #
In WPCS, new tenants are always based on a snapshot that includes the entire WordPress installation, including the database. The integrity of the database is only maintained for existing tenants. This means that all plugins that are activated and configured in the snapshot are the same for the newly created tenant.
Cool trick #
If you create pages, etc. before you launch your product, but hide them from the users, you can later trigger them with the API when they upgrade their plan (explained in the course). This method also works if you introduce features at a later stage, not only upon creation of a tenant. Just make sure you hide them in the version before you deploy a snapshot.
However, we assume that you want to continuously develop your product and might, for example, introduce a custom post type feature or want to add a new plugin in the future, which is why we recommend to do this with code.
This is the way that SaaS companies maintain scalability while leveraging multi-tenant infrastructure. These are the proven methods that we’re introducing to WordPress.
How to activate code that you inserted in the Version on the Tenant level #
Lifecycle Hooks, a truly magnificent feature as it gives you much more control over your product at scale.
What are lifecycle hooks? #
It can be very beneficial to run some PHP in your tenants when certain important events happen. It could be important to add some user meta to the newly created user or update some posts when the tenant has been created.
To enable this, WPCS supports several WordPress hooks that are called during important lifecycle events. We’ll go over a few of the ways that you can use them.
Cool examples of lifecycle hooks #
- One of the ways to use it is to activate plugins by inserting a license key in the form of a PHP snippet. When creating your product, you’ll quickly find that you might not want your customers to perform certain actions in WordPress. You might have some plugins that need to remain activated, or should not be activated without the customer paying for the additional functionality. In order to limit your customer’s rights, you can use WordPress’ role system.
A great plugin to manage the role system is Admin Menu Editor Pro. It is, however, a paid plugin, meaning you’ll have to activate its license on every new domain you want to use it on. The plugin does allow you to license itself via the Admin panel in WordPress, but this is not a feasible endeavour if you’re using WPCS to automate your customers’ websites.
So, let’s automate the licensing of the Admin Menu Editor plugin using lifecycle hooks. Have a look at the example we created for Admin Menu Editor.
This lifecycle hook not only enables a form of automation, it also gives you much more control: say for example that your plugin at some point changes the license protocols, you can easily change that code in the custom plugin that you’ve used and deploy a new snapshot for the entire stack. Consider using a must-use plugin so that these plugins are automatically activated.
- Another use is to create Mailgun domains for your tenants. Most websites, at some point, will need to send E-mails. If your WPCS Product allows your customers to send E-mails to their customers, chances are that they will want to use their own domains for those E-mails. In this recipe, we’ll show you how to implement this feature and how to automate keeping Mailgun up-to-date.
- One way of achieving this could be by sending them an E-mail from your own CRM. Another way, however, is to simply display the data in the tenant’s Dashboard! To create a Dashboard widget, we’ll use the Code Snippets plugin. Here’s a recipe that features a quick and dirty way of getting WPCS DNS data to your customers.
- Another thing is to update the WP admin E-mail without confirmation. This recipe uses a WP hook, not necessarily a LifeCycle hook, but it’s very helpful nonetheless. One of the general WordPress settings is the “Admin E-mail”. It is the E-mail that is used for things like error reporting and verifications.
To change it, the previous E-mail will have to manually agree with the change. This is unfeasible if you are creating multiple tenants a day for external clients. This recipe explains how to automate that process by inserting a PHP snippet.
When and why do you need a must-use plugin? #
By default, WPCS does not activate new plugins when you push them to existing tenants using a snapshot. That’s why, as a rule of thumb, we always recommend that you insert your own plugin from the beginning to facilitate migrations.
If you haven’t, must-use plugins are a way to do this when you’ve missed your opportunity to insert your own plugin from the start. Let’s recap why this is important.
Quick recap: #
The WPCS Versioning System enables you to manage any number of WP installations while just managing a version. This is done by creating an update in your (new) version and deploying a snapshot. The functionial changes that you have made to the version will automatically be pushed to all the tenants inside that version.
However, we fully understand that it might be convenient to programmatically activate new plugins after you’ve installed them on all of your tenants. After all, nobody wants to manually access hundreds of tenants and activate (and possibly also configure) each new plugin you install.
“Must-use plugins (a.k.a. mu-plugins) are plugins installed in a special directory inside the content folder and which are automatically enabled on all sites in the installation.”
A must-use plugin (‘mu-plugin’) is just like any other WordPress plugin, except for the fact that when uploaded into the mu-plugins directory of the wp-content folder (i.e. /wp-content/mu-plugins it is automatically activated and remains enabled on your WordPress installation.
First, you will need to create an mu-plugins directory within the WordPress content directory, as you’ll most likely not have one yet. The mu-plugins directory will sit alongside your normal plugins directory, normally at wp-content/mu-plugins unless you’ve moved or renamed the WordPress content directory.
Files in the mu-plugins directory load alphabetically. If you need to manually control the load order, you can simply rename the files.
Must-use plugins are loaded before normal plugins and do not show in the default list of plugins on the Plugins page of wp-admin. They do, however, appear in a special Must-Use section in the Plugin screen’s list menu.
How to activate a new plugin on an existing tenant #
On your version, insert a PHP snippet into the mu-plugins directory of the wp-content folder (i.e. /wp-content/mu-plugins to instruct your WP installation to activate the plugin that you’ve just added. This is what you could use (this example specifically uses Akismet):
Cool trick: #
If you want to load a normal plugin as a must use plugin, just drop the plugin folder into the mu-plugins directory and then create a plugin-loader.php file (any name will do) that does a require for the main plugin file.
In conclusion #
Lifecycle hooks and custom (must-use) plugins enable you to programmatically trigger actions in your tenants after you’ve made changes in your versions, which would normally have to be performed manually in the database. The goal here is simple: use as much code as you can to keep your life simple. that being said, that doesn’t mean that YOU have to write this code. That’s why we’re here to help.
The idea is that you can track the history of code, and thus, you can see what has been done, why, and by who. When you’re developing your product, adding functionality, maybe even changing the database in certain ways, you need to know what you did.
When you write code to do these migrations, you always know what you did (if you use something like Git), but it is also immediately scalable. You’re basically automating the stuff you would do by hand, or, even worse, applying it to all your websites without knowing the consequences.
Make it scalable #
The basic principle of WPCS is to make sure you can scale thousands of websites while managing only one. That’s why we built a platform that natively scales WordPress applications to multi-tenant cloud architecture, orchestrated by Kubernetes on AWS. Our slogan: Easily turn WordPress into SaaS.
We believe that the next frontier of WordPress development is to push into the SaaS and WaaS space.
Website as a Service (WaaS) and WP-based SaaS are business models and development styles that mimic the success of SaaS and implement that in web development. The reason for that is simple: SaaS companies are generally highly scalable, lend themselves for focus and automation, and are very valuable.
We always like to say: if you want to scale like a SaaS, you have to build like a SaaS.