DirectAdmin WordPress Manager and wp-cli: Site Control

DirectAdmin’s WordPress Manager is included in every current licence and lives in the Evolution skin at User Level. It installs WordPress into a chosen document root, tracks each site it knows about, and offers one-click updates, password resets, cloning and debug toggles. It is not a replacement for wp-cli, but the two work well together: the panel gives customers a safe surface, and wp-cli gives engineers a scriptable one. This guide shows how to use both on a current build.

Short answer: Let customers install, update, clone and scan sites from User Level → WordPress Manager, and use wp-cli (enabled with da build set wpcli yes or installed as a phar) as the site owner for scripted work such as bulk updates, search-replace and verify-checksums. The wordpress_*_pre.sh and wordpress_*_post.sh hooks under scripts/custom/ added in 1.687 let the server enforce house rules on every install the manager performs.

Installing and registering sites

Open User Level → WordPress Manager and choose Install. Pick the domain or subdomain, an optional subdirectory, the admin username and email, and the site title. The manager creates the database and user, downloads the current WordPress release and writes wp-config.php with a random set of salts. It also stores a record of the installation so it appears in the list with its version and update state.

Sites installed before the manager existed, or by hand over SFTP, are not listed until they are registered. Use Scan to search the account’s document roots for wp-config.php files and add them. The scan reads the config file to find the database, so a site whose config lives one directory above the document root is still picked up.

Administrators do not get a fleet view by default; the manager is per user. To see every WordPress installation on the server, loop over accounts with wp-cli or check the WordPress-related counts in the admin resource pages.

Installing wp-cli

Recent CustomBuild versions ship wp-cli as an option. Check whether it is present and enable it if not:

da build options | grep -i wp
da build set wpcli yes
da build wpcli
which wp

If the option name differs on your build, install the phar to /usr/local/bin/wp and make it executable. Either way, run wp-cli as the site owner, never as root, so file ownership stays correct:

su -s /bin/bash - siteuser -c "wp --path=/home/siteuser/domains/example.com/public_html core version"

Every command below assumes that pattern or an equivalent sudo -u siteuser.

Everyday tasks from both sides

Updates are the most common job. The manager exposes core, plugin and theme updates per site, and 1.687 added hooks so the server can react to manager actions. The hook scripts live in /usr/local/directadmin/scripts/custom/ with names of the form wordpress_*_pre.sh and wordpress_*_post.sh; check the changelog for your build for the full list, because the set grew after the first release. A post-install hook is a good place to enforce house rules, for example installing a security plugin and disabling file editing:

#!/bin/sh
cd "$docroot" || exit 0
sudo -u "$username" wp config set DISALLOW_FILE_EDIT true --raw
sudo -u "$username" wp plugin install wordfence --activate

From the shell, bulk updates across an account look like this:

wp core update && wp plugin update --all && wp theme update --all && wp core update-db

For cloning to a staging subdomain, the manager copies files and database and rewrites the site URL. The wp-cli equivalent is wp db export, wp db import and wp search-replace old.example.com staging.example.com --all-tables, which is worth knowing when a site is too large for the panel’s request timeout.

Keeping wp-cron honest

Shared servers suffer when every page view fires wp-cron.php. Disable the pseudo-cron in wp-config.php and run it from a real cron entry:

wp config set DISABLE_WP_CRON true --raw

Then add a per-user cron job in the panel that runs wp cron event run --due-now every five to ten minutes. This keeps scheduled posts and update checks working without tying them to traffic.

Common pitfall: PHP version mismatch

The manager installs with the domain’s selected PHP version, but wp-cli uses whichever php binary is first in the path, usually the default CustomBuild version. When a plugin requires PHP 8.2 or later and the shell default is older, wp-cli fails with a syntax error that never appears in the browser. Fix it by calling the specific interpreter:

/usr/local/php84/bin/php /usr/local/bin/wp plugin list

Or set a per-user alias. See PHP versions and extensions with CustomBuild for the version layout.

Verify

After an install or update, confirm the site loads and the manager and wp-cli agree on the state:

curl -sI https://example.com/ | head -1
wp core verify-checksums
wp plugin list --update=available

verify-checksums catches modified core files, which is also the fastest first check when a customer reports a compromised site. If the manager shows a site as unknown version while wp-cli reports normally, run Scan again; the record is stale rather than the site broken. For servers that also run Imunify, the WordPress WAF rules described in Installing Imunify360 on DirectAdmin complement the hardening done here.

DirectAdmin WordPress Manager at a glance

Official documentation: WordPress advanced administration handbook, DirectAdmin documentation, Linux man pages.

Related guides: Using the da CLI: da update, da build, da config-set, da user and update channels · DirectAdmin removed legacy API endpoints in 2025–2026: what they were and their /api/ replacements · Broken custom Apache/nginx templates after the DOCROOT token change in DirectAdmin 1.710.

Frequently asked questions