Stateless wordpress and media best practices

[davidsteinberger]

I've been playing around with this repo lately and like it a lot. I made a few tweaks (like don't use https b/c my reverse proxy does the ssl handling, serve static files created by a caching plugin if they exist, ...), but changing those things was super easy. Kudos!

The one thing I struggle though is the question on how to deal with the uploads. I can use the admin backend to alter pages and posts. Those changes get stored into the DB and a backup is created automatically. But what about media uploads? One solution is to simply not do media uploads but instead deploy a new stateless image. That works great, but is a bit tedious/complicated for somebody not familiar with docker. Another option seems to be a plugin like wp-stateless.

How do you recommend dealing with uploads?

[AcNette]

Found a way months ago : the upload folder of the current month got other auth than the new one.

Chown -R www-data:www-data path-to-folder

(usually wp-content/uploads/2018/06 for June 2018 :))

[davidsteinberger]

Thanks. However I was not talking about some upload issues. I was more interested in how to deal with that media in the container:

• If I have access to the container I can create an archive and use that in the next image. But like I said above, that can get tedious.
• Plugins like WP-Stateless, WP Offload S3 Lite or Media Cloud solve that by pushing that data to the cloud. While I like that it can get problematic with some plugins.
• Mapping a volume straight into /usr/share/nginx/www/wp-content/uploads is not going to work as it collides with the clean install via wp-cli. One workaround that I could see though is to map some other directory and create a cron job that dumps the data to that share.

[rija]

I also want to solve the same problem, so that I can scale Wordpress (the upload directory is the persistent state that's blocking that).

My current thinking is to use Rancher's Convoy Docker volume plugin. It can take a NFS share or EBS as a backend and it's completely transparent to Wordpress. Also, It makes it easier to to snapshot/backup/restore of that volume.

Regarding the mapping collision, what matters is that Wordpress knows where the upload directory is and that can be configured using the UPLOADS variable in config.php. I do set up a few variables already in config.php so this is just one more. Therefore the volume mount point doesn't have to be the default one.

This is will evenutually land in this project after I've refactored the Dockerfile and docker-compose files to more up-to-date practices.