For most of my WordPress projects I use my own Alcedo WordPress workflow. With some extra scripts, creating a new site is as easy as running 'create site.c7'in the terminal. This sets up a full WordPress install with local domains and certificates.
But, in this case i’m using a different setup in which I use the default wordpress:php8.0 docker image. As i’m using the standard setup, I also wanted to use the default wordpress:cli docker image.
How does that work?
As they say, an image says more then a thousands words. But, since text in images can’t be copied, I’ll copy/paste the two services below:
wp:
container_name: ${NAME}-wp
depends_on:
- db
image: wordpress:php8.0
user: 1000:1000
volumes:
- ./app/www/content/plugins:/var/www/html/wp-content/plugins
- ./app/www/content/mu-plugins:/var/www/html/wp-content/mu-plugins
- ./app/www/content/themes:/var/www/html/wp-content/themes
- uploads:/var/www/html/wp-content/uploads:rw
- wordpress:/var/www/html
ports:
- "8000:80"
environment:
WORDPRESS_DB_HOST: ${NAME}-db:3306
WORDPRESS_DB_USER: ${DB_USER}
WORDPRESS_DB_PASSWORD: ${DB_PASSWORD}
WORDPRESS_DB_NAME: ${DB_NAME}
WORDPRESS_DEBUG: 1
VIRTUAL_HOST: "${SITE_DOMAIN}" # Used for nginx-proxy
VIRTUAL_PORT: 80 # Used for nginx-proxy
LETSENCRYPT_HOST: "${SITE_DOMAIN}" # Used for nginx-proxy
WORDPRESS_CONFIG_EXTRA: |
/* Multisite */
define( 'MULTISITE', true );
define( 'SUBDOMAIN_INSTALL', true );
define( 'DOMAIN_CURRENT_SITE', 'sitec7' );
define( 'PATH_CURRENT_SITE', '/' );
define( 'SITE_ID_CURRENT_SITE', 1 );
define( 'BLOG_ID_CURRENT_SITE', 1 );
expose:
- "80"
wpcli:
container_name: ${NAME}-cli
depends_on:
- wp
image: wordpress:cli
user: 1000:1000
command: tail -f /dev/null
volumes:
- wordpress:/var/www/html
environment:
WORDPRESS_DB_HOST: ${NAME}-db:3306
WORDPRESS_DB_USER: ${DB_USER}
WORDPRESS_DB_PASSWORD: ${DB_PASSWORD}
WORDPRESS_DB_NAME: ${DB_NAME}
profiles:
- devAs you see, both images use the same volume and environment setup. This allows you to run commands like:
docker exec site-cli wp --infoand
docker exec site-cli wp search-replace "test" "test1" --dry-runWant to make it even easier? Set an alias for docker exec site-cli wp so that you can run something like sitewp --info. In my own development environment, my folders are named the same as my container. When you change directory, and the directory has an .env file, an alias is set for wp and links to the correct container.
Happy developing!
Hey,
I added your wp-cli snippet to my docker-compose.yml but it didn’t work.
It runs with no error but there’s no wpcli container.
services:
db:
image: mariadb:latest
command: ‘–default-authentication-plugin=mysql_native_password’
volumes:
– ./db_data:/var/lib/mysql
restart: always
environment:
– MYSQL_ROOT_PASSWORD=${DB_ROOT_PASSWORD}
– MYSQL_DATABASE=${DB_NAME}
– MYSQL_USER=gpuser${DB_USER}
– MYSQL_PASSWORD=${DB_PASSWORD}
networks:
– backend
redis:
image: redis:alpine
restart: always
volumes:
– ./redis_data:/data
networks:
– backend
pma:
image: phpmyadmin/phpmyadmin
environment:
PMA_PORT: 3306
PMA_ARBITRARY: 1 # To allow fill db credentials
restart: always
depends_on:
– db
networks:
– backend
– frontend
wp:
image: wordpress:latest
container_name: wp-${NAME}
user: ${UID}:${GID} # echo $UID
volumes:
– ./wp_data:/var/www/html:rw
– ./wordpress.ini:/usr/local/etc/php/conf.d/wordpress.ini
restart: always
environment:
– WORDPRESS_DB_HOST=db
– WORDPRESS_DB_NAME=${DB_NAME}
– WORDPRESS_DB_USER=${DB_USER}
– WORDPRESS_DB_PASSWORD=${DB_PASSWORD}
– DISABLE_WP_CRON=true
– WP_REDIS_HOST=redis
– WP_CACHE_KEY_SALT=${SALT_KEY}
networks:
– backend
– frontend
wpcli:
image: wordpress:cli
container_name: wpcli-${NAME}
depends_on:
– wp
– db
user: ${UID}:${GID}
command: tail -f /dev/null
volumes:
– ./wp_data:/var/www/html
environment:
– WORDPRESS_DB_HOST=db
– WORDPRESS_DB_NAME=${DB_NAME}
– WORDPRESS_DB_USER=${DB_USER}
– WORDPRESS_DB_PASSWORD=${DB_PASSWORD}
profiles:
– dev
networks:
– backend
– frontend
networks:
frontend:
external: true
backend:
external: true
volumes:
db_data:
wp_data:
You might want to try removing this part;
“`
profiles:
– dev
“`
Thanks for your post, very helpful!
On the wp-cli service, the ‘command: tail -f /dev/null’ line seems to be necessary to prevent the container from immediately dying, but I’ve read lots of other tutorials and I haven’t seen this done anywhere else. How come no one else does this? How do they use the WP CLI image?
I like to keep them running, but I think others use (start and stop) the container by running commands on it directly
It worked like a charm! Thank you, Marinus!