www-data user mismatch cli / wordpress images

[uda]

I am deploying some Wordpress instances, each is a network of sites.

The wp-cli image is based on alpine, only. the Apache image is based on Debian, only. the FPM uses both Debian and alpine, but that requires another HTTP container or configuring FCGI in the LB instead of a simple proxy.

When using the wp-cli on a volume from an Apache image, you can't save the changes into the wp-config.php file, because the www-data user has different uids on alpine and debian.

So I suggest to implement the following (I thing the first is the simplest):

• wp-cli should be available on all Wordpress images, so using docker-compose exec wordpress multisite-install ... will be more efficient than having a separate service for the cli.
• wp-cli should have a debian based flavor where www-data has the same uid like the wordpress image.

Here is my current (initial) setup: https://github.com/uda/docker-wp-ms

[jaswrks]

Basically the same problem explained in a slightly different way, but in great detail, in https://github.com/docker-library/wordpress/issues/279. That issue is now closed as a duplicate, but perhaps still worth reviewing.

[tianon]

There shouldn't be anything preventing running the wordpress:cli variants as whatever UID you want (or even the non-cli variants, for that matter; see https://github.com/docker-library/wordpress/pull/249).

I'd love to get the IDs to match up, but that's not a great solution since in both instances, the www-data user comes from the base image itself (not something we create), and IMO it's not a huge problem since you can choose any runtime ID you want for all associated images.

[mfdeveloper]

Hello there!! My current solution was, create a custom Dockerfile, copy the whole content from cli/DockerFile and remove the line USER www-data. By default, whether not pass a user, docker login like root. So, access the container and use wp-cli commands with --allow-root. For me it's not a problem, because I'm using WP in a docker container by development and CI.

@tianon This can be a official solution? Or installing wp-cli directly to wordpress image like described into the issue #283 ?

[tianon]

I would love to see a clean solution to this, but as I stated above, I really don't see any way we can cleanly resolve this (especially in a way that doesn't break existing users). Both images should allow either using --user or APACHE_RUN_USER to set an explicit UID for running as, and thus this is pretty easy for users to control directly. :+1: