From wordpress-expert
Audits WordPress HTTPS/SSL config: checks siteurl/home URL schemes and FORCE_SSL_ADMIN via WP-CLI (if available), scans PHP/JS files for hardcoded http:// mixed-content URLs.
How this skill is triggered — by the user, by Claude, or both
Slash command
/wordpress-expert:diagnostic-https-auditThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
You audit a WordPress site's HTTPS configuration to detect mixed content risks, unforced SSL on the admin panel, and hardcoded non-HTTPS URLs in code.
You audit a WordPress site's HTTPS configuration to detect mixed content risks, unforced SSL on the admin panel, and hardcoded non-HTTPS URLs in code.
HTTPS misconfigurations create several risks:
This skill has two independently-gated sections:
WP_CLI_AVAILABLE=true. Reads live WordPress configuration values from the database.LOCAL_PATH set. Scans synced PHP and JS files for hardcoded http:// URLs.This skill is NOT in the WP_CLI_SKILLS array — it manages its own gating internally because Part B runs independently of WP-CLI availability.
SITE_NAME="${1:-default-site}"
PROFILE=$(jq -r ".sites[\"$SITE_NAME\"]" sites.json)
HOST=$(echo "$PROFILE" | jq -r '.host // empty')
USER=$(echo "$PROFILE" | jq -r '.user // empty')
WP_PATH=$(echo "$PROFILE" | jq -r '.wp_path // empty')
LOCAL_PATH=$(echo "$PROFILE" | jq -r '.local_path // empty')
SOURCE_TYPE=$(echo "$PROFILE" | jq -r '.source_type // "ssh"')
WP_CLI_AVAILABLE=$(echo "$PROFILE" | jq -r '.wp_cli_available // "false"')
WP_CLI_PREFIX=$(echo "$PROFILE" | jq -r '.wp_cli_prefix // empty')
if [ "$WP_CLI_AVAILABLE" == "true" ]; then
Risk: If siteurl is http://, WordPress serves pages over HTTP, defeating SSL even if the server has a certificate.
SITEURL=$($WP_CLI_PREFIX option get siteurl 2>/dev/null | tr -d '[:space:]')
If siteurl starts with http://: Generate Warning finding INFR-HTTPS-URL.
Finding:
{
"id": "INFR-HTTPS-URL",
"severity": "Warning",
"category": "Infrastructure",
"title": "WordPress URL not configured for HTTPS",
"summary": "The WordPress site URL and/or home URL are set to http://, which means the site serves pages over unencrypted HTTP even if an SSL certificate is installed",
"detail": "The WordPress 'siteurl' option is set to: {SITEURL}. {HOME_URL_DETAIL} WordPress uses these values to generate all page URLs, asset references, and redirects. When set to http://, the site will not use HTTPS even if the server has a valid SSL certificate. This causes: (1) User data transmitted unencrypted, (2) Mixed content warnings if any assets reference https://, (3) Modern browsers flagging the site as 'Not Secure'. The fix requires updating these values in WordPress settings or wp-config.php.",
"location": "WordPress database options: siteurl, home",
"fix": "Update the WordPress URLs to HTTPS: In WordPress Admin go to Settings > General and change both 'WordPress Address (URL)' and 'Site Address (URL)' from http:// to https://. Alternatively via WP-CLI: `wp option update siteurl 'https://yourdomain.com'` and `wp option update home 'https://yourdomain.com'`. Ensure your SSL certificate is valid before making this change. After updating, test that the site loads correctly at the https:// URL."
}
Risk: Same as siteurl — both values must use https:// for complete HTTPS configuration.
HOME_URL=$($WP_CLI_PREFIX option get home 2>/dev/null | tr -d '[:space:]')
Evaluation: If both siteurl and home URL are http://, include both URLs in the INFR-HTTPS-URL finding detail field (combine into a single finding rather than emitting two). If only home URL is http://, still use INFR-HTTPS-URL but update detail to reference home URL specifically.
The {HOME_URL_DETAIL} placeholder in the finding above should be replaced with:
"The 'home' option is also set to: {HOME_URL}.""" (omit)Risk: Without FORCE_SSL_ADMIN, WordPress admin login and session cookies can be transmitted over HTTP, even when siteurl uses HTTPS.
FORCE_SSL_ADMIN=$($WP_CLI_PREFIX config get FORCE_SSL_ADMIN 2>/dev/null | tr -d '[:space:]')
If FORCE_SSL_ADMIN is not set, empty string, "false", or "0": Generate Info finding INFR-HTTPS-SSL.
Finding:
{
"id": "INFR-HTTPS-SSL",
"severity": "Info",
"category": "Infrastructure",
"title": "FORCE_SSL_ADMIN not enabled",
"summary": "The WordPress admin panel does not explicitly force HTTPS connections, which may allow admin credentials to be transmitted over HTTP",
"detail": "The FORCE_SSL_ADMIN constant is not set to true in wp-config.php (current value: {FORCE_SSL_ADMIN_VALUE}). This constant forces WordPress to redirect all admin panel requests to HTTPS, ensuring login credentials and session cookies are never transmitted over unencrypted HTTP. Without it, if a user manually navigates to http://yourdomain.com/wp-admin/, their credentials may be sent unencrypted. Note: If your server already enforces HTTPS via redirect (e.g., .htaccess or server config), this is a belt-and-suspenders measure — still recommended for defense in depth.",
"location": "wp-config.php (FORCE_SSL_ADMIN constant)",
"fix": "Add the following line to wp-config.php before the '/* That\\'s all, stop editing! */' comment: `define('FORCE_SSL_ADMIN', true);` This forces all WordPress admin panel requests to use HTTPS, protecting login credentials even if server-level HTTPS enforcement is misconfigured."
}
else
echo "INFO: WP-CLI config checks skipped — source type does not support WP-CLI. Mixed content code scan ran on local files."
fi
When WP_CLI_AVAILABLE=false, include this note in the findings output but do not generate a finding for it — it is context for the analyst, not a site issue.
This section runs independently of WP-CLI availability. It requires only that LOCAL_PATH is set (i.e., the codebase has been synced locally).
if [ -n "$LOCAL_PATH" ] && [ -d "$LOCAL_PATH" ]; then
Scans all PHP and JS files for hardcoded http:// references that would cause mixed content when the site runs over HTTPS.
HTTP_MATCHES=$(grep -rn \
--include="*.php" --include="*.js" \
--exclude-dir=".git" --exclude-dir="node_modules" --exclude-dir="vendor" \
"http://[a-zA-Z0-9][a-zA-Z0-9.-]*\." \
"$LOCAL_PATH/" 2>/dev/null | \
grep -v "^\s*[*/#]" | \
grep -v "localhost\|127\.0\.0\." | \
grep -v "example\.com\|example\.org\|example\.net" | \
grep -v "php\.net\|wordpress\.org\|w3\.org\|ietf\.org" | \
grep -v "http://schemas\.\|http://www\.w3\." | \
head -50)
HTTP_COUNT=$(echo "$HTTP_MATCHES" | grep -c "." 2>/dev/null || echo 0)
False-positive filters applied:
*, #, /) — documentation stringslocalhost and 127.0.0.x — local development referencesexample.com, example.org, example.net — placeholder/documentation domainsphp.net, wordpress.org, w3.org, ietf.org — official documentation linkshttp://schemas. and http://www.w3. — XML namespace declarations (not real URLs)If count > 0: Generate Warning finding INFR-HTTPS-MXD.
Extract the first 5 file:line examples:
EXAMPLES=$(echo "$HTTP_MATCHES" | head -5 | sed "s|$LOCAL_PATH/||")
Finding:
{
"id": "INFR-HTTPS-MXD",
"severity": "Warning",
"category": "Infrastructure",
"title": "Hardcoded http:// URLs found in PHP/JS files",
"summary": "Found {HTTP_COUNT} hardcoded http:// URL references in theme or plugin code that will cause mixed content warnings on HTTPS sites",
"detail": "Code scan of {LOCAL_PATH} found {HTTP_COUNT} non-comment lines containing hardcoded http:// URLs (excluding localhost, documentation sites, and XML namespaces). These URLs will cause mixed content warnings or errors in modern browsers when the site runs over HTTPS. First 5 examples:\n{EXAMPLES}\n\nMixed content issues can cause: (1) Browser security warnings that erode user trust, (2) Blocked resources (scripts/styles) in strict browser security modes, (3) Broken functionality in browser extensions that enforce HTTPS-only. Note: Not all matches may be actively loaded URLs — review each occurrence to confirm it is a runtime-loaded resource.",
"location": "Local codebase ({LOCAL_PATH}), {HTTP_COUNT} occurrences in PHP/JS files",
"fix": "For each hardcoded http:// URL found: (1) If referencing your own domain — update to https:// or use a protocol-relative URL (//yourdomain.com/path) which inherits the page's scheme. (2) If referencing a CDN or third-party — check if they support HTTPS (most do) and update to https://. (3) If using WordPress asset functions, use `plugins_url()`, `get_template_directory_uri()`, or `content_url()` which automatically use the correct scheme based on WordPress configuration. Run the grep command again after fixes to confirm all instances resolved."
}
If count = 0: No INFR-HTTPS-MXD finding is emitted. Proceed to overall status evaluation.
fi
If no issues were found across both Part A and Part B (siteurl is https://, home URL is https://, FORCE_SSL_ADMIN is true, and no http:// code references), emit a single Info finding:
Finding:
{
"id": "INFR-HTTPS-OK",
"severity": "Info",
"category": "Infrastructure",
"title": "HTTPS configuration healthy",
"summary": "WordPress URLs use HTTPS, FORCE_SSL_ADMIN is enabled, and no hardcoded http:// URLs found in PHP/JS files",
"detail": "All HTTPS configuration checks passed: (1) WordPress siteurl option uses https://, (2) WordPress home option uses https://, (3) FORCE_SSL_ADMIN is set to true in wp-config.php, (4) No hardcoded http:// URLs found in PHP/JS codebase (after filtering documentation and localhost references). The site's HTTPS configuration appears correctly set up.",
"location": "WordPress configuration and codebase",
"fix": "No action required — HTTPS configuration is healthy."
}
Note: INFR-HTTPS-OK is only emitted when WP-CLI checks ran AND code grep ran and both passed. If WP-CLI was unavailable (Part A skipped), do not emit INFR-HTTPS-OK even if Part B was clean — partial checks cannot confirm full HTTPS health.
| ID | Severity | Trigger |
|---|---|---|
| INFR-HTTPS-URL | Warning | siteurl or home URL uses http:// scheme |
| INFR-HTTPS-SSL | Info | FORCE_SSL_ADMIN not set or false |
| INFR-HTTPS-MXD | Warning | Hardcoded http:// URLs found in PHP/JS files |
| INFR-HTTPS-OK | Info | All checks pass — HTTPS configuration healthy |
Return a JSON array of findings. Each triggered check generates one finding. If all checks pass, return [INFR-HTTPS-OK] finding. If WP-CLI unavailable and code grep clean, return [].
Example output (http:// site URLs, no code issues):
[
{
"id": "INFR-HTTPS-URL",
"severity": "Warning",
"category": "Infrastructure",
"title": "WordPress URL not configured for HTTPS",
"summary": "The WordPress site URL and home URL are set to http://, which means the site serves pages over unencrypted HTTP",
"detail": "The WordPress 'siteurl' option is set to: http://example.com. The 'home' option is also set to: http://example.com.",
"location": "WordPress database options: siteurl, home",
"fix": "Update siteurl and home options to https:// via WordPress Admin Settings > General or WP-CLI."
},
{
"id": "INFR-HTTPS-SSL",
"severity": "Info",
"category": "Infrastructure",
"title": "FORCE_SSL_ADMIN not enabled",
"summary": "The WordPress admin panel does not explicitly force HTTPS connections",
"detail": "The FORCE_SSL_ADMIN constant is not set to true in wp-config.php (current value: not set).",
"location": "wp-config.php (FORCE_SSL_ADMIN constant)",
"fix": "Add `define('FORCE_SSL_ADMIN', true);` to wp-config.php."
}
]
Example output (all checks pass):
[
{
"id": "INFR-HTTPS-OK",
"severity": "Info",
"category": "Infrastructure",
"title": "HTTPS configuration healthy",
"summary": "WordPress URLs use HTTPS, FORCE_SSL_ADMIN is enabled, and no hardcoded http:// URLs found in PHP/JS files",
"detail": "All HTTPS configuration checks passed.",
"location": "WordPress configuration and codebase",
"fix": "No action required."
}
]
WP_CLI_SKILLS array in /diagnose or /investigate commands//domain.com/path) are NOT flagged — they correctly inherit the page schemenpx claudepluginhub dr-robert-li/cowork-wordpress-expertChecks WordPress wp-config.php remotely via SSH for critical security misconfigurations: WP_DEBUG enabled, default salts, missing DISALLOW_FILE_EDIT, database credentials exposure.
Runs OWASP Top 10 security audits with configurable depth, scope, and output formats. Supports Drupal and WordPress codebases.
Scans deployed websites for outdated frontend libraries, CMS platforms, known CVEs, and security headers like CSP and HSTS without source code access. Interactive URL and scope selection.