4 ms·

You can aim to run a truly stateless wordpress container using https://github.com/roots/bedrock https://github.com/roots/bedrock for the wordpress install toge

You can aim to run a truly stateless wordpress container using https://github.com/roots/bedrock https://github.com/roots/bedrock for the wordpress install together with Composer and https://wpackagist.org/ https://wpackagist.org/ to manage your plugins and dependencies. Then there's https://github.com/deliciousbrains/wp-amazon-s3-and-cloudfront https://github.com/deliciousbrains/wp-amazon-s3-and-cloudfro... to offload all media files to S3 (consider putting a Cloudfront distribution in front to get a custom domain + HTTPS). I've been there and I can't honestly recommend it. You'll be on your own. Also, it really really feels like Wordpress wasn't made to be deployed this way. If I were you I'd rather use a good hosting provider like WPEngine and spend my time on more valuable things.

folkhack 6y ago
Yep - I run my own composer-driven WP setup based on the roots design and can honestly say that it's an anti-pattern with how WP wants to handle plugins/themes/core updates/etc. I say it's an anti-pattern because we're talking about WP - a platform that allows you to arbitrarily update PHP files from a web admin/install plugins/etc... It's this sort of flexibility that our clients/end users want and when we start designing that BS out due to security reasons it typically ends up in a user yelling at me for "WHY CAN'T I JUST INSTALL A PLUGIN LIKE THE WORDPRESS TUTORIAL SAYS?!" When you come back with "security", and "I have to review that code" it almost always falls on deaf ears. When you start designing the flaws out of WP infra you start to realize those same flaws are why marketing is hellbent on keeping it as a CMS - they hate working with/waiting on devs to get things done.