The Dev Toolbox for a WordPress Build

My old WordPress development notes ran to about 28 KB, most of it PowerShell that wrote PHP. One function built a local site folder, downloaded WordPress, wrote a wp-config.php and an Apache virtual host. Another generated a plugin skeleton, and another a whole classic theme, file by file.

It all worked, and it was a fun project. It's also mostly unnecessary now, because WP-CLIWP-CLIThe command-line tool for WordPress. Anything you'd click through in wp-admin, from updates to new users, you can type or script instead.More: WP-CLI: The Commands I Keep Coming Back To does the same jobs with less to maintain. This is the condensed toolbox. Checked against the WordPress.org and WP-CLI docs in September 2026.

A local copy first

Never build on the live site. A local copy is free, fast and can be thrown away. If you already have PHP and MySQL running, WP-CLI sets up the rest:

wp core download
wp config create --dbname=example_dev --dbuser=root --prompt=dbpass
wp db create
wp core install --url=http://example.test --title="Example" --admin_user=wes [email protected] --prompt=admin_password

--prompt asks for the password instead of leaving it in your shell history. wp config create also fills in fresh security keys, which my old template left as put your unique phrase here.

Packaged local environments that bundle PHP, a database and a web server are the easier road if you don't want to run those yourself. Either way, match the PHP and database versions your host actually runs.

	Recommended by WordPress.org
PHP	8.3 or newer
Database	MySQL 8.0+ or MariaDB 10.11+
HTTPS	Required

The debug switches

These go in wp-config.php on the local copy only:

Constant	What it does
WP_DEBUG	Turns on PHP notices and warnings
WP_DEBUG_LOG	Writes them to wp-content/debug.log
WP_DEBUG_DISPLAY	Set to false so errors go to the log, not the page
SCRIPT_DEBUG	Loads the unminified core CSS and JavaScript
SAVEQUERIES	Records every database query for inspection. Slow, so local only.

wp config set WP_DEBUG true --raw
wp config set WP_DEBUG_LOG true --raw
wp config set WP_DEBUG_DISPLAY false --raw

Heads up

Use --raw for true and false. Without it, WP-CLI writes the string 'false', and PHP reads any non-empty string as true, so "off" means on.

Scaffolding instead of templates

I used to generate	Now
A plugin folder with a main file, constants, activation hooks and an admin page	wp scaffold plugin example-tools
A classic starter theme	wp scaffold _s example-theme
A child theme so updates don't wipe your changes	wp scaffold child-theme example-child --parent_theme=twentytwentyfive
A custom post type or taxonomy	wp scaffold post-type or wp scaffold taxonomy
A block	wp scaffold block

The child theme is the one I'd push on anyone editing somebody else's theme. Change the parent directly and the next update erases your work.

My old plugin template did get a couple of things right that are worth keeping: bail out early with if ( ! defined( 'ABSPATH' ) ) exit; so the file can't be loaded directly, and only enqueue admin scripts on the plugin's own settings screen.

Finding what's slow

wp profile isn't installed with WP-CLI. Add it with wp package install wp-cli/profile-command, then:

wp profile stage --fields=stage,time,query_count
wp profile hook init --fields=callback,time

It shows which part of a page load, and which plugin's hook, is eating the time. That's usually faster than turning plugins off one at a time.

Tip

Before handing a build over, run wp core verify-checksums. It confirms nobody (you included) left an edit in a core file.

Where the rest lives

The commands I use daily are in WP-CLI: the commands I keep coming back to, and the database side of a migration, where local builds usually go wrong, is in looking after a WordPress database. And if you're weighing whether a site needs WordPress at all, picking a CMS for a static blog is where I talked myself out of it for this one.