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:
- Uploaded files
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.
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.
To give an example of how you’d solve each of the issues above, we’ll look into some libraries and plugins to use.
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.
Once again this depends on the backing service you use, but you could easily use a library like Predis (using Composer of course).
Turning a WordPress site into a Twelve-Factor App
- Backing Services
- Build, release, run
- Port binding
- Dev/prod parity
- Admin processes
Want to turn your WordPress site into a Twelve-factor App? Bedrock is a modern WordPress stack to help you get started with the best tools and practices.