Twelve-Factor WordPress App #6: Processes

Factor #6: Processes

Execute the app as one or more stateless processes

The app is executed in the execution environment as one or more processes.

This factor bleeds into the Run Stage and Concurrency factors a bit, but the most important point is:

Twelve-factor processes are stateless and share-nothing. Any data that needs to persist must be stored in a stateful backing service, typically a database.

There’s two main issues you’ll run into with making sure WordPress is stateless and sharing nothing:

• Sessions
• Uploaded files

Sessions

If you need to go beyond normal Cookies (which are stored in the user’s browser) and into session territory (stored on the server), you can’t use the normal PHP file-based session store. A backing service like MySQL, Redis, or Memcached is required.

Uploaded Files

Again, this gets into Concurrency, but if you’re using multiple web servers for your site, you can’t just use locally uploaded files. You’ll either need an internal storage host like NFS, or an external one such as Amazon S3.

In Practice

To give an example of how you’d solve each of the issues above, we’ll look into some libraries and plugins to use.

Files

There’s a wide variety of plugins and it depends on if you’re using an internal or 3rd party store and what it is. But a few examples are W3 Total Cache (which also does a million other things), or the more specific Amazon S3 and CloudFront. Both of these also have the benefit is letting you use a CDN in front of your static files as well.

Sessions

Once again this depends on the backing service you use, but you could easily use a library like Predis (using Composer of course).