Professional logging transforms opaque scripts into transparent, debuggable systems. Track every operation, capture errors with context, monitor script health, and diagnose failures instantly with comprehensive logs that tell the complete story.

In this guide, you’ll learn professional logging and debugging techniques for WP-CLI automation scripts, from basic logging to advanced monitoring systems used by DevOps teams managing critical WordPress infrastructure.

Why Logging Matters for Automation Scripts

Bash scripting without logging is like driving blindfolded—you don’t know what’s happening until something crashes.

Problems Without Proper Logging

Silent failures: Scripts fail without leaving any trace of what went wrong.

No audit trail: Can’t verify what scripts did or when they ran.

Difficult debugging: Recreating issues requires guessing and trial-and-error.

No monitoring: Can’t track script health or detect degrading performance.

Compliance issues: Can’t prove what operations were performed when.

Professional Logging Benefits

Instant diagnosis: Know exactly what failed and why from log messages.

Complete audit trail: Track every operation for compliance and debugging.

Proactive monitoring: Detect issues before they become critical failures.

Performance tracking: Identify bottlenecks and optimization opportunities.

Team collaboration: Share logs for troubleshooting across teams.

According to DevOps best practices, comprehensive logging reduces mean time to recovery (MTTR) by 80%.

Basic Logging Implementation

Start with fundamental logging patterns for WP-CLI scripts.

Simple Log Function

#!/bin/bash
# basic-logging.sh

LOG_FILE="/var/log/wp-automation.log"

log() {
    echo "[$(date '+%Y-%m-%d %H:%M:%S')] $@" | tee -a "$LOG_FILE"
}

# Usage
log "Script started"
log "Updating WordPress plugins..."

wp plugin update --all

if [ $? -eq 0 ]; then
    log "✓ Plugins updated successfully"
else
    log "✗ Plugin update failed"
fi

log "Script completed"

Key Elements:

• Timestamp for every log entry
• tee outputs to both terminal and file
• Exit codes checked and logged

Logging Command Output

#!/bin/bash

LOG_FILE="/var/log/wp-updates.log"

log() {
    echo "[$(date '+%Y-%m-%d %H:%M:%S')] $@" | tee -a "$LOG_FILE"
}

log "Starting WordPress update"

# Capture command output and log it
OUTPUT=$(wp core update 2>&1)
EXIT_CODE=$?

echo "$OUTPUT" >> "$LOG_FILE"

if [ $EXIT_CODE -eq 0 ]; then
    log "✓ WordPress updated successfully"
else
    log "✗ WordPress update failed with exit code $EXIT_CODE"
    log "Output: $OUTPUT"
fi

Learn about Bash redirection for capturing output.

Log Levels and Structured Logging

Implement professional log levels for better organization.

Multi-Level Logging System

#!/bin/bash
# logging-levels.sh

LOG_FILE="/var/log/wp-automation.log"
LOG_LEVEL="${LOG_LEVEL:-INFO}"  # Default to INFO

# Log level hierarchy: DEBUG < INFO < WARN < ERROR
declare -A LOG_LEVELS=([DEBUG]=0 [INFO]=1 [WARN]=2 [ERROR]=3)

log() {
    local level="$1"
    shift
    local message="$@"
    local timestamp=$(date '+%Y-%m-%d %H:%M:%S')

    # Check if we should log this level
    if [ "${LOG_LEVELS[$level]}" -ge "${LOG_LEVELS[$LOG_LEVEL]}" ]; then
        echo "[$timestamp] [$level] $message" | tee -a "$LOG_FILE"
    fi
}

log_debug() { log DEBUG "$@"; }
log_info() { log INFO "$@"; }
log_warn() { log WARN "$@"; }
log_error() { log ERROR "$@"; }

# Usage examples
log_debug "Starting database backup process"
log_info "Backing up WordPress database"
log_warn "Database size exceeds 1GB, this may take a while"
log_error "Database backup failed: disk full"

Structured Log Format

#!/bin/bash
# structured-logging.sh

log_structured() {
    local level="$1"
    local component="$2"
    local action="$3"
    shift 3
    local message="$@"

    local timestamp=$(date '+%Y-%m-%d %H:%M:%S')
    local hostname=$(hostname)

    # JSON-like format for easy parsing
    echo "{\"timestamp\":\"$timestamp\",\"level\":\"$level\",\"host\":\"$hostname\",\"component\":\"$component\",\"action\":\"$action\",\"message\":\"$message\"}" >> "$LOG_FILE"

    # Human-readable format for terminal
    echo "[$timestamp] [$level] [$component] $action: $message"
}

# Usage
log_structured INFO "wordpress" "plugin-update" "Updating all plugins"
log_structured ERROR "database" "backup" "Failed to create backup: Permission denied"

Debugging Techniques

Advanced debugging patterns for troubleshooting scripts.

Bash Debug Mode

#!/bin/bash

# Enable debug mode with -x flag
set -x  # Print each command before executing

# Or use for specific sections
{
    set -x
    wp plugin update --all
    wp theme update --all
    set +x
} 2>&1 | tee -a debug.log

# Verbose WP-CLI output
wp --debug plugin list

Function Tracing

#!/bin/bash

# Enable function call tracing
set -o functrace

# Trace function for debugging
trace() {
    echo "[TRACE] Function: ${FUNCNAME[1]}, Line: ${BASH_LINENO[0]}" >> trace.log
}

backup_database() {
    trace
    log_info "Starting database backup"
    wp db export backup.sql.gz
}

update_plugins() {
    trace
    log_info "Updating plugins"
    wp plugin update --all
}

# Call functions
backup_database
update_plugins

Variable State Logging

#!/bin/bash

log_var() {
    local var_name="$1"
    local var_value="${!var_name}"
    log_debug "Variable $var_name = '$var_value'"
}

# Usage
BACKUP_DIR="/backups"
SITE_URL="https://example.com"
PLUGIN_COUNT=$(wp plugin list --format=count)

log_var BACKUP_DIR
log_var SITE_URL
log_var PLUGIN_COUNT

Learn about Bash debugging techniques.

Error Context and Stack Traces

Capture comprehensive error information for debugging.

Error Handler with Context

#!/bin/bash
set -euo pipefail

LOG_FILE="/var/log/wp-errors.log"

error_handler() {
    local exit_code=$?
    local line_number=$1
    local bash_lineno=${BASH_LINENO[0]}
    local function_name=${FUNCNAME[1]:-main}
    local command="${BASH_COMMAND}"

    {
        echo "=========================================="
        echo "ERROR OCCURRED"
        echo "=========================================="
        echo "Timestamp: $(date '+%Y-%m-%d %H:%M:%S')"
        echo "Exit Code: $exit_code"
        echo "Line Number: $line_number"
        echo "Function: $function_name"
        echo "Command: $command"
        echo "Script: $0"
        echo "Working Directory: $(pwd)"
        echo "User: $(whoami)"
        echo "Hostname: $(hostname)"
        echo "=========================================="
    } | tee -a "$LOG_FILE"

    # Capture environment state
    echo "Environment Variables:" >> "$LOG_FILE"
    env >> "$LOG_FILE"

    exit $exit_code
}

trap 'error_handler ${LINENO}' ERR

# Script operations that might fail
wp db export backup.sql.gz
wp plugin update --all

Stack Trace Function

#!/bin/bash

print_stack_trace() {
    local frame=0
    echo "Stack Trace:" >&2

    while caller $frame; do
        ((frame++))
    done | while read line func file; do
        echo "  at $func ($file:$line)" >&2
    done
}

error_with_trace() {
    echo "ERROR: $@" >&2
    print_stack_trace
}

# Usage
backup_db() {
    if ! wp db export backup.sql.gz; then
        error_with_trace "Database backup failed"
        return 1
    fi
}

Log Rotation and Management

Prevent logs from consuming all disk space.

Manual Log Rotation

#!/bin/bash
# rotate-logs.sh - Rotate log files

LOG_FILE="/var/log/wp-automation.log"
MAX_SIZE_MB=10
KEEP_DAYS=30

# Check log file size
if [ -f "$LOG_FILE" ]; then
    FILE_SIZE=$(du -m "$LOG_FILE" | cut -f1)

    if [ "$FILE_SIZE" -gt "$MAX_SIZE_MB" ]; then
        echo "Rotating log file (${FILE_SIZE}MB)"

        # Archive with timestamp
        ARCHIVE="${LOG_FILE}.$(date +%Y%m%d-%H%M%S).gz"
        gzip -c "$LOG_FILE" > "$ARCHIVE"

        # Clear current log
        > "$LOG_FILE"

        echo "Log rotated to: $ARCHIVE"
    fi
fi

# Delete old archives
find "$(dirname $LOG_FILE)" -name "$(basename $LOG_FILE).*.gz" -mtime +$KEEP_DAYS -delete

Using logrotate

# /etc/logrotate.d/wp-automation

/var/log/wp-automation.log {
    daily
    rotate 7
    compress
    delaycompress
    missingok
    notifempty
    create 0640 www-data www-data
    sharedscripts
    postrotate
        # Optional: restart service if needed
    endscript
}

Learn about logrotate configuration.

Performance and Timing Logs

Track script performance and identify bottlenecks.

Execution Time Logging

#!/bin/bash

log_timed() {
    local description="$1"
    shift
    local command="$@"

    log_info "Starting: $description"
    local start_time=$(date +%s)

    # Execute command
    eval "$command"
    local exit_code=$?

    local end_time=$(date +%s)
    local duration=$((end_time - start_time))

    if [ $exit_code -eq 0 ]; then
        log_info "✓ Completed: $description (${duration}s)"
    else
        log_error "✗ Failed: $description (${duration}s, exit code: $exit_code)"
    fi

    return $exit_code
}

# Usage
log_timed "Database export" "wp db export backup.sql.gz"
log_timed "Plugin updates" "wp plugin update --all"
log_timed "Cache flush" "wp cache flush"

Performance Benchmarking

#!/bin/bash

benchmark() {
    local operation="$1"
    local iterations="${2:-10}"

    log_info "Benchmarking: $operation ($iterations iterations)"

    local total_time=0

    for i in $(seq 1 $iterations); do
        local start=$(date +%s%N)
        eval "$operation" >/dev/null 2>&1
        local end=$(date +%s%N)

        local duration=$(( (end - start) / 1000000 ))  # Convert to milliseconds
        total_time=$((total_time + duration))
    done

    local avg_time=$((total_time / iterations))

    log_info "Benchmark results: ${avg_time}ms average (${iterations} runs)"
}

# Usage
benchmark "wp option get siteurl" 5

Log Aggregation and Analysis

Analyze logs for insights and troubleshooting.

Log Analysis Scripts

#!/bin/bash
# analyze-logs.sh - Extract insights from logs

LOG_FILE="/var/log/wp-automation.log"

echo "WordPress Automation Log Analysis"
echo "=================================="
echo ""

# Count log levels
echo "Log Levels:"
echo "  ERROR:   $(grep -c '\[ERROR\]' "$LOG_FILE")"
echo "  WARN:    $(grep -c '\[WARN\]' "$LOG_FILE")"
echo "  INFO:    $(grep -c '\[INFO\]' "$LOG_FILE")"
echo ""

# Recent errors
echo "Recent Errors (last 10):"
grep '\[ERROR\]' "$LOG_FILE" | tail -10
echo ""

# Most common operations
echo "Most Frequent Operations:"
grep -oP '(?<=\] ).*?(?=:)' "$LOG_FILE" | sort | uniq -c | sort -rn | head -10
echo ""

# Script execution times
echo "Average Execution Times:"
grep -oP 'Completed.*?\(\K[0-9]+(?=s\))' "$LOG_FILE" | awk '{sum+=$1; count++} END {print "Average: " sum/count "s"}'

Error Report Generation

#!/bin/bash
# generate-error-report.sh

LOG_FILE="/var/log/wp-automation.log"
REPORT_FILE="/tmp/error-report-$(date +%Y%m%d).txt"
EMAIL="admin@example.com"

{
    echo "WordPress Automation Error Report"
    echo "Generated: $(date)"
    echo "=================================="
    echo ""

    # Errors in last 24 hours
    echo "Errors in Last 24 Hours:"
    grep '\[ERROR\]' "$LOG_FILE" | grep "$(date +%Y-%m-%d)" | nl
    echo ""

    # Failed operations
    echo "Failed Operations:"
    grep '✗ Failed' "$LOG_FILE" | tail -20
    echo ""

    # Critical errors
    echo "Critical Issues:"
    grep -i 'critical\|fatal\|emergency' "$LOG_FILE" | tail -10

} > "$REPORT_FILE"

# Email report if errors found
ERROR_COUNT=$(grep -c '\[ERROR\]' "$LOG_FILE" || true)
if [ "$ERROR_COUNT" -gt 0 ]; then
    mail -s "WordPress Automation Errors: $ERROR_COUNT found" "$EMAIL" < "$REPORT_FILE"
fi

Centralized Logging Systems

Send logs to centralized logging platforms.

Syslog Integration

#!/bin/bash

# Log to both file and syslog
log_to_syslog() {
    local level="$1"
    shift
    local message="$@"

    # Map to syslog levels
    case "$level" in
        ERROR) priority="err" ;;
        WARN)  priority="warning" ;;
        INFO)  priority="info" ;;
        DEBUG) priority="debug" ;;
        *) priority="notice" ;;
    esac

    # Log to file
    echo "[$(date '+%Y-%m-%d %H:%M:%S')] [$level] $message" >> "$LOG_FILE"

    # Log to syslog
    logger -t "wp-automation" -p "user.${priority}" "$message"
}

# Usage
log_to_syslog INFO "Starting WordPress backup"
log_to_syslog ERROR "Backup failed: disk full"

JSON Logging for Parsing

#!/bin/bash

log_json() {
    local level="$1"
    shift
    local message="$@"

    local json=$(cat <<EOF
{
  "timestamp": "$(date -u +%Y-%m-%dT%H:%M:%SZ)",
  "level": "$level",
  "service": "wp-automation",
  "hostname": "$(hostname)",
  "message": "$message",
  "script": "$0",
  "pid": $
}
EOF
)

    echo "$json" >> /var/log/wp-automation.json
}

# Usage
log_json "info" "WordPress backup started"
log_json "error" "Plugin update failed"

Next Steps

You now have professional logging and debugging skills for production-ready WP-CLI automation.

Recommended Learning Path

Week 1: Basic logging

• Implement log functions
• Add timestamps and levels
• Practice log file rotation

Week 2: Advanced debugging

• Use debug modes
• Add error handlers
• Capture stack traces

Week 3: Performance tracking

• Log execution times
• Benchmark operations
• Identify bottlenecks

Week 4: Production monitoring

• Set up log analysis
• Configure alerting
• Implement centralized logging

Advanced Topics

1. Distributed Tracing – Track operations across systems
2. Log Analytics – Advanced log parsing and insights
3. Monitoring Dashboards – Visualize log data

Get More Resources

Download logging templates including:

• Complete logging systems
• Analysis scripts
• Monitoring tools

Join our email course for:

• Weekly WP-CLI tutorials
• Debugging best practices
• DevOps logging strategies

Conclusion

Professional logging and debugging transform fragile WordPress automation scripts into transparent, maintainable systems that provide complete visibility into operations.

What we covered:

✅ Basic logging implementation with timestamps ✅ Multi-level logging systems (DEBUG, INFO, WARN, ERROR) ✅ Advanced debugging techniques and tracing ✅ Error context and stack trace capture ✅ Log rotation and management ✅ Performance tracking and analysis

Master these techniques, and you’ll never struggle to debug production scripts again—comprehensive logs tell you exactly what happened, when, and why.

Ready for more? Learn monitoring and alerting or production debugging workflows.

Questions about logging WP-CLI automation scripts? Drop a comment below!

Found this helpful? Share with other DevOps engineers.

The post Professional Logging and Debugging for WP-CLI Automation Scripts appeared first on WP-CLI Mastery.

Bash scripts without proper error handling are disasters waiting to happen. One unchecked exit code, one missing validation, and your automation becomes your biggest liability instead of your greatest asset.

In this guide, you’ll learn professional error handling techniques that prevent script failures, protect your data, and make WP-CLI automation scripts production-ready and bulletproof.

Why Error Handling Matters for WP-CLI Scripts

Bash scripting by default continues executing after errors occur, which is dangerous for WordPress operations.

Problems with Poor Error Handling

Silent failures: Scripts continue after failed database exports, creating incomplete backups.

Data corruption: Import scripts run on wrong databases because connection checks were skipped.

Partial operations: Plugin updates fail halfway through, leaving sites in broken states.

No recovery: Scripts can’t rollback or cleanup after failures.

Debugging nightmares: No logs or error messages make troubleshooting impossible.

Professional Error Handling Benefits

Early failure detection: Scripts stop immediately when errors occur.

Safe operations: Validate inputs and check preconditions before making changes.

Automatic cleanup: Trap errors and perform cleanup even during failures.

Detailed logging: Track exactly what failed and why for quick debugging.

Production-ready: Confidence to run scripts on live sites without supervision.

According to DevOps research, organizations with robust error handling in automation scripts experience 60% fewer outages.

Bash Error Handling Fundamentals

Master the core error handling mechanisms in Bash.

Exit Codes and $? Variable

# Every command returns exit code
# 0 = success, non-zero = failure

wp core version
echo $?  # Prints 0 if successful

wp plugin install nonexistent-plugin
echo $?  # Prints non-zero (1) if failed

# Check exit code immediately
if [ $? -eq 0 ]; then
    echo "Success"
else
    echo "Failed"
fi

Better: Check Exit Codes Inline

# Check command directly in if statement
if wp core is-installed; then
    echo "WordPress is installed"
else
    echo "WordPress not found"
    exit 1
fi

# Using && for success chaining
wp db export backup.sql && echo "Backup successful"

# Using || for failure handling
wp db export backup.sql || { echo "Backup failed!"; exit 1; }

Pro Tip: Always check exit codes for destructive operations like database imports, file deletions, or updates.

Set Error Handling Mode

#!/bin/bash

# Exit on any error
set -e

# Exit on undefined variables
set -u

# Pipe failures cause script failure
set -o pipefail

# Combined (recommended)
set -euo pipefail

# Now script exits automatically on errors
wp db export backup.sql  # Script exits if this fails
wp plugin update --all    # Never runs if above failed

Learn more about Bash set options.

Validation and Precondition Checking

Verify assumptions before executing dangerous operations.

Check File Existence

#!/bin/bash
set -euo pipefail

BACKUP_FILE="/backups/database.sql.gz"

# Check file exists before import
if [ ! -f "$BACKUP_FILE" ]; then
    echo "Error: Backup file not found: $BACKUP_FILE"
    exit 1
fi

# Verify file size (not empty)
FILE_SIZE=$(stat -c%s "$BACKUP_FILE")
if [ "$FILE_SIZE" -lt 1000 ]; then
    echo "Error: Backup file too small (${FILE_SIZE} bytes), may be corrupted"
    exit 1
fi

# Safe to import
wp db import "$BACKUP_FILE"

Validate WordPress Installation

#!/bin/bash
set -euo pipefail

# Check WordPress is installed
if ! wp core is-installed 2>/dev/null; then
    echo "Error: WordPress not installed in current directory"
    exit 1
fi

# Check database connection
if ! wp db check 2>/dev/null; then
    echo "Error: Database connection failed"
    exit 1
fi

echo "✓ WordPress installation validated"

Check Required Commands Exist

#!/bin/bash
set -euo pipefail

# Function to check command availability
check_command() {
    if ! command -v "$1" &> /dev/null; then
        echo "Error: Required command '$1' not found"
        echo "Install it with: apt-get install $1"
        exit 1
    fi
}

# Verify dependencies
check_command wp
check_command mysql
check_command gzip

echo "✓ All required commands available"

Error Trapping and Cleanup

Handle errors gracefully and cleanup resources even during failures.

Basic Trap Command

#!/bin/bash
set -euo pipefail

# Cleanup function
cleanup() {
    echo "Cleaning up temporary files..."
    rm -f /tmp/temp-backup-*.sql
    echo "Cleanup complete"
}

# Register cleanup to run on exit
trap cleanup EXIT

# Script continues normally
echo "Starting backup..."
wp db export /tmp/temp-backup-$(date +%s).sql.gz

# cleanup() runs automatically when script exits

Error-Specific Trap

#!/bin/bash
set -euo pipefail

# Error handler
error_handler() {
    local exit_code=$?
    local line_number=$1

    echo "ERROR: Script failed at line $line_number with exit code $exit_code"
    echo "Rolling back changes..."

    # Perform rollback operations
    wp db import /backups/before-update.sql.gz 2>/dev/null || true

    exit $exit_code
}

# Trap errors and call error_handler with line number
trap 'error_handler ${LINENO}' ERR

# Backup before changes
wp db export /backups/before-update.sql.gz

# Risky operation
wp plugin update --all

# If above fails, error_handler restores database

Use Case: Automatically restore database backups if update operations fail mid-process.

Advanced Trap with Multiple Signals

#!/bin/bash
set -euo pipefail

TEMP_DIR="/tmp/wp-deploy-$$"
BACKUP_FILE=""

# Comprehensive cleanup
cleanup() {
    local exit_code=$?

    if [ $exit_code -ne 0 ]; then
        echo "Script failed (exit code: $exit_code)"
        echo "Performing emergency cleanup..."
    fi

    # Remove temporary directory
    [ -d "$TEMP_DIR" ] && rm -rf "$TEMP_DIR"

    # Remove temporary backup
    [ -n "$BACKUP_FILE" ] && rm -f "$BACKUP_FILE"

    echo "Cleanup complete"
}

# Trap multiple signals
trap cleanup EXIT ERR INT TERM

# Create temp directory
mkdir -p "$TEMP_DIR"

# Store backup location
BACKUP_FILE="/tmp/backup-$$.sql.gz"

# Script operations...

Input Validation and Argument Parsing

Validate script arguments and user inputs before processing.

Validate Required Arguments

#!/bin/bash
set -euo pipefail

# Check argument count
if [ $# -lt 2 ]; then
    echo "Usage: $0 <source_url> <target_url>"
    echo "Example: $0 https://oldsite.com https://newsite.com"
    exit 1
fi

SOURCE_URL="$1"
TARGET_URL="$2"

# Validate URL format
if [[ ! "$SOURCE_URL" =~ ^https?:// ]]; then
    echo "Error: Source URL must start with http:// or https://"
    exit 1
fi

if [[ ! "$TARGET_URL" =~ ^https?:// ]]; then
    echo "Error: Target URL must start with http:// or https://"
    exit 1
fi

# Safe to proceed
wp search-replace "$SOURCE_URL" "$TARGET_URL"

Validate User Confirmation

#!/bin/bash
set -euo pipefail

echo "WARNING: This will delete all WordPress posts"
echo "This action cannot be undone!"
read -p "Type 'DELETE' to confirm: " CONFIRMATION

if [ "$CONFIRMATION" != "DELETE" ]; then
    echo "Operation cancelled"
    exit 0
fi

# User confirmed, proceed with deletion
wp post delete $(wp post list --format=ids) --force

Validate Numeric Inputs

#!/bin/bash
set -euo pipefail

DAYS_TO_KEEP="${1:-7}"

# Ensure input is a number
if ! [[ "$DAYS_TO_KEEP" =~ ^[0-9]+$ ]]; then
    echo "Error: Days must be a positive number"
    exit 1
fi

# Ensure reasonable range
if [ "$DAYS_TO_KEEP" -lt 1 ] || [ "$DAYS_TO_KEEP" -gt 365 ]; then
    echo "Error: Days must be between 1 and 365"
    exit 1
fi

# Delete old backups
find /backups -name "*.sql.gz" -mtime +$DAYS_TO_KEEP -delete

Logging and Error Reporting

Track script execution and failures with comprehensive logging.

Basic Logging Function

#!/bin/bash
set -euo pipefail

LOG_FILE="/var/log/wp-automation.log"

# Logging function
log() {
    local level="$1"
    shift
    local message="$@"
    local timestamp=$(date '+%Y-%m-%d %H:%M:%S')

    echo "[$timestamp] [$level] $message" | tee -a "$LOG_FILE"
}

# Usage
log INFO "Starting WordPress backup"
log WARNING "Database size is large, this may take a while"
log ERROR "Backup failed: disk full"

Log with Script Context

#!/bin/bash
set -euo pipefail

LOG_FILE="/var/log/wp-scripts.log"
SCRIPT_NAME=$(basename "$0")

log() {
    echo "[$(date '+%Y-%m-%d %H:%M:%S')] [$SCRIPT_NAME] $@" | tee -a "$LOG_FILE"
}

log "Script started"
log "Backing up database..."

if wp db export backup.sql.gz; then
    log "✓ Database backup successful"
else
    log "✗ Database backup failed"
    exit 1
fi

log "Script completed"

Email Notifications on Failure

#!/bin/bash
set -euo pipefail

ADMIN_EMAIL="admin@example.com"

# Error handler with email notification
error_notify() {
    local exit_code=$?
    local line_number=$1

    # Prepare error message
    ERROR_MSG="WordPress automation script failed

Script: $0
Line: $line_number
Exit Code: $exit_code
Time: $(date)
Server: $(hostname)

Please investigate immediately."

    # Log error
    echo "$ERROR_MSG" >> /var/log/wp-errors.log

    # Send email
    echo "$ERROR_MSG" | mail -s "ALERT: WordPress Script Failure" "$ADMIN_EMAIL"

    exit $exit_code
}

trap 'error_notify ${LINENO}' ERR

# Script operations...

Production-Ready Error Handling Patterns

Complete error handling templates for common WP-CLI operations.

Safe Database Migration Script

#!/bin/bash
set -euo pipefail

# Configuration
SOURCE_URL="https://staging.example.com"
TARGET_URL="https://production.example.com"
BACKUP_DIR="/backups/migrations"
LOG_FILE="/var/log/wp-migration.log"

# Logging
log() {
    echo "[$(date '+%Y-%m-%d %H:%M:%S')] $@" | tee -a "$LOG_FILE"
}

# Error handler
error_handler() {
    log "ERROR: Migration failed at line $1"
    log "Rolling back to previous state..."

    if [ -f "$ROLLBACK_BACKUP" ]; then
        wp db import "$ROLLBACK_BACKUP" && log "✓ Rollback successful"
    fi

    exit 1
}

trap 'error_handler ${LINENO}' ERR

# Start migration
log "=== WordPress Migration Started ==="

# Validate preconditions
log "Validating environment..."
wp core is-installed || { log "ERROR: WordPress not installed"; exit 1; }
wp db check || { log "ERROR: Database connection failed"; exit 1; }

# Create backup directory
mkdir -p "$BACKUP_DIR"

# Backup current state
log "Creating rollback backup..."
ROLLBACK_BACKUP="$BACKUP_DIR/rollback-$(date +%Y%m%d-%H%M%S).sql.gz"
wp db export "$ROLLBACK_BACKUP" || { log "ERROR: Backup failed"; exit 1; }
log "✓ Rollback backup created: $ROLLBACK_BACKUP"

# Verify backup
BACKUP_SIZE=$(stat -c%s "$ROLLBACK_BACKUP")
if [ "$BACKUP_SIZE" -lt 1000 ]; then
    log "ERROR: Backup file too small, aborting"
    exit 1
fi

# Perform search-replace (dry run first)
log "Testing URL replacement..."
if ! wp search-replace "$SOURCE_URL" "$TARGET_URL" --dry-run --report; then
    log "ERROR: Dry run failed"
    exit 1
fi

# Execute actual replacement
log "Executing URL replacement..."
wp search-replace "$SOURCE_URL" "$TARGET_URL" --report

# Verify replacement
REMAINING=$(wp search-replace "$SOURCE_URL" "$TARGET_URL" --dry-run --report | grep -c "$SOURCE_URL" || true)
if [ "$REMAINING" -gt 0 ]; then
    log "WARNING: Some URLs may not have been replaced"
fi

# Update WordPress options
log "Updating WordPress options..."
wp option update home "$TARGET_URL"
wp option update siteurl "$TARGET_URL"

# Clear caches
log "Clearing caches..."
wp cache flush
wp rewrite flush

log "=== Migration Completed Successfully ==="
log "Rollback backup available at: $ROLLBACK_BACKUP"

Safe Plugin Update with Fallback

#!/bin/bash
set -euo pipefail

BACKUP_FILE="/tmp/before-plugin-update-$$.sql.gz"

# Cleanup function
cleanup() {
    rm -f "$BACKUP_FILE"
}

trap cleanup EXIT

# Error handler
error_handler() {
    echo "ERROR: Plugin update failed, restoring backup..."

    if [ -f "$BACKUP_FILE" ]; then
        wp db import "$BACKUP_FILE" && echo "✓ Database restored"
    fi

    exit 1
}

trap error_handler ERR

# Backup database
echo "Creating safety backup..."
wp db export "$BACKUP_FILE"

# Check for available updates
UPDATES=$(wp plugin list --update=available --format=count)

if [ "$UPDATES" -eq 0 ]; then
    echo "No plugin updates available"
    exit 0
fi

echo "$UPDATES plugin(s) have updates available"

# Update plugins
echo "Updating plugins..."
wp plugin update --all

# Verify WordPress still works
echo "Verifying WordPress installation..."
wp core is-installed || error_handler

echo "✓ All plugins updated successfully"
echo "Backup file will be deleted on exit"

Next Steps

You now have professional error handling skills for WP-CLI Bash scripts.

Recommended Learning Path

Week 1: Basic error handling

• Implement exit code checking
• Add input validation
• Use set -euo pipefail

Week 2: Advanced trapping

• Create cleanup functions
• Implement error handlers
• Build rollback mechanisms

Week 3: Logging and monitoring

• Add comprehensive logging
• Set up email notifications
• Create error tracking

Week 4: Production hardening

• Review all scripts for error handling
• Create script templates
• Document recovery procedures

Advanced Topics

1. Bash Script Testing – Unit testing for Bash scripts
2. Monitoring and Alerting – Production script monitoring
3. Incident Response – Handling script failures in production

Get More Resources

Download error handling templates including:

• Production-ready script templates
• Error handling checklist
• Common error patterns

Join our email course for:

• Weekly WP-CLI tutorials
• Advanced scripting techniques
• DevOps best practices

Conclusion

Proper error handling transforms fragile scripts into production-ready automation that you can trust with critical WordPress operations.

What we covered:

✅ Exit codes and error detection fundamentals ✅ Validation and precondition checking ✅ Error trapping and automatic cleanup with trap ✅ Input validation and argument parsing ✅ Comprehensive logging and error reporting ✅ Production-ready error handling patterns

Master these techniques, and you’ll write WordPress automation scripts that gracefully handle failures, protect your data, and make debugging trivial.

Ready for more? Learn advanced Bash scripting patterns or WP-CLI script testing.

Questions about error handling in WP-CLI scripts? Drop a comment below!

Found this helpful? Share with other WordPress developers.

The post Bulletproof Error Handling in Bash Scripts for WP-CLI (Complete Guide) appeared first on WP-CLI Mastery.

Why Parse Arguments in WP-CLI Scripts?

Command line argument parsing enables your Bash scripts to accept dynamic input, making them adaptable to different scenarios without code modifications. Instead of hardcoding site URLs, environment types, or backup paths, you can pass these values as arguments when executing your scripts.

This approach brings several advantages: increased script reusability, reduced maintenance overhead, better error handling, and improved user experience. A well-designed script with proper argument parsing can serve multiple purposes across different WordPress installations.

Understanding Positional Parameters

The simplest form of argument parsing uses positional parameters. In Bash, arguments passed to a script are automatically assigned to special variables: $1 for the first argument, $2 for the second, and so on. The $0 variable contains the script name itself.

#!/bin/bash
# Simple WP-CLI backup script with positional parameters

SITE_PATH=$1
BACKUP_DIR=$2

wp --path="$SITE_PATH" db export "$BACKUP_DIR/database-$(date +%Y%m%d).sql"

Execute this script with: ./backup.sh /var/www/html /backups

While positional parameters work for simple cases, they have limitations. Users must remember the exact order of arguments, and the script offers no built-in way to handle optional parameters or provide helpful usage information.

Using getopts for Named Options

The getopts command provides a more sophisticated approach to argument parsing, allowing you to define named options with single-character flags. This method significantly improves script usability and maintainability.

#!/bin/bash
# WP-CLI deployment script with getopts

usage() {
    echo "Usage: $0 -p <path> -e <environment> [-b]"
    echo "  -p    WordPress installation path"
    echo "  -e    Environment (dev|staging|prod)"
    echo "  -b    Create backup before deployment"
    exit 1
}

BACKUP=false

while getopts "p:e:bh" opt; do
    case $opt in
        p) WP_PATH="$OPTARG" ;;
        e) ENVIRONMENT="$OPTARG" ;;
        b) BACKUP=true ;;
        h) usage ;;
        \?) echo "Invalid option: -$OPTARG" >&2; usage ;;
        :) echo "Option -$OPTARG requires an argument" >&2; usage ;;
    esac
done

# Validate required arguments
if [[ -z "$WP_PATH" ]] || [[ -z "$ENVIRONMENT" ]]; then
    echo "Error: Missing required arguments"
    usage
fi

# Script logic continues here
if [[ "$BACKUP" == true ]]; then
    wp --path="$WP_PATH" db export "backup-pre-deploy-$(date +%Y%m%d-%H%M%S).sql"
fi

In this example, options followed by a colon (like p: and e:) require arguments, while standalone letters (like b) act as flags. The OPTARG variable holds the value passed to options requiring arguments.

Advanced Argument Validation

Robust scripts validate input before processing. Argument validation prevents errors, protects against malicious input, and provides clear feedback when users make mistakes.

#!/bin/bash
# WP-CLI site migration script with validation

validate_path() {
    if [[ ! -d "$1" ]]; then
        echo "Error: Path '$1' does not exist"
        exit 1
    fi

    if [[ ! -f "$1/wp-config.php" ]]; then
        echo "Error: '$1' is not a WordPress installation"
        exit 1
    fi
}

validate_environment() {
    local env=$1
    case $env in
        dev|development|staging|production|prod)
            return 0
            ;;
        *)
            echo "Error: Invalid environment '$env'"
            echo "Allowed values: dev, staging, production"
            exit 1
            ;;
    esac
}

# After parsing arguments with getopts
validate_path "$WP_PATH"
validate_environment "$ENVIRONMENT"

Handling Long-Form Options

While getopts handles short options well, it doesn’t natively support long-form options like --path or --environment. For scripts requiring both short and long options, you can implement manual parsing:

#!/bin/bash

while [[ $# -gt 0 ]]; do
    case $1 in
        -p|--path)
            WP_PATH="$2"
            shift 2
            ;;
        -e|--environment)
            ENVIRONMENT="$2"
            shift 2
            ;;
        --dry-run)
            DRY_RUN=true
            shift
            ;;
        -h|--help)
            usage
            ;;
        *)
            echo "Unknown option: $1"
            usage
            ;;
    esac
done

The shift command removes processed arguments from the parameter list, allowing the loop to progress through all provided options.

Practical Example: Multi-Site Update Script

Here’s a complete example demonstrating argument parsing in a real-world WP-CLI script:

#!/bin/bash
# Update multiple WordPress sites with flexible options

set -euo pipefail

usage() {
    cat << EOF
Usage: $0 -s <sites> [OPTIONS]

Required:
    -s, --sites       Comma-separated list of site paths

Options:
    -c, --core        Update WordPress core
    -p, --plugins     Update plugins
    -t, --themes      Update themes
    -a, --all         Update everything
    --exclude-plugin  Plugin to exclude (can be used multiple times)
    --dry-run         Show what would be updated without making changes
    -h, --help        Display this help message

Example:
    $0 -s "/var/www/site1,/var/www/site2" --all --exclude-plugin akismet
EOF
    exit 1
}

# Initialize variables
SITES=""
UPDATE_CORE=false
UPDATE_PLUGINS=false
UPDATE_THEMES=false
DRY_RUN=false
EXCLUDED_PLUGINS=()

# Parse arguments
while [[ $# -gt 0 ]]; do
    case $1 in
        -s|--sites) SITES="$2"; shift 2 ;;
        -c|--core) UPDATE_CORE=true; shift ;;
        -p|--plugins) UPDATE_PLUGINS=true; shift ;;
        -t|--themes) UPDATE_THEMES=true; shift ;;
        -a|--all) UPDATE_CORE=true; UPDATE_PLUGINS=true; UPDATE_THEMES=true; shift ;;
        --exclude-plugin) EXCLUDED_PLUGINS+=("$2"); shift 2 ;;
        --dry-run) DRY_RUN=true; shift ;;
        -h|--help) usage ;;
        *) echo "Unknown option: $1"; usage ;;
    esac
done

# Validate required arguments
if [[ -z "$SITES" ]]; then
    echo "Error: Sites parameter is required"
    usage
fi

# Convert comma-separated sites to array
IFS=',' read -ra SITE_ARRAY <<< "$SITES"

# Process each site
for site in "${SITE_ARRAY[@]}"; do
    echo "Processing: $site"

    if [[ "$UPDATE_CORE" == true ]]; then
        if [[ "$DRY_RUN" == true ]]; then
            wp --path="$site" core check-update
        else
            wp --path="$site" core update
        fi
    fi

    if [[ "$UPDATE_PLUGINS" == true ]]; then
        EXCLUDE_ARGS=""
        for plugin in "${EXCLUDED_PLUGINS[@]}"; do
            EXCLUDE_ARGS+=" --exclude=$plugin"
        done

        if [[ "$DRY_RUN" == true ]]; then
            wp --path="$site" plugin list --update=available
        else
            wp --path="$site" plugin update --all $EXCLUDE_ARGS
        fi
    fi

    if [[ "$UPDATE_THEMES" == true ]]; then
        if [[ "$DRY_RUN" == true ]]; then
            wp --path="$site" theme list --update=available
        else
            wp --path="$site" theme update --all
        fi
    fi
done

echo "Update process completed successfully"

This script demonstrates several best practices: comprehensive usage documentation, boolean flags for optional features, array handling for multiple values, validation of required parameters, and safe execution with set -euo pipefail.

Best Practices for Argument Parsing

Always provide clear usage documentation that users can access with -h or --help. Validate all input before processing to catch errors early. Use meaningful variable names that clarify the purpose of each argument.

Set default values for optional parameters to ensure predictable behavior. Implement proper error handling with informative messages. Consider the order of operations when multiple flags interact.

For production scripts, add the set -euo pipefail directive at the beginning. This makes your script exit on errors, prevents using undefined variables, and ensures pipeline failures are caught.

Testing Your Argument Parsing

Test your scripts with various input combinations: missing required arguments, invalid values, conflicting options, and edge cases. Create a test suite that validates expected behavior:

# Test missing required argument
./script.sh  # Should show usage

# Test invalid environment
./script.sh -p /var/www/html -e invalid  # Should error

# Test dry run mode
./script.sh -s "/var/www/site1" --all --dry-run  # Should only show what would change

Related Links

• WP-CLI Official Documentation
• Bash Scripting Guide – Advanced Topics
• WP-CLI Commands Reference
• WordPress Automation Best Practices
• Shell Script Security Considerations

The post How to Parse Command Line Arguments in WP-CLI Bash Scripts appeared first on WP-CLI Mastery.

This is where Bash functions become your secret weapon.

In this guide, you’ll learn how to write reusable, production-ready Bash functions for WordPress automation. We’ll cover parameter validation, error handling, logging, and real-world examples you can use immediately in your WP-CLI scripts.

Why Use Functions in Bash Scripts?

Functions are reusable blocks of code that make your scripts:

More Maintainable: Fix a bug once in the function, not in 10 different scripts.

Easier to Read: backup_wordpress_database is clearer than 20 lines of inline code.

More Testable: Test individual functions independently.

DRY (Don’t Repeat Yourself): Write once, use everywhere.

Professional: Production-ready scripts use functions extensively.

Before Functions: Repetitive Code

Here’s what many WordPress automation scripts look like without functions:

#!/bin/bash
# Script 1: Backup site A
cd /var/www/siteA
wp db export /backups/siteA-$(date +%Y%m%d).sql
tar -czf /backups/siteA-files-$(date +%Y%m%d).tar.gz .
echo "Backup completed for Site A"

# Script 2: Backup site B (almost identical!)
cd /var/www/siteB
wp db export /backups/siteB-$(date +%Y%m%d).sql
tar -czf /backups/siteB-files-$(date +%Y%m%d).tar.gz .
echo "Backup completed for Site B"

This violates DRY principles and becomes a maintenance nightmare.

After Functions: Clean and Reusable

With functions, the same logic becomes:

#!/bin/bash

# Reusable function
backup_wordpress() {
    local wp_path=$1
    local backup_dir=$2
    local site_name=$(basename "$wp_path")
    local timestamp=$(date +%Y%m%d)

    cd "$wp_path" || return 1
    wp db export "${backup_dir}/${site_name}-${timestamp}.sql" || return 1
    tar -czf "${backup_dir}/${site_name}-files-${timestamp}.tar.gz" . || return 1
    echo "Backup completed for ${site_name}"
}

# Use the function
backup_wordpress /var/www/siteA /backups
backup_wordpress /var/www/siteB /backups
backup_wordpress /var/www/siteC /backups

One function, multiple uses. Change the backup logic once, and all three sites benefit.

Basic Function Syntax {#basic-syntax}

Bash functions can be defined in two ways:

Method 1: Using the function Keyword

function my_function() {
    echo "Hello from my function"
}

Method 2: Without the function Keyword (POSIX-compliant)

my_function() {
    echo "Hello from my function"
}

Both work identically. Method 2 is more portable and preferred for production scripts.

Calling Functions

Simply use the function name:

my_function  # Calls the function

Example: Simple WordPress Function

#!/bin/bash

# Function to check WordPress version
check_wp_version() {
    wp core version
}

# Call it
check_wp_version

Output:

6.4.2

Parameter Handling in Functions

Functions accept parameters just like scripts. Parameters are accessed using $1, $2, $3, etc.

Basic Parameters

greet_user() {
    local name=$1
    echo "Hello, ${name}!"
}

greet_user "John"  # Output: Hello, John!

Multiple Parameters

update_wordpress() {
    local wp_path=$1
    local backup=$2

    cd "$wp_path" || return 1

    if [ "$backup" = "yes" ]; then
        wp db export backup.sql
    fi

    wp core update
}

# Usage
update_wordpress /var/www/html yes

Parameter Variables

Bash provides special variables for working with parameters:

• $# – Number of parameters
• $@ – All parameters as separate strings
• $* – All parameters as single string
• $1, $2, ... – Individual parameters

WordPress Example: Plugin Update Function

update_plugin() {
    local wp_path=$1
    local plugin_name=$2

    echo "Updating plugin: ${plugin_name} at ${wp_path}"
    wp plugin update "$plugin_name" --path="$wp_path"
}

# Usage
update_plugin /var/www/html woocommerce
update_plugin /var/www/html yoast-seo

Return Values and Exit Codes

Bash functions don’t return values like other programming languages. Instead, they use:

1. Exit codes (0 for success, non-zero for failure)
2. Echo statements (output that can be captured)

Exit Codes with return

check_wordpress_exists() {
    local wp_path=$1

    if [ -f "${wp_path}/wp-config.php" ]; then
        return 0  # Success
    else
        return 1  # Failure
    fi
}

# Usage
if check_wordpress_exists /var/www/html; then
    echo "WordPress found!"
else
    echo "WordPress not found"
fi

Best Practice: Always return 0 for success, 1+ for errors. This follows Unix conventions and works with if statements.

Returning Values via Echo

get_wordpress_version() {
    local wp_path=$1
    wp core version --path="$wp_path"
}

# Capture output
version=$(get_wordpress_version /var/www/html)
echo "WordPress version: ${version}"

Combining Both Approaches

backup_database() {
    local wp_path=$1
    local backup_file=$2

    # Perform backup
    if wp db export "$backup_file" --path="$wp_path" 2>/dev/null; then
        echo "$backup_file"  # Return filename
        return 0             # Success exit code
    else
        echo ""              # Return empty string
        return 1             # Failure exit code
    fi
}

# Usage
if backup_file=$(backup_database /var/www/html "/backups/db.sql"); then
    echo "Backup successful: ${backup_file}"
else
    echo "Backup failed"
fi

Error Handling Best Practices

Production-ready functions need robust error handling. Here’s how to do it right.

Use set -e Cautiously

#!/bin/bash
set -e  # Exit on any error

# This will exit the entire script if wp fails
wp plugin update --all

Problem: set -e exits the entire script on first error, which might not be what you want in functions.

Better approach: Handle errors explicitly in functions.

Check Command Success

update_all_plugins() {
    local wp_path=$1

    if ! wp plugin update --all --path="$wp_path"; then
        echo "ERROR: Plugin update failed" >&2
        return 1
    fi

    echo "All plugins updated successfully"
    return 0
}

Validate Parameters

backup_wordpress() {
    local wp_path=$1
    local backup_dir=$2

    # Validate parameters exist
    if [ -z "$wp_path" ] || [ -z "$backup_dir" ]; then
        echo "ERROR: Missing parameters" >&2
        echo "Usage: backup_wordpress <wp_path> <backup_dir>" >&2
        return 1
    fi

    # Validate WordPress directory
    if [ ! -f "${wp_path}/wp-config.php" ]; then
        echo "ERROR: Not a WordPress installation: ${wp_path}" >&2
        return 1
    fi

    # Validate backup directory
    if [ ! -d "$backup_dir" ]; then
        echo "ERROR: Backup directory doesn't exist: ${backup_dir}" >&2
        return 1
    fi

    # Perform backup
    # ... backup logic here ...
}

Use Error Messages to STDERR

Send errors to stderr (file descriptor 2) instead of stdout:

log_error() {
    echo "[ERROR] $*" >&2
}

log_info() {
    echo "[INFO] $*"
}

# Usage
if ! wp core update; then
    log_error "WordPress core update failed"
    return 1
fi

log_info "WordPress updated successfully"

This allows users to separate errors from normal output:

./script.sh 2>errors.log  # Only errors go to file
./script.sh 2>&1 | grep ERROR  # Search errors

Real-World WordPress Functions {#wordpress-functions}

Let’s build production-ready functions you can use immediately.

Function 1: WordPress Site Backup

#!/bin/bash

backup_wordpress_site() {
    local wp_path=$1
    local backup_dir=$2
    local timestamp=$(date +%Y%m%d_%H%M%S)
    local site_name=$(basename "$wp_path")

    # Validate inputs
    if [ -z "$wp_path" ] || [ -z "$backup_dir" ]; then
        echo "ERROR: Usage: backup_wordpress_site <wp_path> <backup_dir>" >&2
        return 1
    fi

    if [ ! -f "${wp_path}/wp-config.php" ]; then
        echo "ERROR: Invalid WordPress path: ${wp_path}" >&2
        return 1
    fi

    # Create backup directory if needed
    mkdir -p "$backup_dir"

    # Backup database
    local db_file="${backup_dir}/${site_name}_db_${timestamp}.sql"
    echo "Backing up database..."
    if ! wp db export "$db_file" --path="$wp_path" --quiet; then
        echo "ERROR: Database backup failed" >&2
        return 1
    fi

    # Compress database
    gzip "$db_file"
    echo "Database backed up: ${db_file}.gz"

    # Backup files
    local files_archive="${backup_dir}/${site_name}_files_${timestamp}.tar.gz"
    echo "Backing up files..."
    if ! tar -czf "$files_archive" -C "$(dirname $wp_path)" "$(basename $wp_path)" 2>/dev/null; then
        echo "ERROR: File backup failed" >&2
        return 1
    fi

    echo "Files backed up: ${files_archive}"
    echo "Backup completed successfully"
    return 0
}

# Usage
backup_wordpress_site /var/www/html /backups

Function 2: Bulk Plugin Update with Verification

update_plugins_safe() {
    local wp_path=$1

    # Validation
    if [ ! -f "${wp_path}/wp-config.php" ]; then
        echo "ERROR: Invalid WordPress path" >&2
        return 1
    fi

    echo "Checking for plugin updates..."
    local updates=$(wp plugin list --update=available --path="$wp_path" --format=count)

    if [ "$updates" -eq 0 ]; then
        echo "All plugins are up to date"
        return 0
    fi

    echo "Found ${updates} plugin(s) to update"

    # Backup database before updates
    local backup_file="/tmp/pre-update-backup-$(date +%s).sql"
    echo "Creating safety backup..."
    if ! wp db export "$backup_file" --path="$wp_path" --quiet; then
        echo "ERROR: Safety backup failed, aborting" >&2
        return 1
    fi

    echo "Updating plugins..."
    if wp plugin update --all --path="$wp_path"; then
        echo "Plugins updated successfully"
        rm -f "$backup_file"  # Clean up backup if successful
        return 0
    else
        echo "ERROR: Plugin update failed" >&2
        echo "Safety backup available at: ${backup_file}"
        return 1
    fi
}

# Usage
update_plugins_safe /var/www/html

Function 3: WordPress Health Check

wordpress_health_check() {
    local wp_path=$1
    local errors=0

    echo "Running WordPress health check for: ${wp_path}"
    echo "=============================================="

    # Check 1: WordPress core
    echo -n "WordPress Core: "
    if wp core verify-checksums --path="$wp_path" &>/dev/null; then
        echo "✓ OK"
    else
        echo "✗ FAILED"
        ((errors++))
    fi

    # Check 2: Database
    echo -n "Database Connection: "
    if wp db check --path="$wp_path" &>/dev/null; then
        echo "✓ OK"
    else
        echo "✗ FAILED"
        ((errors++))
    fi

    # Check 3: Plugin updates
    echo -n "Plugin Updates: "
    local plugin_updates=$(wp plugin list --update=available --path="$wp_path" --format=count)
    if [ "$plugin_updates" -eq 0 ]; then
        echo "✓ All up to date"
    else
        echo "⚠ ${plugin_updates} update(s) available"
    fi

    # Check 4: Theme updates
    echo -n "Theme Updates: "
    local theme_updates=$(wp theme list --update=available --path="$wp_path" --format=count)
    if [ "$theme_updates" -eq 0 ]; then
        echo "✓ All up to date"
    else
        echo "⚠ ${theme_updates} update(s) available"
    fi

    # Check 5: Core version
    local wp_version=$(wp core version --path="$wp_path")
    echo "WordPress Version: ${wp_version}"

    echo "=============================================="
    if [ $errors -eq 0 ]; then
        echo "Health check passed"
        return 0
    else
        echo "Health check failed with ${errors} error(s)"
        return 1
    fi
}

# Usage
wordpress_health_check /var/www/html

Building a Function Library {#function-library}

Create a reusable library that you can source into any WordPress automation script.

Create the Library File

# Save as: ~/wp-functions.sh

#!/bin/bash
#
# WordPress Automation Function Library
# Source this file in your scripts: source ~/wp-functions.sh
#

# Color codes for output
RED='\033[0;31m'
GREEN='\033[0;32m'
YELLOW='\033[1;33m'
NC='\033[0m' # No Color

# Logging functions
log_info() {
    echo -e "${GREEN}[INFO]${NC} $*"
}

log_error() {
    echo -e "${RED}[ERROR]${NC} $*" >&2
}

log_warning() {
    echo -e "${YELLOW}[WARNING]${NC} $*"
}

# Check if path is valid WordPress installation
is_wordpress() {
    local wp_path=$1
    [ -f "${wp_path}/wp-config.php" ]
}

# Get WordPress version
get_wp_version() {
    local wp_path=$1
    wp core version --path="$wp_path" 2>/dev/null
}

# Check if plugin is installed
has_plugin() {
    local wp_path=$1
    local plugin_name=$2
    wp plugin is-installed "$plugin_name" --path="$wp_path" 2>/dev/null
}

# Safely update WordPress core
safe_core_update() {
    local wp_path=$1

    if ! is_wordpress "$wp_path"; then
        log_error "Not a WordPress installation: ${wp_path}"
        return 1
    fi

    local current_version=$(get_wp_version "$wp_path")
    log_info "Current version: ${current_version}"

    # Backup first
    log_info "Creating backup..."
    local backup_file="/tmp/wp-backup-$(date +%s).sql"
    if ! wp db export "$backup_file" --path="$wp_path" --quiet; then
        log_error "Backup failed"
        return 1
    fi

    # Update
    log_info "Updating WordPress core..."
    if wp core update --path="$wp_path"; then
        local new_version=$(get_wp_version "$wp_path")
        log_info "Updated from ${current_version} to ${new_version}"
        rm -f "$backup_file"
        return 0
    else
        log_error "Update failed. Backup saved at: ${backup_file}"
        return 1
    fi
}

Using the Library

Create a script that sources the library:

#!/bin/bash
# my-script.sh

# Load function library
source ~/wp-functions.sh

# Use the functions
log_info "Starting WordPress maintenance..."

if is_wordpress /var/www/html; then
    log_info "WordPress found"
    safe_core_update /var/www/html
else
    log_error "WordPress not found"
    exit 1
fi

This approach keeps your scripts clean and maintainable. Update the library once, and all scripts benefit.

Advanced Patterns {#advanced-patterns}

Pattern 1: Functions with Named Parameters

backup_wordpress() {
    # Parse named parameters
    local wp_path=""
    local backup_dir=""
    local include_uploads=true

    while [[ $# -gt 0 ]]; do
        case $1 in
            --path)
                wp_path="$2"
                shift 2
                ;;
            --backup-dir)
                backup_dir="$2"
                shift 2
                ;;
            --no-uploads)
                include_uploads=false
                shift
                ;;
            *)
                echo "Unknown option: $1" >&2
                return 1
                ;;
        esac
    done

    # Use the parameters
    echo "Path: ${wp_path}"
    echo "Backup dir: ${backup_dir}"
    echo "Include uploads: ${include_uploads}"
}

# Usage
backup_wordpress --path /var/www/html --backup-dir /backups --no-uploads

Pattern 2: Functions with Default Parameters

update_wordpress() {
    local wp_path=${1:-/var/www/html}  # Default to /var/www/html
    local backup=${2:-yes}               # Default to yes

    echo "Path: ${wp_path}"
    echo "Backup: ${backup}"
}

# Call with defaults
update_wordpress

# Call with custom values
update_wordpress /var/www/mysite no

Pattern 3: Array Return Values

get_outdated_plugins() {
    local wp_path=$1
    wp plugin list --update=available --path="$wp_path" --field=name
}

# Capture into array
mapfile -t plugins < <(get_outdated_plugins /var/www/html)

# Loop through results
for plugin in "${plugins[@]}"; do
    echo "Outdated: ${plugin}"
done

Testing Your Functions {#testing}

Always test functions before using in production.

Manual Testing Script

#!/bin/bash
# test-functions.sh

source ~/wp-functions.sh

echo "Testing WordPress functions..."
echo "=============================="

# Test 1: is_wordpress
echo "Test 1: is_wordpress"
if is_wordpress /var/www/html; then
    echo "✓ PASS"
else
    echo "✗ FAIL"
fi

# Test 2: get_wp_version
echo "Test 2: get_wp_version"
version=$(get_wp_version /var/www/html)
if [ -n "$version" ]; then
    echo "✓ PASS: Version ${version}"
else
    echo "✗ FAIL"
fi

# Add more tests...

Automated Testing with BATS

For serious projects, use BATS (Bash Automated Testing System):

# Install BATS
git clone https://github.com/bats-core/bats-core.git
cd bats-core
./install.sh /usr/local

# Create test file: test-wp-functions.bats
#!/usr/bin/env bats

load ~/wp-functions.sh

@test "is_wordpress returns true for valid path" {
    run is_wordpress /var/www/html
    [ "$status" -eq 0 ]
}

@test "is_wordpress returns false for invalid path" {
    run is_wordpress /tmp
    [ "$status" -eq 1 ]
}

# Run tests
bats test-wp-functions.bats

Next Steps

You now know how to write reusable Bash functions for WordPress automation. Here’s what to learn next:

Related Guides

1. Bulletproof Error Handling in Bash Scripts for WP-CLI – Take error handling to the next level
2. How to Parse Command Line Arguments in WP-CLI Bash Scripts – Make your functions accept complex parameters
3. Professional Logging and Debugging for WP-CLI Automation Scripts – Add production-grade logging

Practice Projects

Build a function library with these functions:

• Database backup and restore
• Plugin/theme management
• User management
• Content import/export
• Security hardening

Create a WordPress maintenance script that:

• Uses multiple functions from your library
• Accepts command-line arguments
• Has proper error handling
• Outputs colored logs

Join WPCLI Mastery

Want to master WordPress automation with battle-tested patterns and real-world projects?

Join the WPCLI Mastery waitlist and get:

• Free WordPress backup automation script (production-ready functions included)
• Access to complete function library
• Early bird course pricing ($99 vs $199)

Conclusion

Bash functions transform messy WordPress automation scripts into clean, maintainable, professional code. The patterns you learned here—parameter validation, error handling, return values—are the foundation of production-ready automation.

Key takeaways:

• Functions eliminate code duplication
• Always validate parameters
• Use return codes (0 = success, 1+ = failure)
• Handle errors explicitly
• Build a reusable function library
• Test your functions before production use

Start building your function library today. Every reusable function you write saves time on every future script.

Ready to build advanced WordPress automation? Check out our guide on automating WordPress backups with WP-CLI, which uses these function patterns in a complete project.

Questions about Bash functions for WordPress? Drop a comment below!

Found this helpful? Share it with other WordPress developers learning automation.

The post Writing Reusable Bash Functions for WordPress Automation appeared first on WP-CLI Mastery.