About the Author

This is the introduction to a 12 part series for turning a WordPress site into a Twelve-Factor App. Want to turn your WordPress site into a Twelve-factor App? Bedrock is a WordPress project boilerplate to help you get started with the best tools and practices. If you aren’t familiar with the Twelve-Factor App: it’s a … Continued

Factor #12: Admin processes Run admin/management tasks as one-off processes The process formation is the array of processes that are used to do the app’s regular business (such as handling web requests) as it runs. Separately, developers will often wish to do one-off administrative or maintenance tasks for the app, such as: Running database migrations … Continued

Factor #11: Logs Treat logs as event streams Logs provide visibility into the behavior of a running app. In server-based environments they are commonly written to a file on disk (a “logfile”); but this is only an output format. One of WordPress' biggest failings is not providing better logs. Most people immediately think of Apache's … Continued

Factor #10: Dev/prod parity Keep development, staging, and production as similar as possible Historically, there have been substantial gaps between development (a developer making live edits to a local deploy of the app) and production (a running deploy of the app accessed by end users). These gaps manifest in three areas: The time gap: A … Continued

Factor #9: Disposability Maximize robustness with fast startup and graceful shutdown The twelve-factor app’s processes are disposable, meaning they can be started or stopped at a moment’s notice. This facilitates fast elastic scaling, rapid deployment of code or config changes, and robustness of production deploys. Most of this factor is already taken care of by … Continued

Factor #8: Concurrency Scale out via the process model Any computer program, once run, is represented by one or more processes. Web apps have taken a variety of process-execution forms. For example, PHP processes run as child processes of Apache, started on demand as needed by request volume. In the twelve-factor app, processes are a … Continued

Factor #7: Port binding Export services via port binding This is probably the most difficult factor to apply to WordPress and that's because of PHP. Web apps are sometimes executed inside a webserver container. For example, PHP apps might run as a module inside Apache HTTPD, or Java apps might run inside Tomcat. The twelve-factor … Continued

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 … Continued

Factor #5: Build, release, run Strictly separate build and run stages A codebase is transformed into a (non-development) deploy through three stages: Build Stage The build stage is a transform which converts a code repo into an executable bundle known as a build. Using a version of the code at a commit specified by the … Continued

Factor #4: Backing Services Treat backing services as attached resources A backing service is any service the app consumes over the network as part of its normal operation. Examples include datastores (such as MySQL or CouchDB), messaging/queueing systems (such as RabbitMQ or Beanstalkd), SMTP services for outbound email (such as Postfix), and caching systems (such … Continued

Factor #3: Config Store config in the environment An app’s config is everything that is likely to vary between deploys (staging, production, developer environments, etc). This includes: Resource handles to the database, Memcached, and other backing services Credentials to external services such as Amazon S3 or Twitter Per-deploy values such as the canonical hostname for … Continued

Factor #2: Dependencies Explicitly declare and isolate dependencies With Codebase out of the way, we're already getting into unknown territory for WordPress. Most programming languages offer a packaging system for distributing support libraries, such as CPAN for Perl or Rubygems for Ruby. The packaging/dependency system for PHP is Composer. A twelve-factor app never relies on … Continued

Factor #1: Codebase One codebase tracked in revision control, many deploys The first factor is a good one to start on because it's probably the easiest. Your WordPress site/app codebase needs to be tracked in a version control system. Git, Mercurial, Subversion, etc. Pick one and use it. Git is usually the de facto choice … Continued

Sometimes when doing performance testing, you just want to do a quick test without setting up a full benchmarking test suite. WordPress and PHP offer a few tools for us to use. WP Timers WP has 2 little known functions available for us: timer_start and timer_stop. timer_start (source) just sets a global variable $timestart to … Continued

This is a follow-up to my previous post on Using Composer with WordPress. Read that first for an introduction. Our WordPress project boilerplate, Bedrock, uses Composer for dependency management. A few common questions came up after my last post and screencast. This post will hopefully clear up two of them. 1. How do I make … Continued

This post will give you an introduction to Composer and how to manage WordPress core, plugins, and even themes with it. If you already know what Composer is and how to use it and just want to see how to integrate it with WordPress, you can skip straight to the The Solution section below. Bedrock, … Continued