Make ClassicPress a 12 Factor App...ish

[discobot]

WordPress has long followed an operational model that makes deploying, updating, and maintaining it automatically difficult.

While the formal Twelve-Factor App structure adheres a little too rigidly to the Heroku deployment model, it offers a number of advancements that would greatly aid operational concerns with ClassicPress.

For reference, I’m referring to this: https://12factor.net/

As an example, implementation of configuration in the environment - not on the filesystem - would improve flexibility and make operating ClassicPress in a Docker container more viable. An excellent library for this exists in the form of Vance Lucas’s phpdotenv: GitHub - vlucas/phpdotenv: Loads environment variables from `.env` to `getenv()`, `$_ENV` and `$_SERVER` automagically.

Another part of the Twelve-Factor App model that would help in operations is logging. WordPress’s logging model is just to rely on the reverse proxy serving it. ClassicPress would benefit from adopting Jordi Boggiano’s monolog library (GitHub - Seldaek/monolog: Sends your logs to files, sockets, inboxes, databases and various web services), as it implements the PSR-3 standard and makes logging much more manageable from an operations standpoint.

Note: this petition has huge scope, and would be best served by being adopted as an overarching strategy, rather than an atomic change.

---

Read-only archive: Issues · ClassicPress/ClassicPress · GitHub

Author: Ben Overmyer

Vote count: 8

Status: open

---

Comments

This is an add-on suggestion. If we were to incorporate Monolog we should also consider incorporating Wonolog too: GitHub - inpsyde/Wonolog: Monolog-based logging package for WordPress.

~ posted by Mike Schinkel

12factor is interesting but it does answer to a specific use case in which deployment is done from the command line.

AFAIK it is just impossible to set OS enviroment variables from a web server, and you are not going to be able to even dream about such functionality in a shared hosting enviroment.

The most relevant config changes I can think of between different deploys (mostly production/staging/dev type of deploys) are the DB credentials. The biggest challenge is probably where to locate an enviroment file that will contain such information in a consistent way which is both outside of GIT hierarchy, but still guarantied to be writable and readable over different platform and hosters.

As for logging, I always find that it is more challenging to decide what to log than do the logging itself. IMHO this will require some user control in one way or another.

~ posted by Mark Kaplun

The thing with phpdotenv is that it can be set up in such a way that it looks at environment variables first, and if it doesn’t find the settings it needs there, you can set configuration another way. It’s not an all-or-nothing approach. The Laravel framework does this really well:

Configuration - Laravel - The PHP Framework For Web Artisans

~ posted by Ben Overmyer

Read the documentation and it does seem nice, but in the end, isn’t it just splitting wp-config.php file into two files?

I think that one of the problems with wp-config is that it is too tempting, and sometime unavoidable, to write code in it. If you need to add a call to “getenv” instead of having an if statements which check if you are in production or not, you do get a cleaner code, that the core problem is still unresolved.

~ posted by Mark Kaplun

Right, but then the only part of your config that contains sensitive info and varies depending on environment is the .env file, which is just key-value data.

After removing all such info from the wp-config.php file, and adding getenv calls and possibly a few more bits of custom code, you simply commit it.

This is implemented at GitHub - ClassicPress/ClassicPress-Network: Old code repository for *.classicpress.net - Do not use! for example. There are a lot of parts I am not satisfied with yet but I quite like the .env setup.

~ posted by James Nylen

James, I will probably take inspiration from you, but right now what I see in the example file it is problematic IMHO as you do want your salts in GIT, or some other place in which it will be easily shared in a multi server enviroment.

~ posted by Mark Kaplun

Using some google mojo I finally found something that I read a while back… Are you guys familiar with how bedrock configuration works? https://roots.io/bedrock/docs/configuration-files/

~ posted by Mark Kaplun

I will be sharing a solution for review very, very soon that I am in the middle of implementing which I named “Better WP-Config.”

~ posted by Mike Schinkel

As promised here is the solution named Better WP-Config that I wanted to share for review.

• GitHub - wplib/better-wp-config: A better way to bootstrap WordPress

It is a general-purpose solution for WordPress, not something I was intending to be ClassicPress only, so I think I would like to promote for use by all of the WordPress community assuming it does meet many people’s needs as I envision it will.

If any of you are willing to provided specific feedback on this I would appreciate first doing so either our Slack (join here: [1]) or our GitHub issues[2] to keep this petition from turning into a huge discussion about Better WP-Config which could easily turn into many issues on our GitHub.

If I can get traction in general then maybe we can evaluate for use in ClassicPress?

Thanks in advance.

[1] https://launchpass.com/wplib
[2] Issues · wplib/better-wp-config · GitHub

~ posted by Mike Schinkel