Include WP-CLI in all WordPress images

[mvasin]

For a while now, WP-CLI has become the official way to manage WordPress from scripts / command line.

But if you glance through docker-entrypoint.sh, the current way of installing WordPress and hacking wp-config.php with sed and awk is not pretty and error-prone compared to a bunch of WP-CLI commands like

wp core download
wp config set
wp core install

WP-CLI doesn't take too much space, and it's become essential. I propose to:

• include WP-CLI in all official WordPress images,
• deprecate the stand-alone WP-CLI image,
• refactor docker-entrypoint.sh using WP-CLI.

It will show the community the relevant way of managing WordPress from the command line, and will make it easier to actually use the image later on. It will also solve #256.

[ConstantinElse]

Having the same problem. It would be nice to be included in WP image.

[yosifkit]

While it is a great tool, it is not included in the image for a number of reasons:

• it is not the canonical way to install wordpress (https://codex.wordpress.org/Installing_WordPress)
• it cannot be removed; some users won't need it
• the cli image can be used to manage a wp installation in another container

  $ docker run --name some-mysql -e MYSQL_ROOT_PASSWORD=my-secret-pw -d mysql:5.7
  2bc33cf6d0f63ddd04ab46af874aac441377d9878ed3de303354e6a53ce82a2f
  $ docker run --name some-wordpress --link some-mysql:mysql -p 8080:80 -d -e WORDPRESS_DB_PASSWORD=my-secret-pw wordpress
  dc783a30d5a4e546e74f0b9c3a04312c1b7d107208dd0fc97aea1770ee100454
  $ docker run -it --rm \
  >     --volumes-from some-wordpress \
  >     --network container:some-wordpress \
  >     wordpress:cli user list
  Error: The site you have requested is not installed.
  Run `wp core install` to create database tables.
  $ # ran through setup in browser
  $ docker run -it --rm     --volumes-from some-wordpress     --network container:some-wordpress     wordpress:cli user list
  +----+------------+--------------+-----------------+---------------------+---------------+
  | ID | user_login | display_name | user_email      | user_registered     | roles         |
  +----+------------+--------------+-----------------+---------------------+---------------+
  | 1  | asdf       | asdf         | [email protected] | 2018-06-22 21:42:02 | administrator |
  +----+------------+--------------+-----------------+---------------------+---------------+

[mvasin]

1. https://codex.wordpress.org/Installing_WordPress DOES contain the suggestion to use wp-cli:

Installing through wp-cli wp-cli is a great command line tool with which you can easily install and update WordPress and themes and extensions.

2. Most users need it (those kind of users who mess with Docker, most of them), and it’s tiny so it doesn’t really matter. 3. WP-CLI can be used from WordPress image or anyone can craft a their own WP-CLI-only image if they desire so. The fact that WP-CLI and WP images are based on different distribution is troublesome as linked issues show. Including WP-CLI will make wp so much more programmatically manageable.

[ConstantinElse]

Personally, I use it for managing users, roles, and plugin activation/dectivation from CLI. I agree that:

1. It's a small utility in comparison to WP.
2. Having to deploy a separate container just for this - by me it's an overkill.
3. As part as WP containers build and automation I don't like the idea that to activate plugins (from CLI) - I need to run another container ... just because the wp-cli is missing

[barcia]

Yes, I also found it very useful! And I think that is lightweight and really is not intrusive for people that not use it.

[aseempatni]

Any updates on this? Are there any plans to include wp-cli in WordPress docker images?

[alexstandiford]

I too am interested to see. Currently using a variant just to get CLI running. Feels like this should be baked in.

[davilera]

I also agree. I feel like anyone who's using Docker to manage WordPress installations is very, very likely to use CLI too.

[darrenbarklie]

I also anticipated this being built in. Considering the barrier to entry is understanding and using Docker, WP CLI would be a justifiable inclusion for devops workflows.

[ffranchina]

Are there news on this? It would really be a good choice to do it!

[narthur]

An issue with relying on the current wordpress:cli image for this functionality is that, as explained here, the CLI image is based on Alpine whereas the WordPress Apache images are based on Debian, resulting in differing uid's, preventing the CLI from doing basic things like downloading & installing a new plugin.

A possible solution to this would be to use one of the Alpine WordPress images, but apparently using one of these would require you also spin up a separate Apache container, which I expect most people aren't interested in doing.

[tianon]

There shouldn't be anything stopping the CLI image from running as an arbitrary user, ala docker run ... --user 33:33 wordpress:cli wp ... (https://github.com/docker-library/docs/tree/master/wordpress#running-as-an-arbitrary-user).

[narthur]

@tianon Yeah, turned out to be a different issue. Thanks.

[ivandotv]

I have created some images which include wp-cli and some other nice stuff.
Currently only for php-fpm because I'm lazy to make the other ones (I will do it soon ).
https://github.com/ivandotv/docker-wordpress-image

[bukowa]

What is the point of running wp-cli in wordpress container? The point of containers is to run one service per container, you can use Dockerfile defined below and just mount /var/www/html to this container, then execute your commands. More advanced setup can be seen here https://github.com/project-wordpress/wpdev

FROM wordpress:cli-php7.4

USER root
COPY wait-for-it.sh /usr/local/bin/wait-for-it
RUN chown www-data:www-data /usr/local/bin/wait-for-it && \
    chmod +x /usr/local/bin/wait-for-it

COPY entrypoint.sh /usr/local/bin/entrypoint.sh
RUN chown www-data:www-data /usr/local/bin/entrypoint.sh && \
    chmod +x /usr/local/bin/entrypoint.sh


RUN mkdir /backups && chown www-data:www-data /backups
USER www-data
WORKDIR /backups

RUN mkdir ~/.wp-cli && echo "path: /var/www/html" > ~/.wp-cli/config.yml
ENTRYPOINT ["entrypoint.sh"]

[madmath03]

What is the point of running wp-cli in wordpress container?

wp-cli is not really a service (ie. it does not run in the background), but just tool to manage your WordPress instance.

Sure you can start a new container with wp-cli, plug it to your wordpress /var/www/html and run your commands, but having it bundled with your WordPress container is a lot easier, especially if you're using docker-compose or Kubernetes and do not want to manage your containers manually.

For reference, a lot of apps have their CLI either part of the project itself (NextCloud, Symfony based apps, etc...) or are added to their containers for convenience.

If some are interested, I also developed for my company a docker container based on the WP official images and which adds wp-cli with several other libraries like memcached and LDAP support : https://github.com/Monogramm/docker-wordpress

[bukowa]

and do not want to manage your containers manually

So why bundle wp-cli? Installation is more vulnerable, official docker images are make so to be minimal. Also other points that are valid from 2nd reply:

• it is not the canonical way to install wordpress (https://codex.wordpress.org/Installing_WordPress)
• it cannot be removed; some users won't need it
• the cli image can be used to manage a wp installation in another container

[madmath03]

and do not want to manage your containers manually

So why bundle wp-cli?

When I say "manage your containers manually", I mean to manually create new containers with wp-cli to manage a Wordpress instance. Having wp-cli in the container can allow you to manage your instance without creating a new container.

Installation is more vulnerable, official docker images are make so to be minimal. Also other points that are valid from 2nd reply:

• it is not the canonical way to install wordpress (https://codex.wordpress.org/Installing_WordPress)
• it cannot be removed; some users won't need it
• the cli image can be used to manage a wp installation in another container

I agree with you on those, though regarding the last point, it's usually easier to have each WP instance use their own wp-cli, and I think maybe better if you want to run wp-cli operations on several WP instances at the same time.

Anyway, I do not mind WP's decision to keep their container minimal.
I just think that having another container based on official WP which adds wp-cli (what we did in our containers) is simpler than a having a "wp-cli only" container that you need to plug to the correct wordpress instance everytime you need it...

[bukowa]

What about bundling that minimal wp-cli that really runs a service? The entrypoint just blocks forever, and then its a real service - API. Is that a solution? For me it looks clear and gives a lot of space for running some pre-installs or pre-checks, or even a cronjob that performs updates automatically.

[madmath03]

It would make sense for a cronjob purpose , but otherwise it would be more problematic since you would need to stop the container first before switching to another WP instance...

[bukowa]

need to stop the container first before switching to another WP instance...

I don't get the point, can you explain with use case?

[madmath03]

need to stop the container first before switching to another WP instance...

I don't get the point, can you explain with use case?

It's as you mentioned before: the cli image can be used to manage a wp installation in another container.

To do that with the container, you need to mount the /var/www/html of the WP instance you want to manage to your wp-cli container:

docker run -it --rm \
    --volumes-from some-wordpress \
    --network container:some-wordpress \
    wordpress:cli user list

So if you have 2 wordpress containers, A & B, respectively with the following volumes:

• WP_A: /srv/wordpress_a/html:/var/www/html
• WP_B: /srv/wordpress_b/html:/var/www/html

If you have a single wp-cli container, with a volume mounted to WP A (/srv/wordpress_a/html:/var/www/html), you will need to stop it first, change the volume to WP B (/srv/wordpress_b/html:/var/www/html) before managing your WP B instance.
Or, you need to mount volumes from all your WP instances to wp-cli container and always execute commands with --path to WP files you want to manage.

In that case, it's probably easier to just have a wp-cli container for each of your WP instances...

[bukowa]

But if you have wp-cli in each wordpress instance, you have to do the same (change your command)?

[madmath03]

But if you have wp-cli in each wordpress instance, you have to do the same (change your command)?

No you don't. That's the big advantage.
When wp-cli is bundled with Wordpress, wp-cli will use the default path, which corresponds to the current WordPress instance.

If you're using docker-compose, you can just run the following command:

docker-compose exec my_wordpress_with_cli wp user list

And just replace the my_wordpress_with_cli with the name of the WP instance you want to manage.

[bukowa]

So you have a lot of wordpress sites in one docker-compose.yaml file if i understand that correctly?
Are you using named volumes or host binding?

[madmath03]

So you have a lot of wordpress sites in one docker-compose.yaml file if i understand that correctly?

Well, that's not my use case, I usually only have one WordPress at the time, but this is the use case for the point you mentioned.

Are you using named volumes or host binding?

Why this would be relevant ?

[bukowa]

@madmath03
With this command you can still connect to all stacks if you have consistent naming, just change $NAME

NAME=wpdev && docker run -it \
--volumes-from="${NAME}_wordpress_1" \
--network="${NAME}_default" \
wordpress:cli-php7.4 \
\
/bin/bash -c "wp core update"
Success: WordPress is up to date.

Or if you have non-consistent naming place .env file in your docker-compose.yaml folder, docker-compose will read it automatically:

---------- 420 buk 345233  236 Jan 26 14:06 .env
---------- 420 buk 345233  124 Jan 26 14:06 docker-compose.yaml

# .env
NETWORK_NAME=mynetwork
WORDPRESS_CONTAINER=mycontainer

# docker-compose.yaml
networks:
  test:
    name: $NETWORK_NAME

services:

  wordpress:
    container_name: $WORDPRESS_CONTAINER
    networks:
      - test

  mysql:
    networks:
      - test

And then run:

source .env && \
docker run -it \
--volumes-from="${WORDPRESS_CONTAINER}" \
--network="${NETWORK_NAME}" \
wordpress:cli-php7.4 \
\
/bin/bash -c "wp core update"
Success: WordPress is up to date.

To use name in networks you have to use docker-compose >= 3.4
Also, keep in mind:

Values in the shell take precedence over those specified in the .env file. If you set TAG to a different value in your shell, the substitution in image uses that instead

• See https://docs.docker.com/v17.12/compose/environment-variables/#set-environment-variables-with-docker-compose-run

Or use labels :)

[weeping-somnambulist]

@madmath03

It's as you mentioned before: the cli image can be used to manage a wp installation in another container.

This is not a viable solution and the community has told you this in multiple different ways. The wp-cli is the only SANE way to manage wordpress in a Docker environment, period.

Well, that's not my use case, I usually only have one WordPress at the time, but this is the use case for the point you mentioned.

Your use case is irrelevant.

And just replace the my_wordpress_with_cli with the name of the WP instance you want to manage.

Also not effective. Not everyone has docker-compose installed, or even uses Docker with OCI containers to begin with. This is a hack, and not a good one at that.

People are repeatedly telling you that the "other container solution" is not effective, doesn't fit the general use case of wordpress in a standalone container, and that wp-cli is not optional or arbitrary. Furthermore the excuses for why it's not included are absolutely nonsensical - if you're that concerned about the size of the container, make a "minimal" tag that doesn't include it, which is actually the idiom that many containers use in the first place.

[weeping-somnambulist]

@madmath03

Yet another reason why your second container hack isn't viable, straight from the documentation itself:

NOTE: Since March 2021, WordPress images use a customized wp-config.php that pulls the values directly from the environment variables defined above (see wp-config-docker.php in docker-library/wordpress#572 and docker-library/wordpress#577). As a result of reading environment variables directly, the cli container also needs the same set of environment variables to properly evaluate wp-config.php.

[tianon]

Please keep the discussion respectful.

[pluraltouch]

could not we just post here a dockerfile, which is FROM wordpress and adds a CLI installation to the image, then using that?

[pluraltouch]

There is also problem we did not mentioned here before when running cli from other container.

In the old days for the cli it was enough to know the path for the wp installation folder, so multiple wp installations could be handled by simply using the default path or the --path switch of the cli. So we may think that using docker volumes creatively and allowing the necessary network connectivity we can still use one cli container for multiple wp docker containers.

However there is a trap, which makes this thing more painfully what it seems:

The newer wp docker images do not write the db info and credentials to wp-config.php, instead just write environment variable references to the wp-config.php. This means, that cli can not get that information by simply reading the pointed wp folders wp-config.php. If the cli is running in other container, it is impossible for it to get the values those env variables. The only way is, to set the same env variables redundantly in the cli container too. So we must manage multiple sets of environment variables and spin up the cli image every time with different set of the environment variables, because pointing to a wp installation folder is not enough anymore

[theDanielJLewis]

This is also now a big issue with Docker-based management systems like Coolify. I finally figured out a way to get the WP-CLI container to talk to my WP container, but then I'll need to do all those steps for my other sites.

But even then, I have to enter or exec the WP-CLI container specific to that site in order to do things with the other container.

It would be so much easier, faster, and simpler to package them together (or simply offer a third image like wordpress:with-cli) so WP-CLI can be run within the container it's actually controlling.

This issue is almost 7 years old. 😢