Mike Lopez

Development

How to Set Up WordPress in Lando for Plugin Development

By Published Updated

How to Set Up WordPress in Lando for Plugin Development

A useful Lando WordPress setup should be reproducible from a small configuration file. You should be able to clone the project, run lando start, use WP-CLI, and get to plugin work without rebuilding the environment by hand.

This guide first shows the standard WordPress recipe with a complete .lando.yml. It then covers landowp, the wrapper I use when I want a disposable WordPress installation around a plugin repository.

What Lando provides for WordPress

Lando runs the local web server, PHP, database, and development tooling in containers. Its official WordPress recipe includes WP-CLI and supports configurable PHP, database, webroot, web server, and Xdebug settings.

For plugin development, this gives you:

  • Explicit PHP and database versions
  • A local HTTPS URL
  • WP-CLI inside the application container
  • Repeatable start, stop, rebuild, and database commands
  • A configuration file that can be committed with the project

Install Docker and Lando before continuing.

A complete Lando WordPress recipe

For an existing WordPress project whose index.php lives in the repository root, create .lando.yml:

name: my-wordpress-site
recipe: wordpress

config:
  webroot: .
  php: '8.3'
  database: mysql:8.0
  xdebug: false

The Lando documentation recommends setting PHP and database versions explicitly because recipe defaults can change. PHP 8.3 and MySQL 8.0 are its current recommended WordPress values. Use versions compatible with the plugin and production environment you need to test.

Start the application:

lando start
lando info

lando info shows the local URLs and connection details. If the project uses a different document root, such as wordpress or public, change webroot to that directory.

Connect wp-config.php to the Lando database

The default WordPress recipe database credentials are:

define('DB_NAME', 'wordpress');
define('DB_USER', 'wordpress');
define('DB_PASSWORD', 'wordpress');
define('DB_HOST', 'database');

The host is database, not localhost, because WordPress connects to the database service over Lando's internal network.

Check lando info before copying these values into an existing project because a customized Landofile may use different credentials.

Create a new WordPress site with Lando

Lando can initialize a vanilla WordPress installation directly from the official archive:

mkdir wordpress-plugin-site
cd wordpress-plugin-site

lando init \
  --source remote \
  --remote-url https://wordpress.org/latest.tar.gz \
  --recipe wordpress \
  --webroot wordpress \
  --name wordpress-plugin-site

lando start

Create the WordPress configuration:

lando wp config create \
  --dbname=wordpress \
  --dbuser=wordpress \
  --dbpass=wordpress \
  --dbhost=database \
  --path=wordpress

Then install WordPress:

lando wp core install \
  --url=https://wordpress-plugin-site.lndo.site/ \
  --title="Plugin Development" \
  --admin_user=admin \
  --admin_password=password \
  [email protected] \
  --path=wordpress

Those credentials are for local development only. Do not reuse the password on a public or shared environment.

Useful WP-CLI commands in Lando

The WordPress recipe exposes WP-CLI as lando wp:

lando wp core version
lando wp plugin list
lando wp plugin activate my-plugin
lando wp theme list
lando wp db export database.sql

You can install development plugins the same way:

lando wp plugin install query-monitor --activate

If WordPress lives in a subdirectory and WP-CLI does not already know the path, pass it explicitly:

lando wp plugin list --path=wordpress

Import and reset a local database

Lando can import uncompressed, gzipped, or zipped database dumps stored inside the application directory:

lando db-import database.sql.gz

For a disposable development database, WP-CLI can reset it and reinstall WordPress:

lando wp db reset --yes
lando wp core install \
  --url=https://my-wordpress-site.lndo.site/ \
  --title="Plugin Development" \
  --admin_user=admin \
  --admin_password=password \
  [email protected]

Use lando db-export or lando wp db export before resetting anything you need to keep.

Enable Xdebug only when needed

Change the recipe setting when you need interactive debugging:

config:
  xdebug: true

Then rebuild the application:

lando rebuild -y

Xdebug adds overhead, so I leave it disabled for ordinary requests and enable it for a focused debugging session.

Use landowp for a disposable plugin environment

The standard recipe works well when the repository contains a complete WordPress site. My landowp project solves a different problem: the repository contains only a plugin, and I want a disposable WordPress installation wrapped around it.

Install the script somewhere on your PATH:

git clone https://github.com/easterncoder/landowp.git
cd landowp
chmod +x landowp
sudo mv landowp /usr/local/bin/

From a plugin directory, build the environment:

cd my-wordpress-plugin
landowp build my-plugin-app

landowp build creates .landowp/.lando.yml and .landowp/wp-cli.yml, starts the services, downloads WordPress, and installs it when needed. Its current defaults use PHP 8.4, MariaDB 11.4, and Xdebug. The plugin repository is mounted read-only inside the generated WordPress site.

If the app name is omitted, landowp derives it from the current directory:

landowp build

Daily landowp workflow

After the environment exists, arguments are forwarded to Lando:

landowp start
landowp wp plugin list
landowp wp plugin install query-monitor --activate
landowp wp db export database.sql
landowp stop

Run the command from the plugin repository so landowp can find .landowp/.lando.yml.

To destroy the generated application and remove .landowp, use:

landowp purge

The command asks for confirmation because it destroys the Lando application and its local database.

Standard recipe or landowp?

Use the standard Lando WordPress recipe when:

  • The repository contains the whole WordPress project.
  • The team wants to customize services and tooling directly.
  • The Landofile should describe a long-lived local environment.

Use landowp when:

  • The repository contains a plugin rather than a whole site.
  • WordPress should remain disposable test infrastructure.
  • You regularly create and remove isolated plugin environments.
  • You want one command to download WordPress and mount the current plugin.

Both approaches use Lando's WordPress recipe underneath. The difference is whether the WordPress installation is the project or a temporary host for the project.

Lando WordPress troubleshooting

WordPress cannot connect to MySQL

Confirm that DB_HOST is database, then compare the remaining credentials with lando info.

The local URL returns the wrong directory

Check the webroot value. It must point to the directory containing the public WordPress entry point.

WP-CLI cannot find WordPress

Pass --path=wordpress or configure the project path in wp-cli.yml.

Configuration changes do not appear

Run lando rebuild -y after changing PHP, database, server, or service configuration.

A plugin change does not appear in landowp

Run commands from the plugin repository and confirm the generated application mounted that directory. Re-run landowp build if .landowp was removed.

Keep the setup repeatable

A good WordPress development environment is explicit, disposable, and boring. Commit the standard .lando.yml when the site owns the environment. Use landowp when the plugin needs a temporary WordPress host.

That separation keeps environment setup out of the plugin itself while still giving every developer the same PHP, database, WP-CLI, and WordPress workflow. It also makes onboarding developers to a plugin codebase much easier.

If you need help standardizing WordPress plugin development across a team, my WordPress and PHP consulting services include local tooling, automated testing, and development workflow design.