Twelve-Factor WordPress App #11: Logs

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 or Nginx’s web server logs as WordPress logs, but they aren’t the same thing. Those logs simply show HTTP requests but offer no visibility into the behavior of WordPress itself.

I’m working on a plugin to offer proper (as much as possible) WP logging. Keep an eye out on our site for news on it. Until then, you can investigate implementing your own logging by using WP hooks and actions, or just use the usual web server logs in the meantime.

A twelve-factor app never concerns itself with routing or storage of its output stream. It should not attempt to write to or manage logfiles. Instead, each running process writes its event stream, unbuffered, to stdout. During local development, the developer will view this stream in the foreground of their terminal to observe the app’s behavior.

This is one of the most opinionated or polarizing factor out of the 12. Especially in the PHP world where Apache + mod_php and Nginx + PHP-FPM never expose STDOUT to the user. I’m going to punt on this one and say it isn’t the end of the world if you’re writing log files.

In Practice

If you do want to follow this factor as is, PHP-FPM can actually be run in the foreground instead of as a daemon. The simplest way:

php5-fpm -y /etc/php5/fpm/php-fpm.conf -F

-F just forces the program to stay in the foreground (ignoring the daemonize option in the config).

The downside of this, as mentioned before, is that since WordPress has no real logging, you won’t see much. The standard HTTP requests you’d see in Nginx/Apache remain in those logs and not in the foreground PHP-FPM process.

The other option is to use the new built-in web server in PHP 5.4+. The benefit is you don’t need Nginx/Apache since it’s standalone. WP-CLI has a simple plugin that starts up WP on the build-in server as well. Since this server runs in the foreground, you will see all the normal HTTP requests and anything in STDOUT (which is non-existent by default).

The downside to this option was already talked about in Port Binding. The built-in web server shouldn’t be used in production. So using it in development means you won’t have Dev/prod parity.