First published on 2022-12-02

Hello all! In this article, I outline my local docker setup for developing wordpress plugins and themes. I use docker to run local mysql (multiple versions) and php (multiple versions) as well as manage the wordpress installed plugins. Furthermore, I use the same setup for deploying to production, so it is particularly useful.

The majority of configuration resides in Dockerfile and docker-compose.yml, however, I also have a few scripts and naming formalisms that facilitate development and rational thinking.

Files

config.json

You don't really need this file, however, I find it helpful. It is the current (if temporary) configuration of the wordspace. Currently it only has one parameter: the project you are working on. I use this setup to work on multiple projects, and it would be inconvenient to specify the current project, for each script that I run. So I set the project name in this file, and all the scripts use that as the configuration. The file looks like this:

    // <ROOT>/config.json  
    {  
    "application_name": "wasya_co_wp_development"  
    }  

The workspace then expects <ROOT>/wasya_co_wp_development_config.json , <ROOT>/wasya_co_wp_development_data, and in docker-compose.yml there is a service called wasya_co_wp_development .

Naming Conventions

The project name is obviously <project-title>_<component>_<env> , so I also have wasya_co_wp_staging and wasya_co_wp_production . There are also databases wasya_co_db_development and wasya_co_db_production . And there are services called wasya_co_db_development and wasya_co_db_production . Notice that although the expected names are strict, each one can be overwritten. For example, to use a staging db in development, I would change the docker-compose.yml service definition.

Working on a theme

The actual theme is in a github repo located in <ROOT>/<dir_data>/themes/<theme_name> . After making the necessary changes in theme files (and testing them!), I git commit/push to remote, and the deploy process picks up those changes.

The deployment process

1. Jenkins setup for developing a wordpress theme
2. Jenkins setup for developing a wordpress plugin
3. Copying a database from production/staging to the local development db

README.txt

This file has useful snippets that I run all the time that I don't automate. For example, when I move or copy databases around, I run this command all the time:

update wp_options set option_value='http://localhost:8019' where option_id in (2, 1);

Another example is the line for changing wordpress admin password:

    UPDATE `wp_users` SET `user_pass` = MD5( 'test1234' ) WHERE `wp_users`.`user_login` = "admin";

You may wonder why the file is called *.txt and not an *.md file, since markdown is the preferred format of README files on github. The reason for this is, .md files are hard to open on mobile, and if I have to read or edit a code file on my phone, .txt works so much better for it. One time being unable to read an .md file on my phone was enough for me to switch to .txt extension.

Dockerfile 

Wordpress, PHP config 

allow shorthand <?='hello' ?>

Instead of `<?php echo 'hello' ?>` you can write `<?= 'hello' ?>` but doing so requires a php configuration. Specifically, I added this to Dockerfile: 

    RUN sed -i 's/short_open_tag = Off/short_open_tag = On/g' /etc/php/8.1/apache2/php.ini 

You can adjust your version of php as needed.