What is meant by WordPress development

Heiko Mamerow

In this four-part tutorial, I show how Docker can be used as a WordPress development environment - for themes or plugins - on a local computer. The tutorial is aimed at developers who are looking for a practical introduction.

The parts of my tutorial are:

  1. Basics (that's this post.)
  2. Installation and configuration of a Hello World WordPress stack
  3. Set up a development environment for theme and plugin development *
  4. Operate multiple WordPress websites in parallel with Docker *

* This post has not yet been published. But soon! ;-)

By the way, on January 25, 2018 I will give a talk on the topic at the WordPress Meetup Berlin.

Part 1: Basics

In Part 1 I start with the "primordial slime" and try to explain what a development environment is, what the concept behind Docker is and how all of this can be used for local web development.

1 development environment

In order for WordPress to be able to run as a content management system, it must be integrated in a specific system environment.

When we download WordPress, we have nothing more than "a few files". If we put them on our computer, nothing will happen to them yet. A WordPress website cannot yet be operated with it. In order for WordPress to work, it needs at least the following environment:

  1. A web server (usually Apache or nginx)
  2. A script revenge on the server: PHP (best from version 7)
  3. A database (MySQL or MariaDB)
  4. Last but not least, an operating system (mostly Linux)

This system environment (often also Software packet, Software stack or just Stack can be created both on the local computer where we want to develop our website and on the provider's computer, where the website should ultimately be accessible to everyone on the Internet.

In the first case, this environment is our development environment. In the second case it is the production environment.

1.1 Why is a development environment needed?

It doesn't matter whether it's a complete website, debugging a defective theme or adding a function to a plugin. All of this work should always be carried out and tested on a local development environment before the code is used on the live system. Only when the work on the local development environment has been completed and tested can the code be transferred to the production environment with a clear conscience.

Using a development environment ensures that the website is always available and that it works as it should. New features and bug fixes can be uploaded in the background unnoticed by users and there is no downtime.

1.2 development environment == production environment

The difference between a development environment and the production environment is only nominal in relation to the system environment (see above). Both need the same stack.

But why then two names for the same?
The difference arises from the practical use:

1.2.1 Development environment

We need the development environment to test newly developed plugins, for example, or to check whether the style sheet just written by the theme does what we want in the output.

A development environment is great for playing and trying out.

Because nobody can develop without errors and it is never quite clear at the beginning how a certain task is to be developed, a system environment is needed for testing and trying things out. This is a kind of "sandpit" or "test site" where something can go wrong and cause no damage.

It is also very useful for development to display error messages. These messages would normally not be issued in the production environment.

In short: Everything that we do not want the “end users” to expect, but that is somehow part of the development process, happens in the development environment.

1.2.2 Production environment

The production environment is the environment on which the website "really" runs. This should never be tested or developed. Of course, the output of error messages should not be visible here either.

That is why it is very important - at least - to have these two environments (development / production)! There are other types of environments as well.

1.3 Development environment === Production environment

Who doesn't know that: The new website works perfectly on the development environment and nothing works on the production environment….

Client: It don't work on my webserver! Dev: Mmmmh, but works on my machine. ¯ \ _ (ツ) _ / ¯

The development environment and the production environment should be identical. It is often the case that the system environment at the provider (= production environment) has to be taken for granted. Then it is advisable to adapt the local development environment to the production environment in as much detail as possible.

If the provider offers a LAMP stack, for example, then our development environment should also be a LAMP stack. But that's not enough. Identical versions and, if applicable, are also important. Server modules and configurations. Under certain circumstances, differences in the MySQL version in the development and production environment can lead to unpleasant results. This equality in the environments can be created very well with Docker.

The more meticulously we adapt our development environment to the production environment, the lower the risk that a function will run in the development environment but not in the production environment.

... I had to pay a lot of money for that ... ;-)

1.4. A small comparison of development environments

There are already so many environments that can be used for local development. For a quick comparison I have put the most famous ones next to each other:

StacksStacks in a virtual environment
For Linux xxxx
For Mac OS xxxx
For windowsxxxx
Nginx x x xxx
Parallel operationxx

If you want a more detailed comparison between MAMP, Vagrant and Docker, you should definitely watch Bernhard's lecture “Local developement with Docker” at WordCamp Cologne 2017. In the first part of his lecture he goes into more detail about the differences, pros and cons.

2 dockers

Docker is a software technology in which the software applications run in isolation in their own closed environments. Such a closed environment is called a container. In the case of WordPress, this can be imagined as follows:

As already described above, every WordPress website is essentially operated with the following applications:

  1. server
  2. Database
  3. Server-side script language

(I neglected the operating system.)

With Docker, each of these applications is isolated in its own container. So we would have three containers.

Docker itself connects or controls these containers and ensures that the applications - in conjunction with the operating system - do what is expected of them: provide a WordPress website.

Each application runs separately in a container. This allows containers to be connected to one another.

This "container principle" has huge advantages compared to the old-fashioned static approach such as with LAMP, MAMP or WAMP:

  1. Each project can run with a very individual system environment.
    E.g. A website should run on nginx with PHP 5.6 and MYSQL 5.5 and another website on the same computer should run with Apache and still with nginx as a reverse proxy under PHP 7.1 and MariaDB. That's not a problem with Docker. With a conventional static software stack, on the other hand, quite a "pull-up".
  2. Several projects can be run in parallel.
    It is possible to run several different website projects at the same time. A real blessing if, for example, a plugin is to be tested on several different platforms.
  3. The development environment can be cloned and used on other computers.
    This enables the work in the team to be standardized. The clone can also be used on the live server, for example.

That's enough of the Docker introduction. In reality, my introduction was very imprecise and a great deal is still missing. But that's all you really need to know at the beginning to be able to use Docker. ;-)

2.1 Notes on installation

In order to use Docker, it must of course be installed on the computer. Docker is now available for all major operating systems and cloud (s). The installation is well explained in the Docker documentation and shouldn't cause any problems. That's why I'm saving the details here.

By the way, it's good to know that Docker is available in two versions: 1) as Community Edition (CE) and 2) as Enterprise Edition (EE). The difference that is relevant for us is that the Community Edition is free and the Enterprise version is chargeable. So when it comes to Docker here (and in the following articles), the Community Edition is always meant.

2.2 Docker Compose

We installed Docker and could theoretically get started. But we should also install something else: Docker Compose

Docker Compose simplifies the configuration and control of Docker because it allows all containers to be combined in one configuration file. Without Docker Compose, we would have to start and configure each application individually, each time by hand. With Docker Compose we can set all containers in a single file and start our project with a single command.

Installation is just as simple as it was before with Docker. The exact instructions can be found in the documentation.

I will make extensive use of Docker Compose in my other posts. In principle, it is enough first to know that we have our entire WordPress environment in one file docker-compose.yml configure and then start it with a command from the command line. More on that later.

What's next?

Up to this point everything was gray theory. And maybe you haven't really understood much yet. But don't panic. It is enough if you only have an approximate theoretical idea of ​​working with Docker.

in the next part the idea becomes clearer. Then I'll show you how to build an entire WordPress stack with Docker Compose. You can then try it out yourself on your computer. Then the penny slowly falls ... ;-)

This entry was posted on by Heiko Mamerow.

Heiko Mamerow

Buddhist, father, friend, website builder, athlete, music lover & road user ;-)