Programmer’s Reference
Inspect a WordPress installation and practice careful maintenance.
WP-CLI must be installed. Run from a demo WordPress directory as its appropriate owner, or supply --path. Verify backups before changing data; never copy live credentials.
Select a term for its definition, syntax, example, and common mistakes.
Inspect WP-CLI and the WordPress version at a fixed demo path.
wp --info
wp --path=/srv/demo-wordpress core versionPractical useInspect a staging installation independently of the application UI.
Common mistakesThe path must contain a WordPress installation. Run as an appropriate unprivileged user; do not normalize --allow-root.
Source: developer.wordpress.org documentation (1) · developer.wordpress.org documentation (2)
List installed extensions and their current status.
wp --path=/srv/demo-wordpress plugin list
wp --path=/srv/demo-wordpress theme listPractical useInspect a demo site before a maintenance plan.
Common mistakesActive is not a security or compatibility guarantee. Public reports should omit private site details.
Source: developer.wordpress.org documentation (1) · developer.wordpress.org documentation (2)
Show a bounded set of post IDs, titles, and status values.
wp --path=/srv/demo-wordpress post list --post_type=post --posts_per_page=10 --fields=ID,post_title,post_status --format=tablePractical useVerify content status in an authorized staging site.
Common mistakesPrivate or draft titles may be confidential. Confirm the site and avoid publishing output verbatim.
Read the home and siteurl settings individually.
wp --path=/srv/demo-wordpress option get home
wp --path=/srv/demo-wordpress option get siteurlPractical useCheck a demo site’s expected public address.
Common mistakesDo not dump all options; they can contain secrets. home and siteurl may differ for intentional subdirectory installs.
Compare WordPress core files to official checksums for the selected installation.
wp --path=/srv/demo-wordpress core verify-checksumsPractical useCheck staging core integrity as one maintenance signal.
Common mistakesThis does not verify database contents or all themes/plugins, and does not prove a site is uncompromised. Network access is required.
Test cron spawning and list scheduled hooks without forcing them to run.
wp --path=/srv/demo-wordpress cron test
wp --path=/srv/demo-wordpress cron event listPractical useInspect a demo schedule before enabling email-related work.
Common mistakesA cron test is not proof every event succeeds. Running due events can send emails or trigger other side effects.
Source: developer.wordpress.org documentation (1) · developer.wordpress.org documentation (2)
Export WordPress’s configured database to a private absolute path outside the web root.
⚠ Caution: May overwrite the named dump file; the export contains private database data.
wp --path=/srv/demo-wordpress db export /srv/demo-backups/wordpress-demo.sqlPractical useMake a private staging backup before a planned change.
Common mistakesThe backup directory must exist and be private. A database dump contains sensitive data; media and files need separate backups. Test restore on staging.
Preview a URL replacement in WordPress tables without saving changes; handle serialized values through WP-CLI.
⚠ Caution: The shown dry run does not write changes. Removing --dry-run changes database contents.
wp --path=/srv/demo-wordpress search-replace 'https://old.example.com' 'https://demo.example.com' --skip-columns=guid --dry-runPractical useRehearse a staging site migration.
Common mistakesRemoving --dry-run writes data. Back up first, verify table scope, and do not blindly use --all-tables on a shared database.
On staging, update one example plugin after a tested backup, then check the site. The example slug must be replaced with an installed plugin.
⚠ Caution: Changes plugin files and may affect availability or database structure.
wp --path=/srv/demo-wordpress plugin update example-plugin
wp --path=/srv/demo-wordpress plugin listPractical useValidate a selected plugin update before live maintenance.
Common mistakesCheck release compatibility and test important flows. Updates can execute plugin code and change database schemas; avoid an unreviewed update --all.
Request deletion of one selected demo post. An untrashed post normally goes to Trash when WordPress Trash is enabled.
⚠ Caution: Removes the selected post. May permanently delete it if already trashed, Trash is disabled, or --force is used.
wp --path=/srv/demo-wordpress post get 123 --fields=ID,post_title,post_status
wp --path=/srv/demo-wordpress post delete 123Practical usePractice cleanup of an explicitly disposable test post.
Common mistakesInspect the target ID and status first. Already-trashed posts, or disabled Trash, can cause permanent deletion even without --force. A backup is required for recovery.
Source: developer.wordpress.org documentation (1) · developer.wordpress.org documentation (2)