These five tools show up in most professional WordPress development setups for good reason — they each solve a distinct part of the workflow: local environment, CLI task automation, performance debugging, structured content, and version control with automated deployment. None of them are exotic; they’re the defaults the WordPress development community has converged on because they work reliably across project types.
1. Local (by WP Engine)
Local is the most widely used local WordPress development environment. It was originally called “Local by Flywheel” — Flywheel was acquired by WP Engine in 2019, and the app is now simply “Local.” It runs on macOS, Windows, and Linux.
What sets Local apart from a generic Docker or XAMPP setup:
- One-click WordPress installs with automatic database creation, wp-config setup, and a ready-to-use admin user — a fresh local site in about 30 seconds
- Choice of web server — Apache or Nginx per site, with selectable PHP versions (8.1, 8.2, 8.3)
- SSL without configuration — Local handles the self-signed cert and trusts it on your machine automatically
- Xdebug toggle — enable Xdebug per site in the Local UI, then connect your IDE’s debugger to that site’s PHP process
- Live Link — a secure tunnel that exposes your local site to a public URL for client preview, no deployment required
- WP-CLI built in — the Shell tab inside each site drops you into a terminal pre-configured with that site’s WP-CLI and PHP environment
The main alternative worth knowing: wp-env (the official WordPress Docker-based local environment, installed via npx @wordpress/env start) is better suited for block plugin development and CI environments where you need a reproducible, containerised setup. Local is better for day-to-day client site development. Both are covered with Docker and Lando in the modern local WordPress development environments guide.
2. WP-CLI
WP-CLI is the command-line interface for WordPress. Most operations you’d do in wp-admin can be done faster from a terminal, and many operations — like mass search-replace, bulk plugin updates, or running eval across a site — are only practical from the CLI.
The commands developers use most:
# Install and activate a plugin
wp plugin install advanced-custom-fields --activate
# List active plugins
wp plugin list --status=active
# Export the database
wp db export backup.sql
# Import a database
wp db import backup.sql
# Search-replace URLs (essential for migrations and environment switches)
wp search-replace 'https://oldsite.com' 'https://newsite.com' --dry-run
wp search-replace 'https://oldsite.com' 'https://newsite.com'
# Update WordPress core
wp core update && wp core update-db
# Flush object cache
wp cache flush
# Create a user
wp user create jane [email protected] --role=editor --send-email
# Run a quick PHP expression
wp eval 'echo home_url();'The wp search-replace command handles serialised PHP data correctly — something a raw SQL find-replace won’t do. It’s the standard tool for domain changes and staging-to-production migrations. WP-CLI is available inside Local’s Shell tab, inside any wp-env container (npx @wordpress/env run cli wp ...), and on any server over SSH.
3. Query Monitor
Query Monitor is a debugging and profiling plugin. It adds a toolbar to the WordPress admin bar (visible in the editor and on the frontend for logged-in users) that exposes what’s happening under the surface on every page load.
The most useful panels:
- Queries — lists every database query run on the page, with its SQL, execution time, calling function, and stack trace. Sort by time to find the slowest queries. N+1 query problems (where a loop generates one query per iteration) show up immediately.
- PHP Errors — catches notices, warnings, and deprecated function calls that don’t show on the page but accumulate silently in logs
- Hooks & Actions — shows every action and filter fired on the page, what callbacks ran on each, and which plugin/theme registered them. Essential for diagnosing hook conflicts.
- HTTP API — shows outbound HTTP requests (remote calls to APIs, webhooks, etc.) and their response times
- Template — shows exactly which template file WordPress used to render the current page, plus the template hierarchy it considered
A typical Query Monitor session: install a new plugin, reload the page, check the Queries panel — if the page went from 40 queries to 120, you know which plugin is responsible. Query Monitor identifies the bottleneck; fixing it might mean caching the query result with wp_cache_set()/wp_cache_get() or restructuring a meta query. The performance fixes those discoveries lead to are covered in the high-performance WordPress guide.
4. Advanced Custom Fields (ACF)
Advanced Custom Fields is the standard plugin for adding structured data fields to WordPress posts, pages, custom post types, options pages, and user profiles. ACF was acquired by WP Engine in 2023; it remains available in free (wordpress.org) and Pro editions.
What ACF adds to a WordPress site:
- Field groups with types like text, textarea, image, gallery, relationship, repeater, flexible content, date picker, colour picker, and more
- Field groups can be conditionally shown based on post type, template, taxonomy, page parent, and other conditions
- An Options page (ACF Pro) for site-wide settings accessible outside the post editing context
In theme templates, retrieve field values with:
<?php
// Returns the field value
$heading = get_field('hero_heading');
// Echoes the field value directly
the_field('hero_heading');
// Repeater field (ACF Pro)
if (have_rows('team_members')) {
while (have_rows('team_members')) {
the_row();
$name = get_sub_field('name');
$role = get_sub_field('role');
echo "<p>{$name} — {$role}</p>";
}
}
// Options page field
$phone = get_field('phone_number', 'option');
?>ACF Free covers most use cases: standard field types, field groups on posts/pages/CPTs. ACF Pro adds Repeater, Flexible Content, Gallery, Options Page, and the ACF Blocks API. For a comparison against Meta Box and Pods, see the ACF vs Meta Box vs Pods comparison.
5. GitHub and GitHub Actions
Version control is non-negotiable on any project with more than one developer, and it’s worth having on solo projects too — every commit is a restore point. GitHub is the default host for WordPress development repositories.
A basic branching model for WordPress development:
- main / production — what’s live. No direct pushes.
- staging / latest — mirrors the staging environment. PRs merge here first.
- feature branches — one branch per feature or fix, opened as PRs against staging.
GitHub Actions automates the deployment step. A workflow that deploys to the server on push to main:
name: Deploy to Production
on:
push:
branches: [main]
jobs:
deploy:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Deploy via SSH
uses: appleboy/[email protected]
with:
host: ${{ secrets.SSH_HOST }}
username: ${{ secrets.SSH_USER }}
key: ${{ secrets.SSH_PRIVATE_KEY }}
script: |
cd /var/www/html/wp-content/themes/my-theme
git pull origin main
composer install --no-dev
wp cache flushAdd a PHP linting step on pull requests to catch errors before they merge:
- name: PHP Lint
run: find . -name "*.php" -not -path "*/vendor/*" | xargs php -lThe full CI/CD setup — including automated PHP unit testing with PHPUnit, WordPress test bootstrap, and environment-specific deployment pipelines — is covered in the WordPress CI/CD pipeline guide. For connecting the GitHub repository to WordPress itself (webhooks, auto-syncing), see the WordPress GitHub integration guide.
How these tools compose
The five tools above cover the development lifecycle end to end: Local (or wp-env) provides the isolated development environment; WP-CLI handles the repetitive site management tasks that would otherwise take ten clicks in wp-admin; Query Monitor catches performance and error issues during development before they reach production; ACF structures content so that clients can manage complex data without editing template code; GitHub Actions automates the deployment so that a merge to main ships to the server without manual FTP or SSH copy steps.
None of them are heavy — Query Monitor and ACF both have minimal runtime overhead when used correctly, Local runs entirely on your machine, and WP-CLI and GitHub Actions have no frontend footprint at all.
