Why Many WordPress Environments Are Needed

WordPress themes and plugins must behave correctly across a wide range of installations. The possible combinations of environments worth testing include: different PHP versions, different WordPress versions, different versions of the block editor, HTTPS enabled or disabled, and multisite enabled or disabled. Each of these variables can introduce breaking changes or feature requirements that affect how your product runs.

For instance, PHP 8.0 introduced breaking changes compared to earlier releases, yet WordPress still officially supports PHP 5.6. That means a plugin may need to support PHP 5.6 through 8.0 — seven versions total. WordPress itself occasionally introduces breaking changes, such as the jQuery update in version 5.6, and new features like the block editor in 5.0 may become requirements.

If your theme or plugin contains custom blocks, you must test against both the Gutenberg version bundled with WordPress core and the standalone Gutenberg plugin. HTTPS and multisite also matter: you might want to restrict a REST endpoint to HTTPS only, or provide super-admin-only capabilities in a multisite network.

Reducing the Matrix

Automating tests with continuous integration helps, but you can't rely on machines alone. You will also need to open a real WordPress site in a browser to visually confirm that your themes and plugins still render as intended after upgrades. If Gutenberg updates its global styles or core block behavior, you need to see the impact.

Suppose you target four PHP versions (7.2–8.0), five WordPress versions (5.3–5.7), both Gutenberg variants, HTTPS on/off, and multisite on/off. That's 160 combinations. Far too many to maintain. Instead, a smaller set of sites can collectively cover the relevant properties:

  1. PHP 7.2 + WP 5.3 + Gutenberg core + HTTPS + multisite
  2. PHP 7.3 + WP 5.4 + Gutenberg plugin + HTTPS + multisite
  3. PHP 7.4 + WP 5.5 + Gutenberg plugin + no HTTPS + no multisite
  4. PHP 8.0 + WP 5.6 + Gutenberg core + HTTPS + no multisite
  5. PHP 8.0 + WP 5.7 + Gutenberg core + no HTTPS + no multisite

Spinning up five sites is manageable but not trivial without the right tooling. Enabling specific PHP versions and provisioning HTTPS certificates are both technical hurdles. What you want is an automated, rapid way to create these environments without becoming a systems administrator.

Introducing DevKinsta

DevKinsta is a free tool from Kinsta, available for Windows, macOS, and Ubuntu. It leverages Docker to isolate applications in containers, but you don't need to know anything about Docker to use it. DevKinsta handles the complexity behind the scenes. Its purpose is to simplify WordPress project work — whether you're a designer, developer, freelancer, or agency.

Initial screen in DevKinsta
Initial screen in DevKinsta. (Large preview)

Upon first launch, DevKinsta presents three ways to create a local WordPress site:

  1. New WordPress site — uses defaults: latest WordPress and PHP 8.
  2. Import from Kinsta — clones configuration from an existing MyKinsta-hosted site.
  3. Custom site — accepts a configuration you provide.

The first option creates a site with a single click. The second imports from MyKinsta, including a database dump, and local changes can also be pushed back to staging. The third opens a configuration screen where you have control.

Custom configuration for new WordPress site.
Custom configuration for new WordPress site. (Large preview)

Some configuration fields are read-only for now. The webserver is currently fixed to Nginx, with Apache support underway. Configurable options include:

  • Site name (from which the local URL is derived)
  • PHP version
  • Database name
  • HTTPS enabled/disabled
  • WordPress site title
  • WordPress version
  • Admin email, username, and password
  • Multisite enabled/disabled

Creating the Required Sites

For the first site — configured with PHP 8.0 and named graphql-api-on-php80 — the entire creation process took two minutes. Once created, the site's info screen appears with its local domain, in this case graphql-api-on-php80.local. An "Open site" button loads it in your browser.

Launching the new WordPress site.
Launching the new WordPress site. (Large preview)

Repeating this process for the remaining environment combinations yields all five local sites, each listed in DevKinsta's initial screen.

List of sites
List of sites. (Large preview)

Installing Plugins via WP-CLI

All conditions are now satisfied except installing Gutenberg as a plugin. You could do this through the WP admin, accessible via the "WP admin" button. A better route: DevKinsta ships with WP-CLI pre-installed, allowing command-line interaction.

This requires a minimal understanding of Docker. DevKinsta's container is called devkinsta_fpm, and the WP-CLI command follows this pattern:

  • wp plugin install {pluginName} --activate --path={pathToSite} --allow-root
  • The site path inside the container is /www/kinsta/public/{siteName}

The full command to install and activate the Gutenberg plugin becomes:

docker exec devkinsta_fpm /bin/bash -c 'wp plugin install gutenberg --activate --path=/www/kinsta/public/MyLocalSite --allow-root'

Database and Email Tools

Two features stand out for local development. First is integration with Adminer, a phpMyAdmin-style tool for managing the database. Clicking the "Database manager" button on the site info screen opens Adminer in a new tab, where you can run custom SQL queries and edit data directly.

Managing the DB with Adminer
Managing the DB with Adminer. (Large preview)

Second is MailHog, a popular email testing tool. Any email sent from your local WordPress site is captured rather than delivered, then displayed in the Email inbox. Clicking an email reveals its full contents.

Captured outgoing emails, in the Email inbox
Captured outgoing emails, in the Email inbox. (Large preview)
Reading the content of the email
Reading the content of the email. (Large preview)

Editing Files Directly on Disk

Local site files are accessible through your operating system's filesystem, not just inside the Docker container. The paths are:

  • Mac and Linux: /Users/{username}/DevKinsta/public/{siteName}.
  • Windows: C:\Users\{username}\DevKinsta\public\{siteName}.

This direct file access offers a significant shortcut when working on your own plugins or themes. Instead of uploading a new plugin version to each site via WP admin or WP-CLI, you can clone a plugin's repository directly into wp-content/plugins:

$ cd ~/DevKinsta/public/MyLocalSite/wp-content/plugins
$ git clone [email protected]:leoloso/MyAwesomePlugin.git

Updating the plugin becomes a simple git pull, making the latest version immediately available in the local WordPress site.

$ cd MyAwesomePlugin
$ git pull

To test a feature branch, run git checkout instead:

git checkout some-branch-with-new-feature

For sites among the five with different environments, you can script the entire process. A bash loop over the local WordPress site folders can execute git pull for the plugin in each one:

#!/bin/bash

iterateSitesAndGitPullPlugin(){
  cd ~/DevKinsta/public/  
  for file in *
  do
    if [ -d "$file" ]; then
      cd ~/DevKinsta/public/$file/wp-content/plugins/MyAwesomePlugin
      git pull
    fi
  done
}

iterateSitesAndGitPullPlugin

Why DevKinsta Fits Into a Local WordPress Workflow

The main advantage of local development environments is that they let you focus on the code rather than on the infrastructure. DevKinsta takes that further by reducing the setup time for each new project. Instead of manually configuring a web server, database, and PHP environment, you can create a fresh WordPress installation with a single action.

Because the tool is built around the same containerized architecture that Kinsta uses in production, switching between local and hosted environments is less painful. You can spin up several sites with different configurations, test themes and plugins in isolated environments, and tear them down without affecting your other work.

Getting the Most Out of DevKinsta

DevKinsta is under active development, so it is worth checking the official documentation when you run into unexpected behavior. For questions that the docs do not cover, the Community forum is the place to get direct help from the team behind the tool.

Whether you are building custom blocks, refining a theme, or just need a throwaway WordPress instance to test a plugin, the ability to quickly create and manage multiple local sites removes a lot of friction. The core workflow stays the same: press a button to create a site, do your work, and move on to the next experiment.

DevKinsta is free to use. If you want to try it, download it from the official site and start creating local WordPress installations.

Smashing Editorial