WP-CLI Mastery https://wpclimastery.com/ Automate WordPress Like a DevOps Pro. Mon, 24 Nov 2025 11:16:47 +0000 en-US hourly 1 https://wpclimastery.com/wp-content/uploads/2025/11/cropped-favicon-32x32.webp WP-CLI Mastery https://wpclimastery.com/ 32 32 WordPress Multisite Network Management with WP-CLI: Complete Guide https://wpclimastery.com/blog/wordpress-multisite-network-management-with-wp-cli-complete-guide/ Wed, 25 Feb 2026 09:00:00 +0000 https://wpclimastery.com/?p=161 Managing dozens or hundreds of WordPress Multisite network sites through the admin dashboard is tedious—creating sites manually, adding users one-by-one, updating plugins across all sites, and managing network settings requires...

The post WordPress Multisite Network Management with WP-CLI: Complete Guide appeared first on WP-CLI Mastery.

]]> Managing dozens or hundreds of WordPress Multisite network sites through the admin dashboard is tedious—creating sites manually, adding users one-by-one, updating plugins across all sites, and managing network settings requires hours of repetitive clicking.

WP-CLI transforms WordPress Multisite management with powerful network commands that create sites instantly, bulk manage users, update plugins network-wide, and automate complex operations across hundreds of sites with single commands.

In this guide, you’ll master WordPress Multisite network management with WP-CLI, from basic site creation to advanced bulk operations managing large-scale WordPress networks efficiently.

Why Use WP-CLI for Multisite?

WordPress Multisite dashboard management doesn’t scale when managing more than a handful of sites.

Dashboard Management Limitations

Time-consuming: Creating sites manually takes 5-10 minutes each.

No bulk operations: Must update plugins/themes on each site individually.

Limited automation: Can’t script repetitive network operations.

User management complexity: Adding users across multiple sites is tedious.

No reporting: Can’t generate network-wide statistics easily.

WP-CLI Multisite Advantages

Instant site creation: Create dozens of sites in seconds with scripts.

Network-wide updates: Update plugins/themes across all sites with one command.

Bulk user management: Add/remove users from multiple sites simultaneously.

Complete automation: Script complex network operations and scheduling.

Powerful reporting: Generate comprehensive network statistics instantly.

According to WordPress Multisite best practices, WP-CLI reduces network management time by 80% for networks with 10+ sites.

Multisite Network Commands Overview

Essential WP-CLI commands for Multisite networks.

Basic Network Information

# Check if Multisite is enabled
wp core is-installed --network

# List all sites in network
wp site list

# Get network details
wp site list --format=table --fields=blog_id,url,registered

# Count total sites
wp site list --format=count

# List sites with specific criteria
wp site list --field=url --archived=0 --deleted=0

Network Site Management

# Create new site
wp site create --slug=newsite --title="New Site"

# Create site with custom email
wp site create \
    --slug=department \
    --title="Department Site" \
    --email=admin@department.com

# Delete site
wp site delete 5 --yes

# Archive site
wp site archive 5

# Unarchive site
wp site unarchive 5

# Mark site as spam
wp site spam 5

# Empty (delete all content but keep site)
wp site empty 5 --yes

Learn about WordPress Multisite architecture.

Bulk Site Creation and Provisioning

Automate creating multiple sites programmatically.

Batch Site Creation Script

#!/bin/bash
# create-sites-batch.sh - Create multiple sites from CSV

SITES_CSV="sites.csv"

if [ ! -f "$SITES_CSV" ]; then
    echo "ERROR: $SITES_CSV not found"
    exit 1
fi

echo "Creating sites from $SITES_CSV"

# Skip header row, read CSV
tail -n +2 "$SITES_CSV" | while IFS=, read -r SLUG TITLE EMAIL; do
    echo "Creating site: $SLUG"

    # Check if site already exists
    if wp site list --field=url | grep -q "/$SLUG"; then
        echo "⊘ Site $SLUG already exists, skipping"
        continue
    fi

    # Create site
    SITE_ID=$(wp site create \
        --slug="$SLUG" \
        --title="$TITLE" \
        --email="$EMAIL" \
        --porcelain)

    if [ $? -eq 0 ]; then
        echo "✓ Created site: $SLUG (ID: $SITE_ID)"
    else
        echo "✗ Failed to create site: $SLUG"
    fi
done

echo "Batch site creation complete"

Sites CSV Template

slug,title,email
sales,Sales Department,sales@example.com
marketing,Marketing Department,marketing@example.com
support,Support Department,support@example.com
engineering,Engineering Department,engineering@example.com

Automated Site Provisioning

#!/bin/bash
# provision-new-site.sh - Complete site setup

SLUG="$1"
TITLE="$2"
ADMIN_EMAIL="$3"

if [ -z "$SLUG" ] || [ -z "$TITLE" ] || [ -z "$ADMIN_EMAIL" ]; then
    echo "Usage: $0 <slug> <title> <admin_email>"
    exit 1
fi

echo "Provisioning new site: $SLUG"

# Create site
SITE_ID=$(wp site create \
    --slug="$SLUG" \
    --title="$TITLE" \
    --email="$ADMIN_EMAIL" \
    --porcelain)

echo "✓ Site created (ID: $SITE_ID)"

# Switch to new site context
export WP_CLI_STRICT_ARGS_MODE=1

# Install and activate plugins
echo "Installing plugins..."
wp plugin install --activate \
    --url="$SLUG" \
    wordpress-seo \
    contact-form-7 \
    wordfence

# Install theme
echo "Installing theme..."
wp theme install twentytwentyfour --activate --url="$SLUG"

# Create default pages
echo "Creating default pages..."
wp post create \
    --url="$SLUG" \
    --post_type=page \
    --post_title='Home' \
    --post_status=publish \
    --post_content='Welcome to our site'

wp post create \
    --url="$SLUG" \
    --post_type=page \
    --post_title='About' \
    --post_status=publish

wp post create \
    --url="$SLUG" \
    --post_type=page \
    --post_title='Contact' \
    --post_status=publish

# Set front page
HOME_ID=$(wp post list --url="$SLUG" --post_type=page --name=home --field=ID)
wp option update --url="$SLUG" page_on_front "$HOME_ID"
wp option update --url="$SLUG" show_on_front page

# Configure settings
wp option update --url="$SLUG" blogdescription "Powered by WordPress Multisite"
wp option update --url="$SLUG" permalink_structure '/%postname%/'

echo "✓ Site provisioning complete: $SLUG"

Network-Wide Plugin and Theme Management

Manage plugins and themes across all sites.

Network-Wide Plugin Operations

# Install plugin network-wide
wp plugin install akismet --network

# Activate plugin for entire network
wp plugin activate akismet --network

# Deactivate network-wide
wp plugin deactivate akismet --network

# Update all plugins across all sites
for url in $(wp site list --field=url); do
    echo "Updating plugins for: $url"
    wp plugin update --all --url="$url"
done

# Check plugin status across network
wp site list --field=url | while read site_url; do
    echo "=== Plugins on $site_url ==="
    wp plugin list --url="$site_url" --status=active --format=table
done

Bulk Theme Management

#!/bin/bash
# manage-themes-network.sh

ACTION="${1:-list}"  # list, install, activate, delete

case "$ACTION" in
    list)
        echo "Themes across network:"
        wp site list --field=url | while read url; do
            echo "Site: $url"
            wp theme list --url="$url" --status=active --fields=name,version
            echo ""
        done
        ;;

    install)
        THEME="$2"
        echo "Installing $THEME on all sites..."
        for url in $(wp site list --field=url); do
            wp theme install "$THEME" --url="$url"
        done
        ;;

    activate)
        THEME="$2"
        echo "Activating $THEME on all sites..."
        for url in $(wp site list --field=url); do
            wp theme activate "$THEME" --url="$url"
        done
        ;;

    delete)
        THEME="$2"
        echo "Deleting $THEME from all sites..."
        for url in $(wp site list --field=url); do
            wp theme delete "$THEME" --url="$url"
        done
        ;;

    *)
        echo "Usage: $0 {list|install|activate|delete} [theme-name]"
        exit 1
        ;;
esac

Learn about Multisite plugin management.

User Management Across Network

Manage users and roles across multiple sites.

Add Users to Multiple Sites

#!/bin/bash
# add-user-to-sites.sh - Add user to multiple sites

USERNAME="$1"
ROLE="${2:-subscriber}"

if [ -z "$USERNAME" ]; then
    echo "Usage: $0 <username> [role]"
    exit 1
fi

# Check if user exists
if ! wp user get "$USERNAME" &>/dev/null; then
    echo "ERROR: User $USERNAME does not exist"
    exit 1
fi

echo "Adding $USERNAME as $ROLE to all sites..."

# Get all site IDs
SITES=$(wp site list --field=blog_id)

for SITE_ID in $SITES; do
    SITE_URL=$(wp site list --blog_id="$SITE_ID" --field=url)

    # Add user to site
    wp user set-role "$USERNAME" "$ROLE" --url="$SITE_URL"

    if [ $? -eq 0 ]; then
        echo "✓ Added to: $SITE_URL"
    else
        echo "✗ Failed: $SITE_URL"
    fi
done

echo "User addition complete"

Bulk User Role Management

#!/bin/bash
# manage-user-roles.sh

# List all users across network
network_user_report() {
    echo "Network User Report"
    echo "==================="

    wp site list --field=url | while read url; do
        echo ""
        echo "Site: $url"
        wp user list --url="$url" --format=table --fields=user_login,roles,user_email
    done
}

# Remove user from all sites
remove_user_network() {
    local username="$1"

    echo "Removing $username from all sites..."

    for url in $(wp site list --field=url); do
        if wp user list --url="$url" --field=user_login | grep -q "^$username
quot;; then
            wp user remove-role "$username" --url="$url"
            echo "✓ Removed from: $url"
        fi
    done
}

# Promote user to admin on all sites
promote_to_admin_network() {
    local username="$1"

    echo "Promoting $username to administrator on all sites..."

    for url in $(wp site list --field=url); do
        wp user set-role "$username" administrator --url="$url"
        echo "✓ Promoted on: $url"
    done
}

# Main script
case "$1" in
    report)
        network_user_report
        ;;
    remove)
        remove_user_network "$2"
        ;;
    promote)
        promote_to_admin_network "$2"
        ;;
    *)
        echo "Usage: $0 {report|remove|promote} [username]"
        exit 1
        ;;
esac







Super Admin Management







# Grant super admin privileges
wp super-admin add username

# Remove super admin privileges
wp super-admin remove username

# List all super admins
wp super-admin list

# Check if user is super admin
wp user get username --field=caps | grep -q "super_admin"







Network Statistics and Reporting





Generate comprehensive network reports.





Network Health Report







#!/bin/bash
# network-health-report.sh

REPORT_FILE="/tmp/multisite-health-$(date +%Y%m%d).txt"

{
    echo "WordPress Multisite Network Health Report"
    echo "=========================================="
    echo "Generated: $(date)"
    echo ""

    # Network overview
    echo "Network Overview"
    echo "----------------"
    SITE_COUNT=$(wp site list --format=count)
    ACTIVE_SITES=$(wp site list --archived=0 --deleted=0 --format=count)
    ARCHIVED_SITES=$(wp site list --archived=1 --format=count)
    DELETED_SITES=$(wp site list --deleted=1 --format=count)

    echo "Total sites: $SITE_COUNT"
    echo "Active sites: $ACTIVE_SITES"
    echo "Archived sites: $ARCHIVED_SITES"
    echo "Deleted sites: $DELETED_SITES"
    echo ""

    # User statistics
    echo "User Statistics"
    echo "---------------"
    TOTAL_USERS=$(wp user list --format=count)
    SUPER_ADMINS=$(wp super-admin list --format=count)

    echo "Total users: $TOTAL_USERS"
    echo "Super admins: $SUPER_ADMINS"
    echo ""

    # Plugin status across network
    echo "Network Plugin Status"
    echo "---------------------"
    echo "Network-activated plugins:"
    wp plugin list --status=active-network --format=table --fields=name,version
    echo ""

    # Site details
    echo "Site Details"
    echo "------------"
    wp site list --format=table --fields=blog_id,url,registered,last_updated

    echo ""

    # Storage usage (if multisite uses subdirectories)
    echo "Storage Usage"
    echo "-------------"
    for site_id in $(wp site list --field=blog_id); do
        url=$(wp site list --blog_id="$site_id" --field=url)
        uploads_dir="wp-content/uploads/sites/$site_id"

        if [ -d "$uploads_dir" ]; then
            size=$(du -sh "$uploads_dir" | cut -f1)
            echo "$url: $size"
        fi
    done

} > "$REPORT_FILE"

echo "✓ Report generated: $REPORT_FILE"

# Email report
mail -s "Multisite Network Health Report" admin@example.com < "$REPORT_FILE"







Activity Monitoring







#!/bin/bash
# monitor-network-activity.sh

echo "Network Activity Monitor"
echo "========================"

# Recently created sites
echo "Recently Created Sites (last 7 days):"
wp site list --format=table --fields=blog_id,url,registered | \
    grep "$(date -d '7 days ago' '+%Y-%m-%d')"

echo ""

# Recently updated sites
echo "Recently Updated Sites:"
wp site list --format=table --fields=blog_id,url,last_updated

echo ""

# New users (last 24 hours)
echo "New Users (last 24 hours):"
wp user list --format=table --fields=user_login,user_email,user_registered | \
    grep "$(date '+%Y-%m-%d')"

echo ""

# Plugin update status
echo "Sites Needing Plugin Updates:"
for url in $(wp site list --field=url); do
    UPDATES=$(wp plugin list --url="$url" --update=available --format=count)
    if [ "$UPDATES" -gt 0 ]; then
        echo "  $url: $UPDATES plugin updates available"
    fi
done







Learn about Multisite network analytics.





Backup and Clone Operations





Backup individual sites or clone across network.





Individual Site Backup







#!/bin/bash
# backup-multisite-site.sh

SITE_ID="$1"
BACKUP_DIR="/backups/multisite"

if [ -z "$SITE_ID" ]; then
    echo "Usage: $0 <site_id>"
    exit 1
fi

SITE_URL=$(wp site list --blog_id="$SITE_ID" --field=url)
DATE=$(date +%Y%m%d_%H%M%S)

echo "Backing up site: $SITE_URL"

mkdir -p "$BACKUP_DIR"

# Export database for specific site
wp db export "$BACKUP_DIR/site-${SITE_ID}-${DATE}.sql.gz" --url="$SITE_URL"

# Backup uploads directory
if [ -d "wp-content/uploads/sites/$SITE_ID" ]; then
    tar -czf "$BACKUP_DIR/uploads-${SITE_ID}-${DATE}.tar.gz" \
        "wp-content/uploads/sites/$SITE_ID"
fi

echo "✓ Backup complete: $BACKUP_DIR"







Clone Site Within Network







#!/bin/bash
# clone-multisite-site.sh

SOURCE_SITE_ID="$1"
NEW_SLUG="$2"
NEW_TITLE="$3"

if [ -z "$SOURCE_SITE_ID" ] || [ -z "$NEW_SLUG" ]; then
    echo "Usage: $0 <source_site_id> <new_slug> <new_title>"
    exit 1
fi

SOURCE_URL=$(wp site list --blog_id="$SOURCE_SITE_ID" --field=url)

echo "Cloning site: $SOURCE_URL to /$NEW_SLUG"

# Export source site
TEMP_SQL="/tmp/clone-$SOURCE_SITE_ID.sql"
wp db export "$TEMP_SQL" --url="$SOURCE_URL"

# Create new site
NEW_SITE_ID=$(wp site create \
    --slug="$NEW_SLUG" \
    --title="$NEW_TITLE" \
    --email="admin@example.com" \
    --porcelain)

echo "✓ New site created (ID: $NEW_SITE_ID)"

# Import database to new site
# Note: This requires custom SQL modification for multisite table prefixes
echo "Manual step required: Modify SQL dump table prefixes from wp_${SOURCE_SITE_ID}_ to wp_${NEW_SITE_ID}_"

echo "Clone preparation complete"







Network Maintenance Automation





Automate routine network maintenance tasks.





Automated Maintenance Script







#!/bin/bash
# multisite-maintenance.sh

LOG_FILE="/var/log/multisite-maintenance.log"

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

log "=== Multisite Maintenance Started ==="

# Update WordPress core on all sites
log "Updating WordPress core..."
wp core update --network

# Update all plugins across network
log "Updating plugins network-wide..."
for url in $(wp site list --field=url); do
    log "Updating plugins on: $url"
    wp plugin update --all --url="$url" 2>&1 | tee -a "$LOG_FILE"
done

# Update all themes
log "Updating themes network-wide..."
for url in $(wp site list --field=url); do
    log "Updating themes on: $url"
    wp theme update --all --url="$url" 2>&1 | tee -a "$LOG_FILE"
done

# Clear caches
log "Clearing caches..."
for url in $(wp site list --field=url); do
    wp cache flush --url="$url"
done

# Optimize databases
log "Optimizing databases..."
wp db optimize

# Clean up spam/trash
log "Cleaning up spam and trash..."
for url in $(wp site list --field=url); do
    wp post delete $(wp post list --url="$url" --post_status=trash --format=ids) --force
    wp comment delete $(wp comment list --url="$url" --status=spam --format=ids) --force
done

log "=== Maintenance Complete ==="







Scheduled Network Maintenance







# Add to crontab: crontab -e

# Weekly network maintenance (Sundays at 2 AM)
0 2 * * 0 /usr/local/bin/multisite-maintenance.sh

# Daily network health report
0 8 * * * /usr/local/bin/network-health-report.sh

# Monthly user audit across network
0 9 1 * * /usr/local/bin/network-user-report.sh | mail -s "Monthly Network User Report" admin@example.com







Next Steps





You now have comprehensive WordPress Multisite network management capabilities with WP-CLI.









Week 1: Basic operations





    

  • Create and manage sites
    • 




  • Understand network commands
    • 




  • Practice bulk operations
    • 






Week 2: User management





    

  • Add users across network
    • 




  • Manage roles and permissions
    • 




  • Configure super admins
    • 






Week 3: Automation





    

  • Build provisioning scripts
    • 




  • Automate maintenance tasks
    • 




  • Create reporting systems
    • 






Week 4: Production scaling





    

  • Optimize large networks
    • 




  • Implement monitoring
    • 




  • Backup and disaster recovery
    • 






Advanced Topics





    

  1. Multi-Network WordPress – Networks of networks
    2. 




  2. Multisite Performance Optimization – Scale to thousands of sites
    3. 




  3. Custom Network Plugins – Build network-specific functionality
    4. 






Get More Resources





Download Multisite scripts including:





    

  • Site provisioning automation
    • 




  • Network management tools
    • 




  • Reporting templates
    • 






Join our email course for:





    

  • Weekly WP-CLI tutorials
    • 




  • Multisite best practices
    • 




  • Network scaling strategies
    • 






Conclusion





WordPress Multisite network management with WP-CLI transforms tedious manual operations into automated workflows—enabling efficient management of networks with hundreds or thousands of sites.





What we covered:





✅ Essential Multisite network commands 
✅ Bulk site creation and provisioning 
✅ Network-wide plugin and theme management 
✅ User management across multiple sites 
✅ Comprehensive network reporting 
✅ Automated maintenance workflows





Master these techniques, and you’ll manage large WordPress Multisite networks effortlessly—provisioning sites instantly, automating updates, and monitoring health across entire networks.





Ready for more? Learn Multisite performance optimization or enterprise WordPress architecture.





Questions about WordPress Multisite management? Drop a comment below!





Found this helpful? Share with other network administrators.


The post WordPress Multisite Network Management with WP-CLI: Complete Guide appeared first on WP-CLI Mastery.

]]>
					
		
		
			
		
		Automate WordPress Content with AI APIs and WP-CLI (Claude, OpenAI)
		https://wpclimastery.com/blog/automate-wordpress-content-with-ai-apis-and-wp-cli-claude-openai/
		
		
		Fri, 20 Feb 2026 09:00:00 +0000
				
		
		
		
		
		
		https://wpclimastery.com/?p=163

					Creating quality WordPress content at scale is time-consuming—researching topics, writing articles, editing drafts, and formatting posts manually limits how much you can publish. Writers spend hours producing content that AI...


The post Automate WordPress Content with AI APIs and WP-CLI (Claude, OpenAI) appeared first on WP-CLI Mastery.

]]>
										Creating quality WordPress content at scale is time-consuming—researching topics, writing articles, editing drafts, and formatting posts manually limits how much you can publish. Writers spend hours producing content that AI could generate in minutes.





AI-powered content generation with WP-CLI automates WordPress publishing—generate articles from prompts, create variations, translate content, optimize for SEO, and publish directly to WordPress. Combine Claude API or OpenAI with WP-CLI for scalable content workflows.





In this guide, you’ll learn to build AI content generation systems for WordPress using WP-CLI, with ethical guidelines, API integration patterns, and automation workflows for responsible AI-assisted publishing.





AI Content Generation Ethics





Before building AI content systems, understand ethical implications and responsible use.





Ethical Considerations





Transparency: Disclose AI-generated content to readers when appropriate.





Quality control: Review and edit AI output before publishing.





Originality: Ensure content doesn’t plagiarize or duplicate existing work.





Accuracy: Verify facts, statistics, and claims in AI-generated content.





Human value: Use AI to augment human creativity, not replace it entirely.





Responsible AI Content Guidelines







# Best practices for AI-generated WordPress content

1. Human oversight required
   - Review all AI content before publishing
   - Edit for accuracy, tone, and brand voice
   - Add human expertise and insights

2. Disclosure when appropriate
   - Consider adding AI disclosure for transparency
   - Follow FTC guidelines for automated content

3. Quality over quantity
   - Don't publish low-quality AI content at scale
   - Maintain editorial standards

4. Respect copyrights
   - Don't train on or reproduce copyrighted material
   - Verify AI output is original

5. Value to readers
   - Ensure content serves reader needs
   - Provide genuine value, not just SEO filler







Learn about AI content ethics from the FTC.





Claude API Integration





Integrate Anthropic’s Claude API with WP-CLI for content generation.





Claude API Setup







# Install dependencies
pip install anthropic

# Set API key
export ANTHROPIC_API_KEY="your-api-key-here"

# Test connection
python -c "import anthropic; client = anthropic.Anthropic(); print('Connected')"







Generate Content with Claude







#!/usr/bin/env python3
# generate-with-claude.py

import anthropic
import sys
import os

def generate_article(topic, target_words=1000):
    client = anthropic.Anthropic(api_key=os.environ.get("ANTHROPIC_API_KEY"))

    prompt = f"""Write a {target_words}-word informative blog post about: {topic}

Include:
- Engaging introduction
- 3-5 main sections with H2 headings
- Practical examples
- Conclusion with key takeaways

Format in markdown."""

    message = client.messages.create(
        model="claude-3-5-sonnet-20241022",
        max_tokens=4096,
        messages=[
            {"role": "user", "content": prompt}
        ]
    )

    return message.content[0].text

if __name__ == "__main__":
    topic = sys.argv[1] if len(sys.argv) > 1 else "WordPress automation"

    print(generate_article(topic))







Usage:







python generate-with-claude.py "WP-CLI best practices" > article.md







Publish to WordPress







#!/bin/bash
# ai-to-wordpress.sh - Generate and publish AI content

TOPIC="$1"
CATEGORY_ID="${2:-1}"

if [ -z "$TOPIC" ]; then
    echo "Usage: $0 <topic> [category_id]"
    exit 1
fi

echo "Generating content for: $TOPIC"

# Generate content with Claude
CONTENT=$(python generate-with-claude.py "$TOPIC")

# Create WordPress post as draft for review
POST_ID=$(wp post create \
    --post_title="$TOPIC" \
    --post_content="$CONTENT" \
    --post_status=draft \
    --post_category=$CATEGORY_ID \
    --porcelain)

echo "✓ Draft created: Post ID $POST_ID"
echo "Review at: $(wp option get siteurl)/wp-admin/post.php?post=$POST_ID&action=edit"







Learn about Claude API.





OpenAI Integration





Use OpenAI’s GPT models for WordPress content generation.





OpenAI Setup







# Install OpenAI library
pip install openai

# Set API key
export OPENAI_API_KEY="your-api-key-here"







Generate with GPT-4







#!/usr/bin/env python3
# generate-with-openai.py

from openai import OpenAI
import sys
import os

def generate_article(topic, model="gpt-4"):
    client = OpenAI(api_key=os.environ.get("OPENAI_API_KEY"))

    response = client.chat.completions.create(
        model=model,
        messages=[
            {"role": "system", "content": "You are a professional content writer creating high-quality WordPress blog posts."},
            {"role": "user", "content": f"Write a comprehensive 1000-word blog post about: {topic}. Include clear headings, practical examples, and actionable takeaways. Format in markdown."}
        ],
        temperature=0.7,
        max_tokens=2000
    )

    return response.choices[0].message.content

if __name__ == "__main__":
    topic = sys.argv[1] if len(sys.argv) > 1 else "WordPress development"
    print(generate_article(topic))







Batch Content Generation







#!/bin/bash
# batch-generate-content.sh - Generate multiple posts

TOPICS_FILE="$1"

if [ ! -f "$TOPICS_FILE" ]; then
    echo "Usage: $0 <topics-file>"
    echo "Topics file should contain one topic per line"
    exit 1
fi

while read -r TOPIC; do
    echo "Generating: $TOPIC"

    # Generate content
    CONTENT=$(python generate-with-claude.py "$TOPIC")

    # Create draft post
    POST_ID=$(wp post create \
        --post_title="$TOPIC" \
        --post_content="$CONTENT" \
        --post_status=draft \
        --porcelain)

    echo "✓ Created draft: $POST_ID"

    # Rate limiting
    sleep 2
done < "$TOPICS_FILE"

echo "✓ Batch generation complete"







Content Enhancement





Use AI to improve existing WordPress content.





SEO Optimization







#!/usr/bin/env python3
# optimize-for-seo.py

import anthropic
import sys
import os

def optimize_content(original_content, focus_keyword):
    client = anthropic.Anthropic(api_key=os.environ.get("ANTHROPIC_API_KEY"))

    prompt = f"""Optimize this content for SEO targeting the keyword: {focus_keyword}

Original content:
{original_content}

Improve:
- Keyword density (natural placement)
- Meta description suggestion
- H2/H3 headings with keyword variations
- Internal linking opportunities

Provide the optimized version."""

    message = client.messages.create(
        model="claude-3-5-sonnet-20241022",
        max_tokens=4096,
        messages=[{"role": "user", "content": prompt}]
    )

    return message.content[0].text

if __name__ == "__main__":
    if len(sys.argv) < 3:
        print("Usage: optimize-for-seo.py <post_id> <focus_keyword>")
        sys.exit(1)

    post_id = sys.argv[1]
    keyword = sys.argv[2]

    # Get original content (would use wp-cli here)
    content = sys.stdin.read()

    print(optimize_content(content, keyword))







Content Expansion







#!/bin/bash
# expand-content.sh - Expand short posts with AI

MIN_WORDS=300
TARGET_WORDS=1000

# Find short posts
SHORT_POSTS=$(wp post list \
    --post_status=publish \
    --format=ids \
    --fields=ID,post_content \
    | while read POST_ID; do
        WORD_COUNT=$(wp post get $POST_ID --field=post_content | wc -w)
        if [ "$WORD_COUNT" -lt "$MIN_WORDS" ]; then
            echo "$POST_ID"
        fi
    done)

for POST_ID in $SHORT_POSTS; do
    echo "Expanding post: $POST_ID"

    TITLE=$(wp post get $POST_ID --field=post_title)
    CONTENT=$(wp post get $POST_ID --field=post_content)

    # Generate expanded version
    EXPANDED=$(python -c "
import anthropic, os
client = anthropic.Anthropic(api_key=os.environ.get('ANTHROPIC_API_KEY'))
message = client.messages.create(
    model='claude-3-5-sonnet-20241022',
    max_tokens=2048,
    messages=[{
        'role': 'user',
        'content': f'''Expand this article to approximately $TARGET_WORDS words while maintaining quality:

Title: $TITLE

Current content:
$CONTENT

Add more detail, examples, and value while staying on topic.'''
    }]
)
print(message.content[0].text)
")

    # Save as revision (create new draft for review)
    wp post create \
        --post_title="$TITLE (Expanded)" \
        --post_content="$EXPANDED" \
        --post_status=draft

    echo "✓ Expanded version created for review"
done







Automated Publishing Workflows





Build complete AI-powered content pipelines.





Daily Auto-Publish System







#!/bin/bash
# daily-ai-content.sh - Generate and publish content daily

TOPICS=(
    "WordPress security best practices"
    "WP-CLI productivity tips"
    "WordPress performance optimization"
    "Content management automation"
)

# Select random topic
TOPIC="${TOPICS[$RANDOM % ${#TOPICS[@]}]}"

echo "Generating daily content: $TOPIC"

# Generate with AI
CONTENT=$(python generate-with-claude.py "$TOPIC")

# Add disclaimer
DISCLAIMER="<em>Note: This article was generated with AI assistance and reviewed by our editorial team.</em>"

FULL_CONTENT="${CONTENT}


${DISCLAIMER}"

# Create post
POST_ID=$(wp post create \
    --post_title="$TOPIC" \
    --post_content="$FULL_CONTENT" \
    --post_status=draft \
    --post_category=5 \
    --tags_input="ai-generated,automation" \
    --porcelain)

# Set featured image (from Unsplash API - separate integration)
# Add meta fields for tracking
wp post meta add $POST_ID ai_generated "true"
wp post meta add $POST_ID generation_date "$(date +%Y-%m-%d)"

echo "✓ Draft created: $POST_ID"
echo "Review and publish at: $(wp option get siteurl)/wp-admin/post.php?post=$POST_ID&action=edit"







Schedule with cron:







# Run daily at 8 AM
0 8 * * * /usr/local/bin/daily-ai-content.sh







Content Translation







#!/usr/bin/env python3
# translate-post.py - Translate WordPress posts with AI

import anthropic
import sys
import os

def translate_content(content, target_language):
    client = anthropic.Anthropic(api_key=os.environ.get("ANTHROPIC_API_KEY"))

    message = client.messages.create(
        model="claude-3-5-sonnet-20241022",
        max_tokens=4096,
        messages=[{
            "role": "user",
            "content": f"Translate this content to {target_language}. Maintain formatting and structure:\n\n{content}"
        }]
    )

    return message.content[0].text

if __name__ == "__main__":
    if len(sys.argv) < 3:
        print("Usage: translate-post.py <post_id> <language>")
        sys.exit(1)

    post_id = sys.argv[1]
    language = sys.argv[2]

    # Read from stdin
    content = sys.stdin.read()

    print(translate_content(content, language))







Usage:







# Translate post to Spanish
wp post get 123 --field=post_content | python translate-post.py 123 "Spanish" | \
wp post create --post_title="Translated Post" --post_content=-







Quality Control





Implement checks to ensure AI content quality.





Content Review Checklist







#!/bin/bash
# review-ai-content.sh - Quality check for AI posts

POST_ID="$1"

echo "Reviewing AI-generated post: $POST_ID"

# Check word count
WORD_COUNT=$(wp post get $POST_ID --field=post_content | wc -w)
echo "Word count: $WORD_COUNT"

if [ "$WORD_COUNT" -lt 300 ]; then
    echo "⚠ Content too short"
fi

# Check for common AI phrases
CONTENT=$(wp post get $POST_ID --field=post_content)

AI_PHRASES=(
    "as an AI"
    "I don't have"
    "I cannot"
    "my knowledge cutoff"
)

for PHRASE in "${AI_PHRASES[@]}"; do
    if echo "$CONTENT" | grep -qi "$PHRASE"; then
        echo "⚠ Found AI artifact: '$PHRASE'"
    fi
done

# Check readability
TITLE=$(wp post get $POST_ID --field=post_title)
if [ ${#TITLE} -gt 60 ]; then
    echo "⚠ Title too long for SEO"
fi

# Check for images
IMAGE_COUNT=$(echo "$CONTENT" | grep -c '<img')
if [ "$IMAGE_COUNT" -eq 0 ]; then
    echo "⚠ No images in content"
fi

echo "✓ Review complete"







Cost Management





Track and control AI API costs.





API Usage Tracking







#!/bin/bash
# track-ai-costs.sh

LOG_FILE="/var/log/ai-content-costs.log"

log_generation() {
    local model="$1"
    local tokens="$2"
    local cost="$3"

    echo "$(date +%Y-%m-%d),$(date +%H:%M:%S),$model,$tokens,$cost" >> "$LOG_FILE"
}

# After each generation
log_generation "claude-3-sonnet" "2048" "0.06"

# Monthly report
generate_cost_report() {
    echo "AI Content Generation Cost Report"
    echo "Month: $(date +%Y-%m)"
    echo "=================================="

    TOTAL_COST=$(awk -F',' '{sum += $5} END {print sum}' "$LOG_FILE")
    TOTAL_POSTS=$(wc -l < "$LOG_FILE")

    echo "Total generations: $TOTAL_POSTS"
    echo "Total cost: \$$TOTAL_COST"
    echo "Average per post: \$$(echo "scale=2; $TOTAL_COST / $TOTAL_POSTS" | bc)"
}







Next Steps





You now have AI-powered content generation capabilities for WordPress.









Week 1: Basic integration





    

  • Set up Claude/OpenAI APIs
    • 




  • Generate test content
    • 




  • Publish to WordPress
    • 






Week 2: Automation





    

  • Build generation scripts
    • 




  • Schedule automated publishing
    • 




  • Implement quality checks
    • 






Week 3: Enhancement





    

  • Add SEO optimization
    • 




  • Implement translations
    • 




  • Create content variations
    • 






Week 4: Production





    

  • Cost tracking
    • 




  • Quality control systems
    • 




  • Editorial workflows
    • 






Advanced Topics





    

  1. Fine-tuning Models – Custom AI models for your brand
    2. 




  2. Multi-modal Content – Generate images with text
    3. 




  3. Content Personalization – AI-driven user targeting
    4. 






Get More Resources





Download AI integration scripts including:





    

  • Complete generation system
    • 




  • Quality control tools
    • 




  • Cost tracking utilities
    • 






Join our email course for:





    

  • Weekly WP-CLI tutorials
    • 




  • AI content strategies
    • 




  • Automation best practices
    • 






Conclusion





AI-powered content generation with WP-CLI enables scalable WordPress publishing while maintaining quality through human oversight and ethical practices.





What we covered:





✅ Ethical AI content guidelines 
✅ Claude and OpenAI API integration 
✅ Automated content generation workflows 
✅ Content enhancement and optimization 
✅ Quality control and review systems 
✅ Cost tracking and management





Use AI responsibly as a tool to augment human creativity—review all content, ensure accuracy, provide genuine value to readers, and maintain editorial standards.





Ready for more? Learn content strategy or SEO automation.





Questions about AI content generation for WordPress? Drop a comment below!





Found this helpful? Share responsibly with other content creators.


The post Automate WordPress Content with AI APIs and WP-CLI (Claude, OpenAI) appeared first on WP-CLI Mastery.

]]>
					
		
		
			
		
		Automate WordPress Security Scanning and Monitoring with WP-CLI
		https://wpclimastery.com/blog/automate-wordpress-security-scanning-and-monitoring-with-wp-cli/
		
		
		Sun, 15 Feb 2026 09:00:00 +0000
				
		
		
		
		
		
		https://wpclimastery.com/?p=162

					WordPress security requires constant vigilance—manually checking for plugin vulnerabilities, monitoring file changes, detecting malware, verifying core integrity, and reviewing user permissions. Manual security audits happen infrequently and miss threats between...


The post Automate WordPress Security Scanning and Monitoring with WP-CLI appeared first on WP-CLI Mastery.

]]>
										WordPress security requires constant vigilance—manually checking for plugin vulnerabilities, monitoring file changes, detecting malware, verifying core integrity, and reviewing user permissions. Manual security audits happen infrequently and miss threats between checks.





Automated WordPress security scanning with WP-CLI detects vulnerabilities continuously, monitors file integrity, checks for malware patterns, validates checksums, and alerts on suspicious changes. Run comprehensive security scans daily without manual intervention.





In this guide, you’ll build automated WordPress security monitoring systems using WP-CLI, from basic vulnerability checks to production-grade security automation that protects your sites 24/7.





Why Automate WordPress Security?





Manual WordPress security checks don’t provide continuous protection against evolving threats.





Manual Security Limitations





Infrequent checks: Manual audits happen weekly or monthly, leaving gaps.





Human error: Manual reviews miss subtle security indicators.





Time-consuming: Comprehensive security audits take hours per site.





No real-time alerts: Breaches go undetected until the next manual check.





Limited scope: Can’t check every file, user, and configuration regularly.





Automated Security Benefits





Continuous monitoring: Security checks run automatically every day.





Instant alerts: Get notified immediately when threats are detected.





Comprehensive coverage: Scan every file, plugin, theme, and configuration.





Historical tracking: Log all security events for forensic analysis.





Multi-site management: Monitor dozens of WordPress sites from one system.





According to Sucuri research, automated security monitoring detects breaches 85% faster than manual audits.





Core File Integrity Verification





Detect unauthorized modifications to WordPress core files.





Checksum Verification







#!/bin/bash
# verify-core-integrity.sh

echo "WordPress Core Integrity Check"
echo "==============================="

# Verify core file checksums
if wp core verify-checksums; then
    echo "✓ Core files verified - no modifications detected"
else
    echo "✗ ALERT: Core files modified or corrupted"
    echo "Details:"
    wp core verify-checksums --format=json | jq -r '.[] | "  - \(.)"'

    # Send alert
    echo "Core file integrity check failed on $(hostname)" | \
        mail -s "WordPress Security Alert" admin@example.com
fi







Automated Daily Verification







#!/bin/bash
# daily-integrity-check.sh

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

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

log "Starting core integrity check"

# Check WordPress core
if ! wp core verify-checksums 2>&1 | tee -a "$LOG_FILE"; then
    log "✗ Core integrity check FAILED"

    # Create detailed report
    {
        echo "WordPress Core Integrity Failure"
        echo "================================="
        echo "Timestamp: $(date)"
        echo "Server: $(hostname)"
        echo "WordPress version: $(wp core version)"
        echo ""
        echo "Modified files:"
        wp core verify-checksums 2>&1 | grep "^Error:"
    } | mail -s "URGENT: WordPress Core Modified" security@example.com

    exit 1
fi

log "✓ Core integrity check passed"







Learn about WordPress file integrity.





Plugin and Theme Vulnerability Detection





Check for known security vulnerabilities in plugins and themes.





WP-CLI Vulnerability Scanner







#!/bin/bash
# scan-vulnerabilities.sh

echo "WordPress Vulnerability Scan"
echo "============================"

# Check if WPScan CLI is available
if ! command -v wpscan &> /dev/null; then
    echo "Installing WPScan..."
    gem install wpscan
fi

# Update WPScan database
wpscan --update

# Scan WordPress installation
SCAN_RESULTS=$(wpscan --url "$(wp option get siteurl)" \
    --format json \
    --random-user-agent \
    --disable-tls-checks)

# Parse vulnerabilities
VULN_COUNT=$(echo "$SCAN_RESULTS" | jq '.plugins | to_entries[] | select(.value.vulnerabilities | length > 0) | .value.vulnerabilities | length' | awk '{s+=$1} END {print s}')

if [ "$VULN_COUNT" -gt 0 ]; then
    echo "✗ ALERT: $VULN_COUNT vulnerabilities detected"

    # Generate detailed report
    echo "$SCAN_RESULTS" | jq -r '.plugins | to_entries[] | select(.value.vulnerabilities | length > 0) | "Plugin: \(.key)\nVulnerabilities:\n\(.value.vulnerabilities[] | "  - \(.title) (Severity: \(.vuln_type))\n    Fixed in: \(.fixed_in // "No fix available")\n")"'

else
    echo "✓ No known vulnerabilities detected"
fi







Check Plugin Updates for Security Fixes







#!/bin/bash
# check-security-updates.sh

echo "Checking for security updates..."

# Get plugins with available updates
UPDATES=$(wp plugin list --update=available --format=json)

if [ "$UPDATES" != "[]" ]; then
    echo "Plugins with available updates:"
    echo "$UPDATES" | jq -r '.[] | "- \(.name) (Current: \(.version), Available: \(.update_version))"'

    # Check update changelogs for security keywords
    echo ""
    echo "Checking changelogs for security mentions..."

    echo "$UPDATES" | jq -r '.[].name' | while read PLUGIN; do
        CHANGELOG=$(wp plugin get "$PLUGIN" --field=update_changelog 2>/dev/null)

        if echo "$CHANGELOG" | grep -qi 'security\|vulnerability\|xss\|sql injection\|exploit'; then
            echo "⚠ SECURITY UPDATE AVAILABLE: $PLUGIN"
            echo "  Update immediately using: wp plugin update $PLUGIN"
        fi
    done
else
    echo "✓ All plugins up to date"
fi







Learn about WordPress security best practices.





File Change Monitoring





Detect unauthorized file modifications.





File Integrity Database







#!/bin/bash
# create-file-baseline.sh - Create baseline of file checksums

BASELINE_FILE="/var/backups/wp-file-baseline.txt"
WP_PATH="/var/www/html"

echo "Creating file integrity baseline..."

cd "$WP_PATH"

# Generate checksums for all WordPress files
find . -type f \
    -not -path "./wp-content/uploads/*" \
    -not -path "./wp-content/cache/*" \
    -not -path "./wp-content/backup/*" \
    -exec md5sum {} \; | sort > "$BASELINE_FILE"

echo "✓ Baseline created: $BASELINE_FILE"
echo "Total files: $(wc -l < $BASELINE_FILE)"







Detect File Changes







#!/bin/bash
# detect-file-changes.sh

BASELINE_FILE="/var/backups/wp-file-baseline.txt"
WP_PATH="/var/www/html"
REPORT_FILE="/tmp/file-changes-$(date +%Y%m%d).txt"

if [ ! -f "$BASELINE_FILE" ]; then
    echo "ERROR: Baseline file not found. Run create-file-baseline.sh first."
    exit 1
fi

echo "Scanning for file changes..."

cd "$WP_PATH"

# Generate current checksums
find . -type f \
    -not -path "./wp-content/uploads/*" \
    -not -path "./wp-content/cache/*" \
    -not -path "./wp-content/backup/*" \
    -exec md5sum {} \; | sort > /tmp/current-checksums.txt

# Compare with baseline
{
    echo "WordPress File Change Report"
    echo "============================="
    echo "Date: $(date)"
    echo ""

    # Modified files
    echo "Modified Files:"
    comm -13 "$BASELINE_FILE" /tmp/current-checksums.txt | awk '{print $2}' | while read file; do
        if grep -q "$file" "$BASELINE_FILE"; then
            echo "  MODIFIED: $file"
        fi
    done

    echo ""

    # New files
    echo "New Files:"
    comm -13 "$BASELINE_FILE" /tmp/current-checksums.txt | awk '{print $2}' | while read file; do
        if ! grep -q "$file" "$BASELINE_FILE"; then
            echo "  ADDED: $file"
        fi
    done

    echo ""

    # Deleted files
    echo "Deleted Files:"
    comm -23 "$BASELINE_FILE" /tmp/current-checksums.txt | awk '{print $2}' | while read file; do
        echo "  DELETED: $file"
    done

} > "$REPORT_FILE"

# Check if changes detected
CHANGE_COUNT=$(cat "$REPORT_FILE" | grep -c "MODIFIED:\|ADDED:\|DELETED:")

if [ "$CHANGE_COUNT" -gt 0 ]; then
    echo "✗ ALERT: $CHANGE_COUNT file changes detected"
    echo "Report: $REPORT_FILE"

    # Email report
    mail -s "WordPress File Changes Detected" admin@example.com < "$REPORT_FILE"
else
    echo "✓ No file changes detected"
fi

# Cleanup
rm /tmp/current-checksums.txt







Malware Pattern Scanning





Detect common malware patterns in WordPress files.





Basic Malware Scanner







#!/bin/bash
# scan-malware.sh - Detect common malware patterns

WP_PATH="/var/www/html"
REPORT_FILE="/tmp/malware-scan-$(date +%Y%m%d).txt"

echo "WordPress Malware Scan"
echo "======================"

# Suspicious patterns to check
declare -a PATTERNS=(
    "eval(base64_decode"
    "eval(gzinflate"
    "eval(str_rot13"
    "system(\$_"
    "shell_exec"
    "passthru"
    "base64_decode.*eval"
    "FilesMan"
    "r57shell"
    "c99shell"
    "WSO shell"
)

{
    echo "Malware Scan Report"
    echo "==================="
    echo "Date: $(date)"
    echo "Path: $WP_PATH"
    echo ""

    for PATTERN in "${PATTERNS[@]}"; do
        echo "Checking for: $PATTERN"

        MATCHES=$(grep -r -l -i "$PATTERN" "$WP_PATH" \
            --exclude-dir=wp-content/uploads \
            --exclude-dir=wp-content/cache \
            --exclude-dir=node_modules \
            --include="*.php" 2>/dev/null)

        if [ ! -z "$MATCHES" ]; then
            echo "✗ SUSPICIOUS: Files matching '$PATTERN':"
            echo "$MATCHES" | while read file; do
                echo "  - $file"
            done
            echo ""
        fi
    done

} > "$REPORT_FILE"

# Check if suspicious files found
SUSPICIOUS_COUNT=$(grep -c "✗ SUSPICIOUS:" "$REPORT_FILE" || echo 0)

if [ "$SUSPICIOUS_COUNT" -gt 0 ]; then
    echo "✗ ALERT: Potential malware detected"
    echo "Report: $REPORT_FILE"

    # Send alert
    mail -s "URGENT: Potential Malware Detected" security@example.com < "$REPORT_FILE"
else
    echo "✓ No malware patterns detected"
fi







Check for Suspicious Files







#!/bin/bash
# check-suspicious-files.sh

WP_PATH="/var/www/html"

echo "Checking for suspicious files..."

# Check for unusual file types in wp-content
echo "Checking for executable files in wp-content..."
find "$WP_PATH/wp-content" \
    -type f \
    \( -name "*.exe" -o -name "*.sh" -o -name "*.bat" \) \
    -print

# Check for PHP files in uploads directory
echo "Checking for PHP files in uploads..."
find "$WP_PATH/wp-content/uploads" -name "*.php" -print

# Check for recently modified files (last 24 hours)
echo "Recently modified PHP files (last 24 hours)..."
find "$WP_PATH" -name "*.php" -mtime -1 -type f -print

# Check for files with suspicious permissions
echo "Files with 777 permissions..."
find "$WP_PATH" -type f -perm 0777 -print







Learn about WordPress malware detection.





User Account Security Auditing





Monitor user accounts for security issues.





User Security Audit







#!/bin/bash
# audit-users.sh

echo "WordPress User Security Audit"
echo "=============================="

# Check for users with admin privileges
echo "Administrator Accounts:"
wp user list --role=administrator --format=table --fields=ID,user_login,user_email,user_registered

ADMIN_COUNT=$(wp user list --role=administrator --format=count)
if [ "$ADMIN_COUNT" -gt 3 ]; then
    echo "⚠ WARNING: $ADMIN_COUNT administrator accounts (recommended: 1-2)"
fi

echo ""

# Check for weak usernames
echo "Checking for common/weak usernames..."
WEAK_USERS=("admin" "administrator" "root" "test" "demo")

for USERNAME in "${WEAK_USERS[@]}"; do
    if wp user get "$USERNAME" &>/dev/null; then
        echo "✗ WARNING: Common username detected: $USERNAME"
        echo "  Recommended: Delete or rename this account"
    fi
done

echo ""

# Check for inactive admin accounts
echo "Inactive Administrator Accounts (no posts/pages):"
wp user list --role=administrator --format=json | \
    jq -r '.[] | select(.posts == "0") | "- \(.user_login) (registered: \(.user_registered))"'

echo ""

# Check user capabilities
echo "Users with 'delete_users' capability:"
wp user list --format=json | \
    jq -r '.[] | select(.roles[] | contains("administrator")) | .user_login'







Password Policy Check







#!/bin/bash
# check-password-policy.sh

echo "Password Policy Check"
echo "===================="

# This requires custom code to check password strength
# WordPress doesn't expose password hashes via WP-CLI for security

# Check for recent password changes
echo "Users who haven't changed password recently:"
# This would require custom user meta tracking

# Check for 2FA status (if plugin installed)
if wp plugin is-installed two-factor; then
    echo "2FA Status:"
    wp user list --format=json | \
        jq -r '.[] | "\(.user_login): \(if .two_factor_enabled then "Enabled" else "DISABLED" end)"'
fi

# List users who can install plugins/themes
echo ""
echo "Users with plugin/theme installation privileges:"
wp user list --role=administrator,editor --format=csv --fields=user_login,roles







Comprehensive Security Report





Generate complete security assessment reports.





Master Security Script







#!/bin/bash
# comprehensive-security-check.sh

REPORT_FILE="/tmp/wordpress-security-report-$(date +%Y%m%d).txt"
LOG_FILE="/var/log/wp-security.log"

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

{
    echo "WordPress Comprehensive Security Report"
    echo "========================================"
    echo "Generated: $(date)"
    echo "Server: $(hostname)"
    echo ""

    # Core integrity
    echo "1. Core File Integrity"
    echo "----------------------"
    if wp core verify-checksums; then
        echo "✓ PASS: Core files verified"
    else
        echo "✗ FAIL: Core file modifications detected"
    fi
    echo ""

    # Plugin security
    echo "2. Plugin Security"
    echo "------------------"
    PLUGIN_UPDATES=$(wp plugin list --update=available --format=count)
    echo "Plugins needing updates: $PLUGIN_UPDATES"

    if [ "$PLUGIN_UPDATES" -eq 0 ]; then
        echo "✓ PASS: All plugins up to date"
    else
        echo "⚠ WARNING: Plugin updates available"
        wp plugin list --update=available --format=table --fields=name,version,update_version
    fi
    echo ""

    # Theme security
    echo "3. Theme Security"
    echo "-----------------"
    THEME_UPDATES=$(wp theme list --update=available --format=count)
    echo "Themes needing updates: $THEME_UPDATES"
    echo ""

    # User accounts
    echo "4. User Account Security"
    echo "------------------------"
    ADMIN_COUNT=$(wp user list --role=administrator --format=count)
    echo "Administrator accounts: $ADMIN_COUNT"

    if [ "$ADMIN_COUNT" -gt 3 ]; then
        echo "⚠ WARNING: Too many administrator accounts"
    else
        echo "✓ PASS: Administrator count acceptable"
    fi
    echo ""

    # SSL/HTTPS check
    echo "5. SSL/HTTPS Configuration"
    echo "--------------------------"
    SITE_URL=$(wp option get siteurl)
    if [[ "$SITE_URL" == https://* ]]; then
        echo "✓ PASS: HTTPS enabled"
    else
        echo "✗ FAIL: Site not using HTTPS"
    fi
    echo ""

    # File permissions
    echo "6. File Permissions"
    echo "-------------------"
    INSECURE_FILES=$(find . -type f -perm 0777 | wc -l)
    echo "Files with 777 permissions: $INSECURE_FILES"

    if [ "$INSECURE_FILES" -eq 0 ]; then
        echo "✓ PASS: No files with overly permissive permissions"
    else
        echo "⚠ WARNING: Insecure file permissions detected"
    fi
    echo ""

    # WordPress version
    echo "7. WordPress Version"
    echo "--------------------"
    CURRENT_VERSION=$(wp core version)
    LATEST_VERSION=$(wp core check-update --format=json | jq -r '.[0].version // empty')

    echo "Current version: $CURRENT_VERSION"
    echo "Latest version: ${LATEST_VERSION:-$CURRENT_VERSION}"

    if [ -z "$LATEST_VERSION" ]; then
        echo "✓ PASS: WordPress is up to date"
    else
        echo "⚠ WARNING: WordPress update available"
    fi

} > "$REPORT_FILE"

log "Security report generated: $REPORT_FILE"

# Email report
mail -s "WordPress Security Report - $(hostname)" admin@example.com < "$REPORT_FILE"

echo "✓ Security report complete: $REPORT_FILE"







Automated Scheduling





Run security scans automatically with cron.





Cron Configuration







# Add to crontab: crontab -e

# Daily core integrity check at 2 AM
0 2 * * * /usr/local/bin/verify-core-integrity.sh >> /var/log/wp-security.log 2>&1

# Daily vulnerability scan at 3 AM
0 3 * * * /usr/local/bin/scan-vulnerabilities.sh >> /var/log/wp-security.log 2>&1

# Daily file change detection at 4 AM
0 4 * * * /usr/local/bin/detect-file-changes.sh >> /var/log/wp-security.log 2>&1

# Weekly comprehensive security report (Mondays at 8 AM)
0 8 * * 1 /usr/local/bin/comprehensive-security-check.sh

# Monthly user audit (first day of month)
0 9 1 * * /usr/local/bin/audit-users.sh | mail -s "Monthly User Audit" admin@example.com







Learn about WordPress security monitoring.





Next Steps





You now have automated WordPress security scanning and monitoring capabilities with WP-CLI.









Week 1: Core security





    

  • Implement core integrity checks
    • 




  • Set up vulnerability scanning
    • 




  • Test alerting systems
    • 






Week 2: File monitoring





    

  • Create file baselines
    • 




  • Configure change detection
    • 




  • Add malware scanning
    • 






Week 3: User security





    

  • Audit user accounts
    • 




  • Check permissions
    • 




  • Implement password policies
    • 






Week 4: Automation





    

  • Schedule all security checks
    • 




  • Configure comprehensive reports
    • 




  • Integrate with monitoring tools
    • 






Advanced Topics





    

  1. Intrusion Detection Systems – Advanced threat detection
    2. 




  2. Security Information and Event Management (SIEM) – Centralized security monitoring
    3. 




  3. Automated Incident Response – Automatic threat mitigation
    4. 






Get More Resources





Download security scripts including:





    

  • Complete scanning system
    • 




  • Monitoring tools
    • 




  • Report templates
    • 






Join our email course for:





    

  • Weekly WP-CLI tutorials
    • 




  • Security best practices
    • 




  • Threat response strategies
    • 






Conclusion





Automated WordPress security scanning with WP-CLI provides continuous protection against vulnerabilities, malware, and unauthorized changes—detecting threats before they compromise your sites.





What we covered:





✅ Core file integrity verification 
✅ Plugin and theme vulnerability detection 
✅ File change monitoring and alerting 
✅ Malware pattern scanning 
✅ User account security auditing 
✅ Comprehensive automated security reports





Implement these security automation systems, and you’ll detect threats immediately—protecting WordPress sites 24/7 without constant manual monitoring.





Ready for more? Learn incident response or WordPress hardening.





Questions about WordPress security automation? Drop a comment below!





Found this helpful? Share with other WordPress administrators.


The post Automate WordPress Security Scanning and Monitoring with WP-CLI appeared first on WP-CLI Mastery.

]]>
					
		
		
			
		
		Build a WordPress Deployment Pipeline with WP-CLI and Bash
		https://wpclimastery.com/blog/build-a-wordpress-deployment-pipeline-with-wp-cli-and-bash/
		
		
		Tue, 10 Feb 2026 09:00:00 +0000
				
		
		
		
		
		
		https://wpclimastery.com/?p=164

					Deploying WordPress changes manually means FTPing files, manually importing databases, running SQL updates, and crossing your fingers that nothing breaks. One mistake during deployment takes your production site offline during...


The post Build a WordPress Deployment Pipeline with WP-CLI and Bash appeared first on WP-CLI Mastery.

]]>
										Deploying WordPress changes manually means FTPing files, manually importing databases, running SQL updates, and crossing your fingers that nothing breaks. One mistake during deployment takes your production site offline during peak traffic hours.





A WordPress deployment pipeline automates the entire process—code changes flow from development through testing to production automatically, with safety checks, automated testing, rollback capability, and zero downtime. Deploy confidently dozens of times per day.





In this guide, you’ll build a complete WordPress deployment pipeline using WP-CLI and Bash, from basic scripts to production-ready systems used by professional WordPress development teams.





Why Build a Deployment Pipeline?





Manual WordPress deployments don’t scale and introduce human error at every step.





Problems with Manual Deployment





Error-prone: Manual file transfers and database updates cause mistakes.





Downtime: Sites go offline during deployments affecting users and revenue.





No testing: Changes deploy directly to production without validation.





Slow: Manual deployments take 30-60 minutes of focused work.





No rollback: Fixing failed deployments requires manual restoration from backups.





Deployment Pipeline Benefits





Automated: One command deploys entire release from development to production.





Zero downtime: Users never see maintenance pages or errors.





Tested: Automated tests catch issues before they reach production.





Fast: Complete deployments in under 5 minutes instead of hours.





Reversible: Instant rollback to previous version if issues occur.





According to DevOps Research, teams with deployment pipelines deploy 200x more frequently with 24x faster recovery times.





Deployment Pipeline Components





Understand the stages of a WordPress deployment pipeline.





Basic Pipeline Stages







1. Development  → Code changes made locally
2. Testing      → Automated tests verify changes
3. Staging      → Deploy to staging environment
4. Validation   → Manual/automated verification
5. Production   → Deploy to live site
6. Monitoring   → Track deployment health







Essential Pipeline Elements





Version Control: Git tracks all changes and enables rollback.





Database Migrations: Automated schema and data updates.





Asset Building: Compile CSS, minify JavaScript, optimize images.





Environment Config: Different settings for dev/staging/production.





Health Checks: Verify deployment succeeded before completing.





Rollback Strategy: Quick recovery from failed deployments.





Learn about continuous deployment principles.





Basic Deployment Script





Start with a simple automated deployment workflow.





Manual Deployment Process







#!/bin/bash
# deploy-wordpress.sh - Basic deployment script

set -euo pipefail

REPO_URL="git@github.com:yourcompany/wordpress-site.git"
DEPLOY_PATH="/var/www/production"
BRANCH="main"

cd "$DEPLOY_PATH"

echo "Starting deployment..."

# Pull latest code
git fetch origin
git reset --hard "origin/$BRANCH"

# Install/update dependencies
composer install --no-dev --optimize-autoloader

# Run database migrations
wp db migrate

# Clear caches
wp cache flush
wp rewrite flush

# Build assets (if needed)
npm run build

echo "✓ Deployment complete"







Deployment with Backup







#!/bin/bash
# deploy-with-backup.sh

set -euo pipefail

DEPLOY_PATH="/var/www/production"
BACKUP_DIR="/backups/deployments"
DATE=$(date +%Y%m%d_%H%M%S)

cd "$DEPLOY_PATH"

# Create pre-deployment backup
echo "Creating backup..."
mkdir -p "$BACKUP_DIR"

wp db export "$BACKUP_DIR/db-$DATE.sql.gz"
git rev-parse HEAD > "$BACKUP_DIR/git-commit-$DATE.txt"

# Deploy
echo "Deploying..."
git pull origin main

composer install --no-dev

# Database updates
wp db migrate || {
    echo "Migration failed, rolling back..."
    wp db import "$BACKUP_DIR/db-$DATE.sql.gz"
    git reset --hard $(cat "$BACKUP_DIR/git-commit-$DATE.txt")
    exit 1
}

# Clear caches
wp cache flush

echo "✓ Deployment complete"
echo "Backup: $BACKUP_DIR/db-$DATE.sql.gz"







Staging to Production Pipeline





Deploy changes from staging environment to production safely.





Complete Staging Deploy







#!/bin/bash
# deploy-staging-to-production.sh

set -euo pipefail

STAGING_PATH="/var/www/staging"
PROD_PATH="/var/www/production"
BACKUP_DIR="/backups/production"
DATE=$(date +%Y%m%d_%H%M%S)

echo "=== Staging to Production Deployment ==="

# Step 1: Backup production
echo "Step 1/6: Backing up production..."
cd "$PROD_PATH"

wp db export "$BACKUP_DIR/db-$DATE.sql.gz"
tar -czf "$BACKUP_DIR/files-$DATE.tar.gz" \
    wp-content/plugins \
    wp-content/themes \
    wp-content/uploads

echo "✓ Backup complete"

# Step 2: Get staging code version
echo "Step 2/6: Getting staging version..."
cd "$STAGING_PATH"
STAGING_COMMIT=$(git rev-parse HEAD)
echo "Staging commit: $STAGING_COMMIT"

# Step 3: Deploy code to production
echo "Step 3/6: Deploying code..."
cd "$PROD_PATH"

# Enable maintenance mode
wp maintenance-mode activate

git fetch origin
git reset --hard "$STAGING_COMMIT"

# Step 4: Install dependencies
echo "Step 4/6: Installing dependencies..."
composer install --no-dev --no-interaction

# Build assets
npm run build

# Step 5: Run database migrations
echo "Step 5/6: Running database migrations..."
if ! wp db migrate; then
    echo "✗ Migration failed, rolling back..."
    wp db import "$BACKUP_DIR/db-$DATE.sql.gz"
    wp maintenance-mode deactivate
    exit 1
fi

# Step 6: Final checks and cleanup
echo "Step 6/6: Final checks..."

# Verify WordPress works
if ! wp core is-installed; then
    echo "✗ WordPress check failed, rolling back..."
    wp db import "$BACKUP_DIR/db-$DATE.sql.gz"
    wp maintenance-mode deactivate
    exit 1
fi

# Clear caches
wp cache flush
wp rewrite flush

# Disable maintenance mode
wp maintenance-mode deactivate

echo "=== Deployment Complete ==="
echo "Deployed commit: $STAGING_COMMIT"
echo "Backup: $BACKUP_DIR/db-$DATE.sql.gz"







Automated Validation







#!/bin/bash
# validate-deployment.sh

SITE_URL="$1"

echo "Validating deployment..."

# Test homepage
HTTP_CODE=$(curl -s -o /dev/null -w "%{http_code}" "$SITE_URL")
if [ "$HTTP_CODE" != "200" ]; then
    echo "✗ Homepage failed: HTTP $HTTP_CODE"
    exit 1
fi
echo "✓ Homepage accessible"

# Test admin
ADMIN_CODE=$(curl -s -o /dev/null -w "%{http_code}" "$SITE_URL/wp-admin/")
if [ "$ADMIN_CODE" != "200" ] && [ "$ADMIN_CODE" != "302" ]; then
    echo "✗ Admin failed: HTTP $ADMIN_CODE"
    exit 1
fi
echo "✓ Admin accessible"

# Test critical pages
for PAGE in "/about" "/contact" "/shop"; do
    CODE=$(curl -s -o /dev/null -w "%{http_code}" "$SITE_URL$PAGE")
    if [ "$CODE" = "200" ]; then
        echo "✓ $PAGE accessible"
    else
        echo "⚠ $PAGE returned HTTP $CODE"
    fi
done

echo "✓ Validation complete"







Zero-Downtime Deployment





Deploy without taking the site offline.











#!/bin/bash
# zero-downtime-deploy.sh

set -euo pipefail

DEPLOY_BASE="/var/www/releases"
CURRENT_LINK="/var/www/current"
SHARED_DIR="/var/www/shared"
RELEASE_ID=$(date +%Y%m%d_%H%M%S)
RELEASE_PATH="$DEPLOY_BASE/$RELEASE_ID"

echo "=== Zero-Downtime Deployment ==="
echo "Release ID: $RELEASE_ID"

# Create new release directory
mkdir -p "$RELEASE_PATH"
cd "$RELEASE_PATH"

# Clone code
git clone --depth 1 git@github.com:yourcompany/site.git .

# Link shared directories
ln -s "$SHARED_DIR/wp-content/uploads" wp-content/uploads
ln -s "$SHARED_DIR/wp-config.php" wp-config.php

# Install dependencies
composer install --no-dev

# Build assets
npm run build

# Database migrations (on shared database)
cd "$SHARED_DIR"
wp db migrate --path="$RELEASE_PATH"

# Atomic switch to new release
ln -sfn "$RELEASE_PATH" "$CURRENT_LINK"

# Webserver points to /var/www/current

# Cleanup old releases (keep last 5)
cd "$DEPLOY_BASE"
ls -t | tail -n +6 | xargs rm -rf

echo "✓ Deployment complete"
echo "Current release: $RELEASE_ID"







Blue-Green Deployment







#!/bin/bash
# blue-green-deploy.sh

BLUE_PATH="/var/www/blue"
GREEN_PATH="/var/www/green"
CURRENT_LINK="/var/www/current"

# Determine inactive environment
if [ "$(readlink $CURRENT_LINK)" = "$BLUE_PATH" ]; then
    INACTIVE="$GREEN_PATH"
    INACTIVE_NAME="green"
else
    INACTIVE="$BLUE_PATH"
    INACTIVE_NAME="blue"
fi

echo "Deploying to inactive environment: $INACTIVE_NAME"

cd "$INACTIVE"

# Deploy to inactive
git pull origin main
composer install --no-dev
npm run build

# Test inactive environment
if curl -f "http://localhost:8080" > /dev/null 2>&1; then
    echo "✓ Inactive environment healthy"
else
    echo "✗ Inactive environment failed health check"
    exit 1
fi

# Switch traffic to new version
ln -sfn "$INACTIVE" "$CURRENT_LINK"

# Reload webserver
systemctl reload nginx

echo "✓ Switched to $INACTIVE_NAME environment"







Learn about zero-downtime deployment strategies.





Database Migration Handling





Safely manage database schema changes during deployments.





Migration System







#!/bin/bash
# db-migrate.sh - Run database migrations

MIGRATIONS_DIR="/var/www/db/migrations"
APPLIED_FILE="/var/www/db/applied-migrations.txt"

touch "$APPLIED_FILE"

echo "Running database migrations..."

for MIGRATION in $(ls "$MIGRATIONS_DIR"/*.sql | sort); do
    MIGRATION_NAME=$(basename "$MIGRATION")

    # Check if already applied
    if grep -q "$MIGRATION_NAME" "$APPLIED_FILE"; then
        echo "⊘ Skipping: $MIGRATION_NAME (already applied)"
        continue
    fi

    echo "Applying: $MIGRATION_NAME"

    # Run migration
    if wp db query < "$MIGRATION"; then
        echo "$MIGRATION_NAME" >> "$APPLIED_FILE"
        echo "✓ Applied: $MIGRATION_NAME"
    else
        echo "✗ Failed: $MIGRATION_NAME"
        exit 1
    fi
done

echo "✓ All migrations applied"







Reversible Migrations







# Migration file structure
# migrations/001-add-custom-table.sql (up)
# migrations/001-add-custom-table-rollback.sql (down)

#!/bin/bash
# rollback-migration.sh

MIGRATION_ID="$1"
MIGRATIONS_DIR="/var/www/db/migrations"

ROLLBACK_FILE="$MIGRATIONS_DIR/${MIGRATION_ID}-rollback.sql"

if [ ! -f "$ROLLBACK_FILE" ]; then
    echo "✗ Rollback file not found: $ROLLBACK_FILE"
    exit 1
fi

echo "Rolling back migration: $MIGRATION_ID"
wp db query < "$ROLLBACK_FILE"

echo "✓ Rollback complete"







Deployment Notifications





Alert teams about deployment status.





Slack Notifications







#!/bin/bash
# notify-deployment.sh

SLACK_WEBHOOK="https://hooks.slack.com/services/YOUR/WEBHOOK/URL"
STATUS="$1"  # success or failure
COMMIT="$2"
DEPLOYER="$3"

if [ "$STATUS" = "success" ]; then
    COLOR="good"
    MESSAGE="Deployment successful"
else
    COLOR="danger"
    MESSAGE="Deployment failed"
fi

curl -X POST "$SLACK_WEBHOOK" \
    -H 'Content-Type: application/json' \
    -d "{
        \"attachments\": [{
            \"color\": \"$COLOR\",
            \"title\": \"$MESSAGE\",
            \"fields\": [
                {\"title\": \"Environment\", \"value\": \"Production\", \"short\": true},
                {\"title\": \"Commit\", \"value\": \"$COMMIT\", \"short\": true},
                {\"title\": \"Deployed by\", \"value\": \"$DEPLOYER\", \"short\": true}
            ]
        }]
    }"







Email Notifications







#!/bin/bash
# email-deployment-report.sh

EMAIL="team@example.com"
STATUS="$1"
DETAILS="$2"

SUBJECT="WordPress Deployment $STATUS"

cat <<EOF | mail -s "$SUBJECT" "$EMAIL"
WordPress Deployment Report
===========================

Status: $STATUS
Time: $(date)
Server: $(hostname)
Deployed by: $(whoami)

Details:
$DETAILS

Automated deployment system
EOF







Complete Production Pipeline





Integrate all components into a complete system.





Master Deployment Script







#!/bin/bash
# deploy.sh - Complete deployment pipeline

set -euo pipefail

ENVIRONMENT="${1:-staging}"
LOG_FILE="/var/log/deployments/deploy-$(date +%Y%m%d-%H%M%S).log"

mkdir -p "$(dirname $LOG_FILE)"

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

notify() {
    ./notify-deployment.sh "$1" "$2" "$(whoami)"
}

log "=== Deployment Started ==="
log "Environment: $ENVIRONMENT"

# Pre-deployment checks
log "Running pre-deployment checks..."
./pre-deploy-check.sh "$ENVIRONMENT" || {
    log "✗ Pre-deployment checks failed"
    notify "failure" "Pre-deployment checks failed"
    exit 1
}

# Backup
log "Creating backup..."
./backup.sh "$ENVIRONMENT"

# Deploy code
log "Deploying code..."
./deploy-code.sh "$ENVIRONMENT" || {
    log "✗ Code deployment failed"
    ./rollback.sh "$ENVIRONMENT"
    notify "failure" "Code deployment failed"
    exit 1
}

# Database migrations
log "Running database migrations..."
./db-migrate.sh || {
    log "✗ Database migration failed"
    ./rollback.sh "$ENVIRONMENT"
    notify "failure" "Database migration failed"
    exit 1
}

# Post-deployment validation
log "Validating deployment..."
./validate-deployment.sh "$ENVIRONMENT" || {
    log "✗ Validation failed"
    ./rollback.sh "$ENVIRONMENT"
    notify "failure" "Deployment validation failed"
    exit 1
}

# Success
log "=== Deployment Complete ==="
notify "success" "Deployment to $ENVIRONMENT successful"

echo "✓ Deployment successful"
echo "Log: $LOG_FILE"







Next Steps





You now have a complete WordPress deployment pipeline built with WP-CLI and Bash.









Week 1: Basic automation





    

  • Create simple deploy scripts
    • 




  • Add backup mechanisms
    • 




  • Implement rollback procedures
    • 






Week 2: Testing integration





    

  • Add validation checks
    • 




  • Create health checks
    • 




  • Automate testing
    • 






Week 3: Zero-downtime





    

  • Implement symlink strategy
    • 




  • Set up blue-green deployment
    • 




  • Test switching mechanisms
    • 






Week 4: Production hardening





    

  • Add monitoring
    • 




  • Implement notifications
    • 




  • Document procedures
    • 






Advanced Topics





    

  1. Container Deployments – Docker-based pipelines
    2. 




  2. GitOps Workflows – Git-driven deployments
    3. 




  3. Multi-Region Deployment – Global site deployment
    4. 






Get More Resources





Download deployment scripts including:





    

  • Complete pipeline system
    • 




  • Testing frameworks
    • 




  • Rollback automation
    • 






Join our email course for:





    

  • Weekly WP-CLI tutorials
    • 




  • DevOps best practices
    • 




  • Deployment strategies
    • 






Conclusion





A WordPress deployment pipeline transforms risky manual deployments into reliable, automated workflows that enable rapid, confident releases to production.





What we covered:





✅ Deployment pipeline components and stages 
✅ Basic deployment automation with backups 
✅ Staging to production workflows 
✅ Zero-downtime deployment strategies 
✅ Database migration handling 
✅ Complete production pipeline integration





Master these techniques, and you’ll deploy WordPress changes confidently dozens of times per day with zero downtime and instant rollback capability.





Ready for more? Learn continuous integration or infrastructure as code.





Questions about WordPress deployment pipelines? Drop a comment below!





Found this helpful? Share with other WordPress DevOps teams.


The post Build a WordPress Deployment Pipeline with WP-CLI and Bash appeared first on WP-CLI Mastery.

]]>
					
		
		
			
		
		Bulk Content Operations in WordPress: WP-CLI Advanced Techniques
		https://wpclimastery.com/blog/bulk-content-operations-in-wordpress-wp-cli-advanced-techniques/
		
		
		Thu, 05 Feb 2026 09:00:00 +0000
				
		
		
		
		
		
		https://wpclimastery.com/?p=141

					Managing hundreds or thousands of WordPress posts through the admin panel is impossible—updating categories across 500 posts, changing authors on old content, or adding custom fields to existing articles wastes...


The post Bulk Content Operations in WordPress: WP-CLI Advanced Techniques appeared first on WP-CLI Mastery.

]]>
										Managing hundreds or thousands of WordPress posts through the admin panel is impossible—updating categories across 500 posts, changing authors on old content, or adding custom fields to existing articles wastes days of manual clicking.





WP-CLI transforms bulk content operations from tedious manual work into fast, scriptable workflows. Update unlimited posts with one command, batch-assign taxonomies, transform content structure, and automate complex content management tasks.





In this guide, you’ll learn advanced WP-CLI techniques for bulk content operations used by high-volume WordPress publishers managing thousands of posts efficiently.





Why Bulk Content Operations Matter





WordPress content management at scale requires automation—manual operations don’t work beyond 50-100 posts.





Problems with Manual Bulk Editing





Time-consuming: Updating 1,000 posts manually takes weeks of repetitive work.





Error-prone: Manual operations introduce inconsistencies and mistakes.





Limited scope: Can’t perform complex transformations or conditional updates.





No validation: Can’t preview changes before executing them.





Not repeatable: Can’t reuse workflows or share processes with team.





WP-CLI Bulk Operation Advantages





Lightning fast: Update 10,000 posts in minutes instead of weeks.





Scriptable: Save complex operations as reusable scripts.





Conditional logic: Update only posts matching specific criteria.





Preview mode: Test operations before executing on production data.





Audit trails: Log all changes for compliance and debugging.





According to content management studies, sites with 1,000+ posts save 40+ hours monthly with automated bulk operations.





Bulk Post Status Operations





Manage post publication status at scale.





Bulk Status Changes







# Publish all drafts
wp post update $(wp post list --post_status=draft --format=ids) --post_status=publish

# Draft all scheduled posts
wp post update $(wp post list --post_status=future --format=ids) --post_status=draft

# Unpublish posts older than 2 years
wp post list --post_status=publish --before="2 years ago" --format=ids | xargs wp post update --post_status=draft

# Archive old posts (change status)
YEAR_AGO=$(date -d "1 year ago" +%Y-%m-%d)
wp post update $(wp post list --post_status=publish --before="$YEAR_AGO" --format=ids) --post_status=private







Conditional Status Updates







#!/bin/bash
# update-post-status-by-category.sh

CATEGORY_ID=5  # Posts in this category
TARGET_STATUS="draft"

# Get posts in specific category
POSTS=$(wp post list --category_id=$CATEGORY_ID --post_status=publish --format=ids)

if [ -z "$POSTS" ]; then
    echo "No posts found in category $CATEGORY_ID"
    exit 0
fi

# Count posts
COUNT=$(echo $POSTS | wc -w)
echo "Found $COUNT posts to update"

# Update status
wp post update $POSTS --post_status=$TARGET_STATUS

echo "✓ Updated $COUNT posts to $TARGET_STATUS status"







Learn more about WordPress post statuses.





Bulk Taxonomy Assignment





Assign categories, tags, and custom taxonomies in bulk.





Bulk Category Operations







# Add category to all posts
CATEGORY_ID=10
for post_id in $(wp post list --format=ids); do
    wp post term add $post_id category $CATEGORY_ID
done

# Remove category from all posts
for post_id in $(wp post list --format=ids); do
    wp post term remove $post_id category 3
done

# Replace category across posts
OLD_CAT=5
NEW_CAT=10
POSTS=$(wp post list --category=$OLD_CAT --format=ids)

for post_id in $POSTS; do
    wp post term remove $post_id category $OLD_CAT
    wp post term add $post_id category $NEW_CAT
done

echo "✓ Category replacement complete"







Bulk Tag Operations







# Add tags to all posts without tags
wp post list --format=ids | while read post_id; do
    TAG_COUNT=$(wp post term list $post_id post_tag --format=count)

    if [ "$TAG_COUNT" -eq 0 ]; then
        echo "Adding tags to post $post_id"
        wp post term add $post_id post_tag "general,uncategorized"
    fi
done

# Remove all tags from specific category
POSTS=$(wp post list --category_name="old-news" --format=ids)
for post_id in $POSTS; do
    wp post term remove $post_id post_tag --all
done







Smart Auto-Categorization







#!/bin/bash
# auto-categorize-by-keywords.sh - Assign categories based on content

# Define keyword-to-category mapping
declare -A KEYWORDS=(
    ["WordPress"]="5"
    ["security"]="8"
    ["performance"]="12"
    ["tutorial"]="15"
)

# Search for keywords and assign categories
for KEYWORD in "${!KEYWORDS[@]}"; do
    CAT_ID="${KEYWORDS[$KEYWORD]}"

    echo "Processing keyword: $KEYWORD → Category $CAT_ID"

    # Find posts containing keyword
    POSTS=$(wp post list --s="$KEYWORD" --post_status=publish --format=ids)

    for post_id in $POSTS; do
        # Check if category already assigned
        HAS_CAT=$(wp post term list $post_id category --field=term_id | grep -c "^${CAT_ID}
quot;)

        if [ "$HAS_CAT" -eq 0 ]; then
            echo "  Adding category $CAT_ID to post $post_id"
            wp post term add $post_id category $CAT_ID
        fi
    done
done

echo "✓ Auto-categorization complete"







Bulk Author Updates





Reassign post authorship in bulk.





Change Post Authors







# Reassign all posts from one author to another
OLD_AUTHOR_ID=5
NEW_AUTHOR_ID=1

wp post update $(wp post list --author=$OLD_AUTHOR_ID --format=ids) --post_author=$NEW_AUTHOR_ID

# Update posts by author email
OLD_EMAIL="old@example.com"
NEW_AUTHOR_ID=2

OLD_AUTHOR=$(wp user list --user_email=$OLD_EMAIL --field=ID)
wp post update $(wp post list --author=$OLD_AUTHOR --format=ids) --post_author=$NEW_AUTHOR_ID







Distribute Posts Across Authors







#!/bin/bash
# distribute-posts.sh - Evenly distribute posts across authors

AUTHORS=(2 5 8 12)  # Author IDs
POSTS=$(wp post list --post_status=publish --format=ids)

# Convert to array
POST_ARRAY=($POSTS)
TOTAL_POSTS=${#POST_ARRAY[@]}
AUTHOR_COUNT=${#AUTHORS[@]}

echo "Distributing $TOTAL_POSTS posts across $AUTHOR_COUNT authors..."

INDEX=0
for post_id in "${POST_ARRAY[@]}"; do
    AUTHOR_INDEX=$((INDEX % AUTHOR_COUNT))
    AUTHOR_ID=${AUTHORS[$AUTHOR_INDEX]}

    wp post update $post_id --post_author=$AUTHOR_ID

    ((INDEX++))
done

echo "✓ Post distribution complete"







Bulk Post Meta Operations





Add, update, or delete custom fields across posts.





Add Meta to All Posts







# Add custom field to all posts
for post_id in $(wp post list --format=ids); do
    wp post meta add $post_id featured_priority "normal"
done

# Add meta only to posts without it
for post_id in $(wp post list --format=ids); do
    if ! wp post meta get $post_id custom_field &>/dev/null; then
        wp post meta add $post_id custom_field "default_value"
    fi
done







Update Meta in Bulk







# Update meta for posts in specific category
POSTS=$(wp post list --category_name="premium" --format=ids)

for post_id in $POSTS; do
    wp post meta update $post_id access_level "premium"
    wp post meta update $post_id show_ads "false"
done

# Conditional meta update
for post_id in $(wp post list --format=ids); do
    OLD_VALUE=$(wp post meta get $post_id old_field 2>/dev/null)

    if [ -n "$OLD_VALUE" ]; then
        wp post meta add $post_id new_field "$OLD_VALUE"
        wp post meta delete $post_id old_field
    fi
done







Clean Orphaned Meta







#!/bin/bash
# clean-post-meta.sh - Remove meta from deleted posts

echo "Cleaning orphaned post meta..."

# SQL query to find orphaned meta
wp db query "
DELETE FROM wp_postmeta
WHERE post_id NOT IN (
    SELECT ID FROM wp_posts
)
"

echo "✓ Orphaned post meta cleaned"







Learn about WordPress custom fields.





Content Transformation Operations





Transform post content structure and format.





Bulk Content Search-Replace







# Replace text in all post content
wp search-replace "old company name" "new company name" wp_posts --dry-run
wp search-replace "old company name" "new company name" wp_posts

# Update image URLs
wp search-replace "http://oldcdn.com" "https://newcdn.com" wp_posts

# Fix broken shortcodes
wp search-replace "[old_shortcode" "[new_shortcode" wp_posts







Add Content Prefix/Suffix







#!/bin/bash
# add-content-notice.sh - Add notice to all posts

NOTICE='<div class="post-notice">This article was published over a year ago.</div>'

# Get posts older than 1 year
POSTS=$(wp post list --before="1 year ago" --post_status=publish --format=ids)

for post_id in $POSTS; do
    CONTENT=$(wp post get $post_id --field=post_content)

    # Check if notice already exists
    if [[ ! "$CONTENT" =~ "post-notice" ]]; then
        NEW_CONTENT="${NOTICE}${CONTENT}"

        wp post update $post_id --post_content="$NEW_CONTENT"
        echo "Added notice to post $post_id"
    fi
done

echo "✓ Content notices added"







Convert Post Types







# Convert posts to pages
for post_id in $(wp post list --post_type=post --format=ids); do
    wp post update $post_id --post_type=page
done

# Convert pages back to posts
for post_id in $(wp post list --post_type=page --format=ids); do
    wp post update $post_id --post_type=post --post_category=1
done







Bulk Post Cleanup





Remove unwanted content and maintain database health.





Delete Posts by Criteria







# Delete all drafts older than 6 months
wp post delete $(wp post list --post_status=draft --before="6 months ago" --format=ids) --force

# Delete empty posts
wp post delete $(wp post list --post_content="" --format=ids) --force

# Empty trash
wp post delete $(wp post list --post_status=trash --format=ids) --force

# Delete posts with specific meta
for post_id in $(wp post list --format=ids); do
    if wp post meta get $post_id spam_flag 2>/dev/null | grep -q "true"; then
        wp post delete $post_id --force
        echo "Deleted spam post: $post_id"
    fi
done







Clean Revisions







# Delete all revisions
wp post delete $(wp post list --post_type=revision --format=ids) --force

# Keep only last 5 revisions per post (requires custom logic)
#!/bin/bash
for post_id in $(wp post list --format=ids); do
    # Get revision IDs
    REVISIONS=$(wp post list --post_type=revision --post_parent=$post_id --orderby=date --order=DESC --format=ids)

    # Convert to array
    REV_ARRAY=($REVISIONS)

    # Delete all but first 5
    if [ ${#REV_ARRAY[@]} -gt 5 ]; then
        REVISIONS_TO_DELETE="${REV_ARRAY[@]:5}"
        wp post delete $REVISIONS_TO_DELETE --force
    fi
done







Scheduled Content Operations





Automate recurring bulk content tasks.





Auto-Publish Scheduled Script







#!/bin/bash
# auto-publish-oldest-draft.sh - Publish oldest draft daily

MAX_POSTS=${1:-1}

echo "Publishing up to $MAX_POSTS draft posts..."

DRAFTS=$(wp post list \
    --post_status=draft \
    --orderby=date \
    --order=ASC \
    --posts_per_page=$MAX_POSTS \
    --format=ids)

if [ -z "$DRAFTS" ]; then
    echo "No drafts available"
    exit 0
fi

for post_id in $DRAFTS; do
    TITLE=$(wp post get $post_id --field=post_title)
    echo "Publishing: $TITLE"

    wp post update $post_id \
        --post_status=publish \
        --post_date="$(date '+%Y-%m-%d %H:%M:%S')"
done

echo "✓ Publishing complete"







Schedule with cron:







# Publish 1 draft daily at 9 AM
0 9 * * * /usr/local/bin/auto-publish-oldest-draft.sh 1







Monthly Content Audit







#!/bin/bash
# monthly-content-audit.sh

REPORT="/tmp/content-audit-$(date +%Y%m).txt"

{
    echo "WordPress Content Audit Report"
    echo "Generated: $(date)"
    echo "=============================="
    echo ""

    echo "Total Posts: $(wp post list --post_type=post --format=count)"
    echo "Published: $(wp post list --post_status=publish --format=count)"
    echo "Drafts: $(wp post list --post_status=draft --format=count)"
    echo "Scheduled: $(wp post list --post_status=future --format=count)"
    echo ""

    echo "Posts by Category:"
    wp term list category --fields=name,count --format=table
    echo ""

    echo "Posts Without Categories:"
    wp post list --category=0 --format=count
    echo ""

    echo "Posts Without Tags:"
    for post_id in $(wp post list --format=ids | head -100); do
        TAG_COUNT=$(wp post term list $post_id post_tag --format=count)
        [ "$TAG_COUNT" -eq 0 ] && ((NO_TAGS++))
    done
    echo "${NO_TAGS:-0} posts"

} > "$REPORT"

# Email report
mail -s "Monthly Content Audit" admin@example.com < "$REPORT"

echo "✓ Audit report sent"







Next Steps





You now have advanced bulk content operation skills for WordPress at scale.









Week 1: Basic bulk operations





    

  • Practice post status updates
    • 




  • Master taxonomy assignments
    • 




  • Update post authors
    • 






Week 2: Advanced transformations





    

  • Content search-replace
    • 




  • Meta field operations
    • 




  • Post type conversions
    • 






Week 3: Cleanup automation





    

  • Delete unwanted content
    • 




  • Manage revisions
    • 




  • Orphaned data cleanup
    • 






Week 4: Scheduled workflows





    

  • Auto-publishing scripts
    • 




  • Content audits
    • 




  • Maintenance automation
    • 






Advanced Topics





    

  1. Custom Post Type Bulk Operations – Advanced CPT management
    2. 




  2. Multi-Site Content Sync – Network-wide operations
    3. 




  3. AI Content Enhancement – Automated content improvements
    4. 






Get More Resources





Download bulk operation scripts including:





    

  • Complete automation toolkit
    • 




  • Content transformation scripts
    • 




  • Cleanup utilities
    • 






Join our email course for:





    

  • Weekly WP-CLI tutorials
    • 




  • Content management strategies
    • 




  • Automation best practices
    • 






Conclusion





WP-CLI bulk content operations transform WordPress content management from manual drudgery into fast, automated workflows that handle any scale.





What we covered:





✅ Bulk post status and publication management 
✅ Taxonomy assignment and reorganization 
✅ Author reassignment and distribution 
✅ Post meta bulk operations 
✅ Content transformation and cleanup 
✅ Scheduled and automated workflows





Master these techniques, and you’ll manage thousands of WordPress posts as easily as managing ten—whether publishing content at scale or maintaining large content archives.





Ready for more? Learn WordPress content migration or automated content workflows.





Questions about bulk content operations in WordPress? Drop a comment below!





Found this helpful? Share with other WordPress content managers.


The post Bulk Content Operations in WordPress: WP-CLI Advanced Techniques appeared first on WP-CLI Mastery.

]]>
					
		
		
			
		
		Building a Complete WordPress Deployment System with WP-CLI (Real Project)
		https://wpclimastery.com/blog/building-a-complete-wordpress-deployment-system-with-wp-cli-real-project/
		
		
		Fri, 30 Jan 2026 09:00:00 +0000
				
		
		
		
		
		
		https://wpclimastery.com/?p=160

					Professional WordPress deployments require coordinating server provisioning, WordPress installation, plugin configuration, database migrations, zero-downtime releases, automated backups, health monitoring, and rollback capabilities. Managing these manually across development, staging, and production...


The post Building a Complete WordPress Deployment System with WP-CLI (Real Project) appeared first on WP-CLI Mastery.

]]>
										Professional WordPress deployments require coordinating server provisioning, WordPress installation, plugin configuration, database migrations, zero-downtime releases, automated backups, health monitoring, and rollback capabilities. Managing these manually across development, staging, and production environments is error-prone and time-consuming.





A complete WordPress deployment system automates the entire lifecycle—provision servers, install WordPress, deploy code changes, run migrations, monitor health, and rollback failures—all with single commands executed by WP-CLI and Bash scripts.





In this guide, you’ll build a production-ready WordPress deployment system used by professional development teams, integrating server provisioning, automated deployments, monitoring, and disaster recovery into one cohesive system.





System Architecture Overview





Understand the complete deployment system components and workflow.





Deployment System Components







┌─────────────────────┐
│  Version Control    │  ← Git repository (source of truth)
│      (Git)          │
└──────────┬──────────┘
           │
           ▼
┌─────────────────────┐
│  CI/CD Pipeline     │  ← GitHub Actions/GitLab CI
│   (Automated)       │
└──────────┬──────────┘
           │
           ▼
┌─────────────────────┐
│ Deployment Scripts  │  ← WP-CLI + Bash automation
│    (This System)    │
└──────────┬──────────┘
           │
    ┌──────┴──────┐
    │             │
    ▼             ▼
┌────────┐   ┌────────┐
│Staging │   │  Prod  │  ← WordPress environments
└────────┘   └────────┘







System Features





Server provisioning: Automated WordPress server setup from scratch.





Zero-downtime deploys: Release code without taking site offline.





Database migrations: Automatic schema changes with rollback.





Health monitoring: Continuous uptime and performance checks.





Automatic backups: Pre-deployment snapshots with retention policies.





One-command rollback: Instantly revert failed deployments.





Learn about DevOps deployment patterns.





Project Structure and Setup





Organize the deployment system codebase.





Directory Structure







wordpress-deploy-system/
├── bin/                      # Executable scripts
│   ├── deploy                # Main deployment command
│   ├── provision             # Server provisioning
│   ├── backup                # Backup management
│   ├── rollback              # Rollback deployments
│   └── monitor               # Health monitoring
├── lib/                      # Reusable functions
│   ├── common.sh             # Shared utilities
│   ├── deploy.sh             # Deployment logic
│   ├── database.sh           # DB operations
│   └── wordpress.sh          # WordPress operations
├── config/                   # Configuration files
│   ├── environments/         # Environment-specific configs
│   │   ├── development.conf
│   │   ├── staging.conf
│   │   └── production.conf
│   └── deploy.conf           # Global deployment config
├── migrations/               # Database migrations
│   ├── 001-initial-schema.sql
│   └── 002-add-custom-tables.sql
├── hooks/                    # Deployment hooks
│   ├── pre-deploy.sh
│   ├── post-deploy.sh
│   └── health-check.sh
├── logs/                     # Deployment logs
└── backups/                  # Backup storage







Installation Script







#!/bin/bash
# install.sh - Set up deployment system

INSTALL_DIR="/opt/wordpress-deploy"

echo "Installing WordPress Deployment System"
echo "======================================="

# Create directory structure
sudo mkdir -p "$INSTALL_DIR"/{bin,lib,config/environments,migrations,hooks,logs,backups}

# Copy files
sudo cp -r bin/* "$INSTALL_DIR/bin/"
sudo cp -r lib/* "$INSTALL_DIR/lib/"
sudo cp -r config/* "$INSTALL_DIR/config/"

# Make scripts executable
sudo chmod +x "$INSTALL_DIR"/bin/*
sudo chmod +x "$INSTALL_DIR"/hooks/*

# Add to PATH
echo "export PATH=\$PATH:$INSTALL_DIR/bin" | sudo tee -a /etc/profile.d/wordpress-deploy.sh

# Install WP-CLI if not present
if ! command -v wp &> /dev/null; then
    echo "Installing WP-CLI..."
    curl -O https://raw.githubusercontent.com/wp-cli/builds/gh-pages/phar/wp-cli.phar
    sudo mv wp-cli.phar /usr/local/bin/wp
    sudo chmod +x /usr/local/bin/wp
fi

echo "✓ Installation complete"
echo "Usage: deploy <environment> <release>"







Server Provisioning Automation





Automate complete WordPress server setup.





Provisioning Script







#!/bin/bash
# bin/provision - Provision WordPress server

set -euo pipefail

source "$(dirname "$0")/../lib/common.sh"

ENVIRONMENT="${1:-staging}"
CONFIG_FILE="$CONFIG_DIR/environments/$ENVIRONMENT.conf"

if [ ! -f "$CONFIG_FILE" ]; then
    error "Configuration not found: $CONFIG_FILE"
fi

source "$CONFIG_FILE"

log "Provisioning WordPress server for: $ENVIRONMENT"

# Update system packages
log "Updating system packages..."
sudo apt-get update
sudo apt-get upgrade -y

# Install LAMP stack
log "Installing LAMP stack..."
sudo apt-get install -y \
    nginx \
    mysql-server \
    php8.1-fpm \
    php8.1-mysql \
    php8.1-xml \
    php8.1-mbstring \
    php8.1-curl \
    php8.1-zip \
    php8.1-gd \
    php8.1-intl

# Configure Nginx
log "Configuring Nginx..."
sudo tee /etc/nginx/sites-available/wordpress <<EOF
server {
    listen 80;
    server_name $SERVER_NAME;
    root $DEPLOY_PATH/current;
    index index.php;

    location / {
        try_files \$uri \$uri/ /index.php?\$args;
    }

    location ~ \.php$ {
        fastcgi_pass unix:/var/run/php/php8.1-fpm.sock;
        fastcgi_index index.php;
        include fastcgi_params;
        fastcgi_param SCRIPT_FILENAME \$document_root\$fastcgi_script_name;
    }
}
EOF

sudo ln -sf /etc/nginx/sites-available/wordpress /etc/nginx/sites-enabled/
sudo nginx -t && sudo systemctl reload nginx

# Create deployment directories
log "Creating deployment directories..."
sudo mkdir -p "$DEPLOY_PATH"/{releases,shared}
sudo mkdir -p "$DEPLOY_PATH/shared"/{wp-content/uploads,logs}

# Set permissions
sudo chown -R www-data:www-data "$DEPLOY_PATH"
sudo chmod -R 755 "$DEPLOY_PATH"

# Create MySQL database
log "Creating WordPress database..."
sudo mysql <<EOF
CREATE DATABASE IF NOT EXISTS $DB_NAME;
CREATE USER IF NOT EXISTS '$DB_USER'@'localhost' IDENTIFIED BY '$DB_PASS';
GRANT ALL PRIVILEGES ON $DB_NAME.* TO '$DB_USER'@'localhost';
FLUSH PRIVILEGES;
EOF

# Install WordPress
log "Installing WordPress..."
cd "$DEPLOY_PATH"

wp core download --path=initial-install
cd initial-install

wp config create \
    --dbname="$DB_NAME" \
    --dbuser="$DB_USER" \
    --dbpass="$DB_PASS" \
    --dbhost=localhost

wp core install \
    --url="$SITE_URL" \
    --title="$SITE_TITLE" \
    --admin_user="$ADMIN_USER" \
    --admin_password="$ADMIN_PASS" \
    --admin_email="$ADMIN_EMAIL"

# Move to shared directory
mv wp-content/uploads/* "$DEPLOY_PATH/shared/wp-content/uploads/"
mv wp-config.php "$DEPLOY_PATH/shared/"

# Install SSL certificate (Let's Encrypt)
if [ "$SSL_ENABLED" = "true" ]; then
    log "Installing SSL certificate..."
    sudo apt-get install -y certbot python3-certbot-nginx
    sudo certbot --nginx -d "$SERVER_NAME" --non-interactive --agree-tos -m "$ADMIN_EMAIL"
fi

log "✓ Server provisioning complete"
log "WordPress URL: $SITE_URL"
log "Admin user: $ADMIN_USER"







Environment Configuration Template







# config/environments/production.conf

# Server settings
SERVER_NAME="example.com"
SITE_URL="https://example.com"
SITE_TITLE="Production Site"

# Deployment paths
DEPLOY_PATH="/var/www/production"
RELEASE_DIR="$DEPLOY_PATH/releases"
SHARED_DIR="$DEPLOY_PATH/shared"
CURRENT_LINK="$DEPLOY_PATH/current"

# Database credentials
DB_NAME="wp_production"
DB_USER="wp_user"
DB_PASS="strong-password-here"
DB_HOST="localhost"

# WordPress admin
ADMIN_USER="admin"
ADMIN_PASS="admin-password-here"
ADMIN_EMAIL="admin@example.com"

# Git repository
GIT_REPO="git@github.com:yourcompany/wordpress-site.git"
GIT_BRANCH="main"

# Deployment settings
KEEP_RELEASES=5
BACKUP_RETENTION_DAYS=30
SSL_ENABLED=true

# Notifications
SLACK_WEBHOOK="https://hooks.slack.com/services/YOUR/WEBHOOK/URL"
EMAIL_NOTIFICATIONS="team@example.com"







Learn about WordPress server requirements.





Zero-Downtime Deployment Implementation





Deploy code changes without taking site offline.





Main Deployment Script







#!/bin/bash
# bin/deploy - Main deployment command

set -euo pipefail

source "$(dirname "$0")/../lib/common.sh"
source "$(dirname "$0")/../lib/deploy.sh"

ENVIRONMENT="${1:-staging}"
RELEASE_TAG="${2:-HEAD}"
CONFIG_FILE="$CONFIG_DIR/environments/$ENVIRONMENT.conf"

if [ ! -f "$CONFIG_FILE" ]; then
    error "Configuration not found: $CONFIG_FILE"
fi

source "$CONFIG_FILE"

log "=== WordPress Deployment Started ==="
log "Environment: $ENVIRONMENT"
log "Release: $RELEASE_TAG"
log "Time: $(date)"

# Pre-deployment checks
log "Running pre-deployment checks..."
run_hook "pre-deploy" || error "Pre-deployment checks failed"

# Create backup
log "Creating pre-deployment backup..."
"$BIN_DIR/backup" "$ENVIRONMENT" || error "Backup failed"

# Prepare new release
RELEASE_ID=$(date +%Y%m%d_%H%M%S)
RELEASE_PATH="$RELEASE_DIR/$RELEASE_ID"

log "Creating release: $RELEASE_ID"
mkdir -p "$RELEASE_PATH"

# Clone code from Git
log "Cloning repository..."
git clone --depth 1 --branch "$GIT_BRANCH" "$GIT_REPO" "$RELEASE_PATH"
cd "$RELEASE_PATH"

# Install dependencies
log "Installing dependencies..."
if [ -f composer.json ]; then
    composer install --no-dev --optimize-autoloader
fi

if [ -f package.json ]; then
    npm ci --production
    npm run build
fi

# Link shared directories
log "Linking shared resources..."
ln -nfs "$SHARED_DIR/wp-content/uploads" "$RELEASE_PATH/wp-content/uploads"
ln -nfs "$SHARED_DIR/wp-config.php" "$RELEASE_PATH/wp-config.php"

# Run database migrations
log "Running database migrations..."
run_migrations "$RELEASE_PATH" || {
    error "Database migration failed"
    rollback_deployment "$ENVIRONMENT" "$RELEASE_ID"
    exit 1
}

# Health check on new release
log "Running health checks..."
test_release "$RELEASE_PATH" || {
    error "Health checks failed"
    rollback_deployment "$ENVIRONMENT" "$RELEASE_ID"
    exit 1
}

# Atomic switch to new release
log "Switching to new release..."
ln -nfs "$RELEASE_PATH" "$CURRENT_LINK"

# Post-deployment tasks
log "Running post-deployment tasks..."
cd "$CURRENT_LINK"
wp cache flush
wp rewrite flush

run_hook "post-deploy"

# Cleanup old releases
log "Cleaning up old releases..."
cleanup_releases "$RELEASE_DIR" "$KEEP_RELEASES"

# Send notifications
notify_deployment "success" "$ENVIRONMENT" "$RELEASE_ID"

log "=== Deployment Complete ==="
log "Active release: $RELEASE_ID"
log "Site URL: $SITE_URL"







Shared Functions Library







# lib/common.sh - Common utilities

LOG_FILE="$LOG_DIR/deploy-$(date +%Y%m%d).log"

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

error() {
    echo "[ERROR] $@" | tee -a "$LOG_FILE" >&2
    notify_deployment "failure" "$ENVIRONMENT" "$RELEASE_ID"
    exit 1
}

run_hook() {
    local hook_name="$1"
    local hook_script="$HOOKS_DIR/${hook_name}.sh"

    if [ -f "$hook_script" ]; then
        log "Running hook: $hook_name"
        bash "$hook_script" "$ENVIRONMENT"
    fi
}

notify_deployment() {
    local status="$1"
    local environment="$2"
    local release="$3"

    # Slack notification
    if [ -n "$SLACK_WEBHOOK" ]; then
        curl -X POST "$SLACK_WEBHOOK" \
            -H 'Content-Type: application/json' \
            -d "{\"text\":\"Deployment $status: $environment ($release)\"}"
    fi

    # Email notification
    if [ -n "$EMAIL_NOTIFICATIONS" ]; then
        echo "Deployment $status on $environment (Release: $release)" | \
            mail -s "WordPress Deployment $status" "$EMAIL_NOTIFICATIONS"
    fi
}

cleanup_releases() {
    local release_dir="$1"
    local keep_count="$2"

    cd "$release_dir"
    ls -t | tail -n +$((keep_count + 1)) | xargs rm -rf
}







Database Migration System





Manage database schema changes safely.





Migration Runner







# lib/database.sh - Database migration functions

run_migrations() {
    local release_path="$1"
    local migration_dir="$MIGRATIONS_DIR"
    local applied_file="$SHARED_DIR/.applied-migrations"

    touch "$applied_file"

    log "Checking for pending migrations..."

    for migration in $(ls "$migration_dir"/*.sql | sort); do
        local migration_name=$(basename "$migration")

        # Check if already applied
        if grep -q "$migration_name" "$applied_file"; then
            log "  ⊘ Skipping: $migration_name (already applied)"
            continue
        fi

        log "  → Applying: $migration_name"

        # Run migration
        if wp db query < "$migration" --path="$release_path"; then
            echo "$migration_name" >> "$applied_file"
            log "  ✓ Applied: $migration_name"
        else
            error "Migration failed: $migration_name"
        fi
    done

    log "✓ All migrations applied"
}

rollback_migration() {
    local migration_name="$1"
    local rollback_file="$MIGRATIONS_DIR/${migration_name%.sql}-rollback.sql"

    if [ -f "$rollback_file" ]; then
        log "Rolling back migration: $migration_name"
        wp db query < "$rollback_file"
    else
        error "Rollback file not found: $rollback_file"
    fi
}







Example Migration Files







-- migrations/001-add-custom-tables.sql

CREATE TABLE IF NOT EXISTS wp_custom_data (
    id BIGINT(20) UNSIGNED NOT NULL AUTO_INCREMENT,
    user_id BIGINT(20) UNSIGNED NOT NULL,
    data_key VARCHAR(255) NOT NULL,
    data_value LONGTEXT,
    created_at DATETIME DEFAULT CURRENT_TIMESTAMP,
    PRIMARY KEY (id),
    KEY user_id (user_id)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

-- migrations/001-add-custom-tables-rollback.sql

DROP TABLE IF EXISTS wp_custom_data;







Rollback System





Instantly revert failed deployments.





Rollback Script







#!/bin/bash
# bin/rollback - Rollback to previous release

set -euo pipefail

source "$(dirname "$0")/../lib/common.sh"

ENVIRONMENT="${1:-staging}"
CONFIG_FILE="$CONFIG_DIR/environments/$ENVIRONMENT.conf"

source "$CONFIG_FILE"

log "=== Starting Rollback ==="

# Get current release
CURRENT=$(readlink "$CURRENT_LINK")
CURRENT_NAME=$(basename "$CURRENT")

log "Current release: $CURRENT_NAME"

# Get previous release
PREVIOUS=$(ls -t "$RELEASE_DIR" | grep -v "^$CURRENT_NAME
quot; | head -n 1)

if [ -z "$PREVIOUS" ]; then
    error "No previous release found for rollback"
fi

PREVIOUS_PATH="$RELEASE_DIR/$PREVIOUS"

log "Rolling back to: $PREVIOUS"

# Backup current state (in case rollback fails)
ROLLBACK_BACKUP="$BACKUP_DIR/pre-rollback-$(date +%Y%m%d_%H%M%S)"
mkdir -p "$ROLLBACK_BACKUP"
wp db export "$ROLLBACK_BACKUP/database.sql.gz" --path="$CURRENT"

# Switch to previous release
ln -nfs "$PREVIOUS_PATH" "$CURRENT_LINK"

# Clear caches
cd "$CURRENT_LINK"
wp cache flush
wp rewrite flush

# Verify rollback
if wp core is-installed --path="$CURRENT_LINK"; then
    log "✓ Rollback successful"
    notify_deployment "rollback-success" "$ENVIRONMENT" "$PREVIOUS"
else
    error "Rollback verification failed"
fi

log "=== Rollback Complete ==="
log "Active release: $PREVIOUS"







Health Monitoring System





Continuous uptime and performance monitoring.





Monitoring Script







#!/bin/bash
# bin/monitor - WordPress health monitoring

set -euo pipefail

source "$(dirname "$0")/../lib/common.sh"

ENVIRONMENT="${1:-production}"
CONFIG_FILE="$CONFIG_DIR/environments/$ENVIRONMENT.conf"

source "$CONFIG_FILE"

check_site_health() {
    local url="$1"
    local response=$(curl -s -o /dev/null -w "%{http_code}" "$url")

    if [ "$response" = "200" ]; then
        log "✓ Site accessible: $url"
        return 0
    else
        error "✗ Site down: $url (HTTP $response)"
        return 1
    fi
}

check_database_connection() {
    if wp db check --path="$CURRENT_LINK"; then
        log "✓ Database connection OK"
        return 0
    else
        error "✗ Database connection failed"
        return 1
    fi
}

check_disk_space() {
    local usage=$(df -h "$DEPLOY_PATH" | awk 'NR==2 {print $5}' | sed 's/%//')

    if [ "$usage" -lt 80 ]; then
        log "✓ Disk space OK ($usage%)"
        return 0
    else
        log "⚠ Disk space warning: $usage%"
        return 1
    fi
}

check_plugin_updates() {
    local updates=$(wp plugin list --update=available --format=count --path="$CURRENT_LINK")

    if [ "$updates" -eq 0 ]; then
        log "✓ All plugins up to date"
    else
        log "⚠ $updates plugin updates available"
    fi
}

# Run all checks
log "=== Health Check: $ENVIRONMENT ==="

FAILED=0

check_site_health "$SITE_URL" || FAILED=$((FAILED + 1))
check_database_connection || FAILED=$((FAILED + 1))
check_disk_space || FAILED=$((FAILED + 1))
check_plugin_updates

if [ "$FAILED" -gt 0 ]; then
    error "$FAILED health checks failed"
else
    log "✓ All health checks passed"
fi







Scheduled Monitoring







# Add to crontab: crontab -e

# Health check every 5 minutes
*/5 * * * * /opt/wordpress-deploy/bin/monitor production >> /var/log/wp-monitor.log 2>&1

# Daily deployment report
0 9 * * * /opt/wordpress-deploy/bin/report production | mail -s "Daily WordPress Report" team@example.com







Next Steps





You now have a complete production-ready WordPress deployment system.









Week 1: System setup





    

  • Install deployment system
    • 




  • Configure environments
    • 




  • Test provisioning
    • 






Week 2: Deployment workflow





    

  • Practice deployments
    • 




  • Test rollback procedures
    • 




  • Configure notifications
    • 






Week 3: CI/CD integration





    

  • Connect to GitHub Actions
    • 




  • Automate testing
    • 




  • Deploy on merge
    • 






Week 4: Production hardening





    

  • Implement monitoring
    • 




  • Optimize performance
    • 




  • Document procedures
    • 






Advanced Topics





    

  1. Multi-Server Deployments – Load-balanced WordPress
    2. 




  2. Container-Based Deployments – Docker/Kubernetes
    3. 




  3. GitOps Workflows – Infrastructure as code
    4. 






Get More Resources





Download complete system including:





    

  • Full deployment scripts
    • 




  • Configuration templates
    • 




  • Documentation
    • 






Join our email course for:





    

  • Weekly WP-CLI tutorials
    • 




  • DevOps best practices
    • 




  • Production war stories
    • 






Conclusion





A complete WordPress deployment system automates the entire lifecycle from server provisioning to zero-downtime deployments, monitoring, and rollback—enabling professional DevOps workflows for WordPress sites.





What we covered:





✅ Complete system architecture and project structure 
✅ Automated server provisioning from scratch 
✅ Zero-downtime deployment implementation 
✅ Database migration system with rollback 
✅ Instant rollback for failed deployments 
✅ Continuous health monitoring and alerting





Build this system, and you’ll deploy WordPress professionally—automated provisioning, zero-downtime releases, instant rollbacks, and comprehensive monitoring for production-grade WordPress operations.





Ready for more? Learn high-availability WordPress or enterprise DevOps.





Questions about WordPress deployment systems? Drop a comment below!





Found this helpful? Share with other DevOps engineers.


The post Building a Complete WordPress Deployment System with WP-CLI (Real Project) appeared first on WP-CLI Mastery.

]]>
					
		
		
			
		
		WP-CLI Search-Replace: Safe Database Modifications for WordPress Migration
		https://wpclimastery.com/blog/wp-cli-search-replace-safe-database-modifications-for-wordpress-migration/
		
		
		Sun, 25 Jan 2026 09:00:00 +0000
				
		
		
		
		
		
		https://wpclimastery.com/?p=138

					Changing URLs in WordPress databases manually destroys serialized data, breaks widget settings, corrupts option values, and leaves your site unusable. MySQL find-replace queries seem simple until you realize WordPress stores...


The post WP-CLI Search-Replace: Safe Database Modifications for WordPress Migration appeared first on WP-CLI Mastery.

]]>
										Changing URLs in WordPress databases manually destroys serialized data, breaks widget settings, corrupts option values, and leaves your site unusable. MySQL find-replace queries seem simple until you realize WordPress stores array lengths in serialized strings—one wrong replacement breaks everything.





WP-CLI’s search-replace command handles serialized data automatically, validates replacements before executing, and shows exactly what changed. It’s the only safe way to modify WordPress database content at scale.





In this guide, you’ll master WP-CLI search-replace for site migrations, domain changes, protocol updates, and any database modification requiring precision and safety.





Why WP-CLI Search-Replace is Critical





WordPress serialized data contains length values that break when modified with simple find-replace operations.





Problems with Manual Database Search-Replace





Serialized data corruption: Direct MySQL replacement breaks array and object serialization.





Partial replacements: URLs in JSON, meta fields, and options get missed.





No validation: Can’t preview changes before executing them.





No reporting: Don’t know what was changed or how many replacements occurred.





Irreversible: Once executed, can’t undo without restoring backups.





WP-CLI Search-Replace Advantages





Serialization-safe: Automatically recalculates lengths in serialized strings.





Dry-run mode: Preview all changes before executing them.





Comprehensive: Searches all tables, columns, and data types.





Detailed reporting: Shows exactly what will change and where.





Table-specific: Target specific tables or exclude sensitive data.





According to WordPress migration studies, 80% of failed migrations are due to incorrect URL replacement breaking serialized data.





Search-Replace Fundamentals





Master basic search-replace operations safely.





Basic Search-Replace Syntax







# Basic replacement
wp search-replace 'old-text' 'new-text'

# Replace in specific tables
wp search-replace 'old' 'new' wp_posts wp_postmeta

# Replace in all tables (dangerous, use carefully)
wp search-replace 'old' 'new' --all-tables

# Skip specific columns
wp search-replace 'old' 'new' --skip-columns=guid







Always Use Dry-Run First







# Preview changes without executing (CRITICAL!)
wp search-replace 'oldsite.com' 'newsite.com' --dry-run

# Dry-run with detailed report
wp search-replace 'http://' 'https://' --dry-run --report

# See exact replacement count
wp search-replace 'old' 'new' --dry-run --report --precise







Critical Rule: NEVER run search-replace without --dry-run first. Always preview changes.





Understanding Serialized Data







# WordPress serialized data example:
# a:3:{s:4:"name";s:4:"John";s:3:"age";i:30;}
#      ^ length     ^ length

# Direct MySQL replacement breaks this:
# UPDATE wp_options SET option_value =
# REPLACE(option_value, 'John', 'Jonathan');
# Result: a:3:{s:4:"name";s:8:"Jonathan";...}
#                        ^ WRONG! Should be s:8

# WP-CLI handles this automatically:
wp search-replace 'John' 'Jonathan' wp_options

# WP-CLI recalculates: s:4 becomes s:8 automatically







Learn more about WP-CLI search-replace documentation.





Common Search-Replace Use Cases





Handle the most frequent WordPress database modification scenarios.





Domain Migration







#!/bin/bash
# migrate-domain.sh - Complete domain change

OLD_DOMAIN="oldsite.com"
NEW_DOMAIN="newsite.com"

# Backup first (ALWAYS!)
wp db export backup-before-domain-change.sql.gz

# Dry-run to preview
echo "Previewing changes..."
wp search-replace "https://$OLD_DOMAIN" "https://$NEW_DOMAIN" --dry-run --report

# Ask for confirmation
read -p "Proceed with replacement? (y/n) " -n 1 -r
echo
if [[ ! $REPLY =~ ^[Yy]$ ]]; then
    echo "Operation cancelled"
    exit 0
fi

# Execute replacements
echo "Executing replacements..."

# Replace full URLs
wp search-replace "https://$OLD_DOMAIN" "https://$NEW_DOMAIN"
wp search-replace "http://$OLD_DOMAIN" "https://$NEW_DOMAIN"

# Replace protocol-relative URLs
wp search-replace "//$OLD_DOMAIN" "//$NEW_DOMAIN"

# Update WordPress options directly
wp option update home "https://$NEW_DOMAIN"
wp option update siteurl "https://$NEW_DOMAIN"

# Flush caches
wp cache flush
wp rewrite flush

echo "✓ Domain migration complete"







HTTP to HTTPS Migration







#!/bin/bash
# migrate-to-https.sh

DOMAIN="example.com"

# Backup
wp db export backup-before-https.sql.gz

# Dry-run
wp search-replace "http://$DOMAIN" "https://$DOMAIN" --dry-run

# Execute
wp search-replace "http://$DOMAIN" "https://$DOMAIN"

# Update options
wp option update home "https://$DOMAIN"
wp option update siteurl "https://$DOMAIN"

echo "✓ Migrated to HTTPS"







Use Case: Essential for SEO and security—Google requires HTTPS for ranking.





Path Changes (Subdirectory Moves)







# Move from subdirectory to root
wp search-replace 'https://example.com/blog' 'https://example.com'

# Move from root to subdirectory
wp search-replace 'https://example.com' 'https://example.com/wordpress'

# Move between subdirectories
wp search-replace 'https://example.com/old' 'https://example.com/new'







Content Text Replacement







# Replace company name in all content
wp search-replace 'Old Company LLC' 'New Company Inc' wp_posts

# Fix common typos across site
wp search-replace 'recieve' 'receive' wp_posts wp_postmeta

# Update email addresses
wp search-replace 'contact@oldcompany.com' 'contact@newcompany.com'

# Replace shortcodes
wp search-replace '[old_shortcode]' '[new_shortcode]' wp_posts







Advanced Search-Replace Techniques





Handle complex scenarios with precision.





Regex Pattern Replacement







# Enable regex mode
wp search-replace 'pattern' 'replacement' --regex

# Replace all HTTP/HTTPS variations
wp search-replace 'https?://oldsite\.com' 'https://newsite.com' --regex

# Remove URL parameters
wp search-replace '\?utm_[^\s"]+' '' --regex wp_posts

# Fix malformed URLs
wp search-replace 'http://http://' 'http://' --regex







Warning: Test regex patterns thoroughly with --dry-run. Incorrect patterns cause unexpected replacements.





Table-Specific Operations







# Replace in posts and metadata only
wp search-replace 'old' 'new' wp_posts wp_postmeta

# Replace in all tables except options
wp search-replace 'old' 'new' --all-tables-with-prefix --skip-tables=wp_options

# List all tables first
wp db tables

# Replace in custom tables
wp search-replace 'old' 'new' wp_custom_table







Export Replacement Report







# Generate CSV report of all changes
wp search-replace 'old' 'new' --export=changes.csv

# Generate report with dry-run
wp search-replace 'old' 'new' --dry-run --report > replacement-report.txt

# Count replacements
REPLACEMENTS=$(wp search-replace 'old' 'new' --dry-run --format=count)
echo "Will replace $REPLACEMENTS occurrences"







Learn about WordPress database tables structure.





Skip Sensitive Columns







# Don't modify GUIDs (recommended)
wp search-replace 'old' 'new' --skip-columns=guid

# Skip multiple columns
wp search-replace 'old' 'new' --skip-columns=guid,post_date

# Skip user passwords and meta
wp search-replace 'old' 'new' wp_users --skip-columns=user_pass







Best Practice: Always skip guid column—changing GUIDs breaks feed readers and external references.





Safe Migration Workflow





Complete migration process with validation and rollback capability.





Complete Migration Script







#!/bin/bash
set -euo pipefail

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

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

log "=== WordPress Migration Started ==="

# Validate WordPress
if ! wp core is-installed; then
    log "ERROR: WordPress not installed"
    exit 1
fi

# Create backup
log "Creating backup..."
BACKUP_FILE="$BACKUP_DIR/pre-migration-$(date +%Y%m%d-%H%M%S).sql.gz"
wp db export "$BACKUP_FILE"

BACKUP_SIZE=$(stat -c%s "$BACKUP_FILE")
if [ "$BACKUP_SIZE" -lt 1000 ]; then
    log "ERROR: Backup too small, aborting"
    exit 1
fi
log "✓ Backup created: $BACKUP_FILE"

# Dry-run validation
log "Validating replacements..."
if ! wp search-replace "$SOURCE_URL" "$TARGET_URL" --dry-run --report &> /dev/null; then
    log "ERROR: Dry-run failed"
    exit 1
fi

# Count expected replacements
REPLACEMENTS=$(wp search-replace "$SOURCE_URL" "$TARGET_URL" --dry-run --report | grep -c "$SOURCE_URL" || true)
log "Found $REPLACEMENTS occurrences to replace"

if [ "$REPLACEMENTS" -eq 0 ]; then
    log "WARNING: No replacements found, check URLs"
fi

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

# Also replace without protocol
wp search-replace "//staging.example.com" "//example.com"

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

# Verify replacements
log "Verifying replacements..."
REMAINING=$(wp search-replace "$SOURCE_URL" "$TARGET_URL" --dry-run --report | grep -c "$SOURCE_URL" || true)

if [ "$REMAINING" -gt 0 ]; then
    log "WARNING: $REMAINING occurrences still remain"
else
    log "✓ All occurrences replaced"
fi

# Clear caches
wp cache flush
wp rewrite flush

log "=== Migration Complete ==="
log "Rollback backup: $BACKUP_FILE"







Rollback Procedure







#!/bin/bash
# rollback-migration.sh

BACKUP_FILE="$1"

if [ -z "$BACKUP_FILE" ]; then
    echo "Usage: $0 <backup-file.sql.gz>"
    exit 1
fi

if [ ! -f "$BACKUP_FILE" ]; then
    echo "ERROR: Backup file not found: $BACKUP_FILE"
    exit 1
fi

echo "Rolling back to: $BACKUP_FILE"
read -p "This will overwrite current database. Continue? (y/n) " -n 1 -r
echo

if [[ ! $REPLY =~ ^[Yy]$ ]]; then
    echo "Rollback cancelled"
    exit 0
fi

# Restore database
wp db import "$BACKUP_FILE"

# Flush caches
wp cache flush
wp rewrite flush

echo "✓ Rollback complete"







Troubleshooting Search-Replace





Fix common search-replace issues.





URLs Not Changing







# Check current URLs in database
wp search-replace 'oldsite.com' 'oldsite.com' --dry-run --report | head -20

# Try all URL variations
wp search-replace 'http://oldsite.com' 'https://newsite.com'
wp search-replace 'https://oldsite.com' 'https://newsite.com'
wp search-replace 'http://www.oldsite.com' 'https://newsite.com'
wp search-replace '//oldsite.com' '//newsite.com'

# Force update options
wp option update home 'https://newsite.com'
wp option update siteurl 'https://newsite.com'







Serialization Errors







# Check for serialization issues
wp search-replace 'old' 'new' --precise

# Skip problematic tables
wp search-replace 'old' 'new' --skip-tables=wp_options

# Replace table by table
for TABLE in $(wp db tables --format=csv); do
    echo "Processing: $TABLE"
    wp search-replace 'old' 'new' "$TABLE" --dry-run
done







Performance Issues







# Large databases may timeout, increase PHP limits
php -d memory_limit=512M wp search-replace 'old' 'new'

# Process tables individually for very large databases
wp search-replace 'old' 'new' wp_posts
wp search-replace 'old' 'new' wp_postmeta
wp search-replace 'old' 'new' wp_options







Next Steps





You now have professional WordPress search-replace skills for safe database migrations.









Week 1: Basic replacements





    

  • Practice dry-run workflows
    • 




  • Test domain changes on staging
    • 




  • Learn serialization concepts
    • 






Week 2: Advanced techniques





    

  • Master regex patterns
    • 




  • Handle complex migrations
    • 




  • Build verification scripts
    • 






Week 3: Production migrations





    

  • Create complete migration workflows
    • 




  • Implement rollback procedures
    • 




  • Document migration playbooks
    • 






Week 4: Automation





    

  • Build migration scripts
    • 




  • Add validation checks
    • 




  • Automate testing
    • 






Advanced Topics





    

  1. Multisite Search-Replace – Network-wide replacements
    2. 




  2. Large Database Migrations – Handle millions of records
    3. 




  3. Custom Table Migrations – Plugin-specific data
    4. 






Get More Resources





Download migration scripts including:





    

  • Complete migration automation
    • 




  • Rollback procedures
    • 




  • Validation checklists
    • 






Join our email course for:





    

  • Weekly WP-CLI tutorials
    • 




  • Migration best practices
    • 




  • Advanced database techniques
    • 






Conclusion





WP-CLI search-replace is the only safe way to modify WordPress database content, handling serialized data automatically while giving you complete control and visibility.





What we covered:





✅ Search-replace fundamentals with dry-run validation 
✅ Common use cases (domain changes, HTTPS migration, paths) 
✅ Advanced techniques (regex, table-specific, reporting) 
✅ Safe migration workflows with backups and rollback 
✅ Troubleshooting common search-replace issues





Master these techniques, and you’ll handle WordPress migrations and database modifications with confidence—whether changing domains, updating URLs, or migrating content.





Ready for more? Learn WordPress database optimization or advanced WP-CLI automation.





Questions about WP-CLI search-replace? Drop a comment below!





Found this helpful? Share with other WordPress developers.


The post WP-CLI Search-Replace: Safe Database Modifications for WordPress Migration appeared first on WP-CLI Mastery.

]]>
					
		
		
			
		
		WordPress CI/CD Pipeline with GitHub Actions and WP-CLI
		https://wpclimastery.com/blog/wordpress-ci-cd-pipeline-with-github-actions-and-wp-cli/
		
		
		Tue, 20 Jan 2026 09:00:00 +0000
				
		
		
		
		
		
		https://wpclimastery.com/?p=15

					Manually deploying WordPress changes is risky, time-consuming, and prone to human error. Push to FTP, run SQL updates, clear caches, pray nothing breaks. When something goes wrong at 2 AM,...


The post WordPress CI/CD Pipeline with GitHub Actions and WP-CLI appeared first on WP-CLI Mastery.

]]>
										Manually deploying WordPress changes is risky, time-consuming, and prone to human error. Push to FTP, run SQL updates, clear caches, pray nothing breaks. When something goes wrong at 2 AM, there’s no easy rollback.





Professional WordPress development requires automated CI/CD (Continuous Integration/Continuous Deployment) pipelines that test, build, and deploy code safely and consistently.





In this advanced guide, you’ll learn to build a production-ready WordPress CI/CD pipeline using GitHub Actions and WP-CLI. You’ll implement automated testing, staging deployments, database migrations, and zero-downtime production deployments—all triggered automatically by Git pushes.





By the end, you’ll have a professional WordPress DevOps workflow that eliminates deployment fear.





What is CI/CD for WordPress?





CI/CD Defined





Continuous Integration (CI):





    

  • Automatically test code changes
    • 




  • Verify WordPress functionality
    • 




  • Run security checks
    • 




  • Ensure code quality
    • 






Continuous Deployment (CD):





    

  • Automatically deploy to staging
    • 




  • Deploy to production on approval
    • 




  • Run database migrations
    • 




  • Zero-downtime deployments
    • 






The Manual Deployment Problem





Traditional workflow:





    

  1. Make changes locally
    2. 




  2. FTP files to server (hope you don’t overwrite something)
    3. 




  3. SSH and run SQL updates manually
    4. 




  4. Clear caches
    5. 




  5. Hope nothing is broken
    6. 




  6. If broken, scramble to fix or revert
    7. 






Problems:





    

  • Downtime during deployment
    • 




  • Human error (forgot to run migration, uploaded wrong file)
    • 




  • No testing before production
    • 




  • Difficult rollback
    • 




  • No audit trail
    • 






CI/CD Workflow





Automated workflow:





    

  1. Push code to GitHub
    2. 




  2. CI: Automated tests run
    3. 




  3. CD: Deploy to staging automatically
    4. 




  4. QA tests staging environment
    5. 




  5. Approve production deployment
    6. 




  6. CD: Deploy to production with zero downtime
    7. 




  7. Automatic rollback if issues detected
    8. 






Benefits:





    

  • No manual deployment steps
    • 




  • Every deployment is tested
    • 




  • Instant rollback capability
    • 




  • Complete audit trail in Git
    • 




  • Confidence to deploy frequently
    • 






Prerequisites





Before building your CI/CD pipeline:





Required Accounts





    

  • GitHub Account – For repository and Actions
    • 




  • WordPress Server(s) – Staging and production with SSH access
    • 




  • WP-CLI Access – On all WordPress servers
    • 






Server Requirements





Both staging and production need:





    

  • SSH access
    • 




  • WP-CLI installed – Installation guide
    • 




  • Git installed
    • 




  • Web server (Apache/Nginx)
    • 




  • MySQL/MariaDB database
    • 






Local Development









Knowledge Requirements





Helpful background:





    

  • Git basics (branches, commits, pull requests)
    • 




  • GitHub fundamentals
    • 




  • WordPress theme/plugin development
    • 




  • SSH and server administration
    • 






GitHub Actions Basics





What are GitHub Actions?





GitHub Actions are automated workflows that run when specific GitHub events occur (push, pull request, release, etc.).





Workflow anatomy:





name: WordPress CI/CD

on:
  push:
    branches: [main, develop]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - name: Run tests
        run: ./run-tests.sh






Key concepts:





    

  • Workflow: YAML file defining automation
    • 




  • Event: Trigger (push, pull_request, schedule)
    • 




  • Job: Set of steps that run on a runner
    • 




  • Step: Individual task (run command, use action)
    • 




  • Runner: Server that runs workflows (GitHub-hosted or self-hosted)
    • 






Why GitHub Actions for WordPress?





Advantages:





    

  • Free for public repos (2,000 minutes/month for private)
    • 




  • Integrated with GitHub (no external CI service)
    • 




  • Large marketplace of pre-built actions
    • 




  • Supports matrix builds (test multiple PHP versions)
    • 




  • Secret management built-in
    • 






Learn more: GitHub Actions Documentation





Setting Up Your Repository





Repository Structure





Organize your WordPress project for CI/CD:





wordpress-project/
├── .github/
│   └── workflows/
│       ├── ci.yml           # Continuous Integration
│       └── deploy.yml       # Continuous Deployment
├── wp-content/
│   ├── themes/
│   │   └── my-theme/
│   ├── plugins/
│   │   └── my-plugin/
│   └── mu-plugins/
├── scripts/
│   ├── deploy.sh            # Deployment script
│   ├── test.sh              # Testing script
│   └── migrate.sh           # Database migration
├── tests/
│   └── test-wordpress.php
├── composer.json
└── README.md






What to version control:





    

  • ✅ Custom themes
    • 




  • ✅ Custom plugins
    • 




  • ✅ mu-plugins
    • 




  • ✅ Configuration files
    • 




  • ✅ Deployment scripts
    • 






What NOT to version:





    

  • ❌ WordPress core (use Composer or WP-CLI)
    • 




  • ❌ Third-party plugins (manage separately)
    • 




  • ❌ wp-config.php (use environment-specific configs)
    • 




  • ❌ uploads/ directory
    • 




  • ❌ .env files with secrets
    • 






Create .gitignore





# .gitignore for WordPress

# WordPress core
/wp-admin/
/wp-includes/
/wp-*.php
/xmlrpc.php
/license.txt
/readme.html

# Configuration
wp-config.php
.env
.env.*

# Uploads
wp-content/uploads/

# Cache
wp-content/cache/
wp-content/backup*/

# Third-party plugins (manage via Composer)
wp-content/plugins/*
!wp-content/plugins/my-custom-plugin/

# IDE
.vscode/
.idea/

# OS
.DS_Store
Thumbs.db

# Dependencies
/vendor/
node_modules/






Initialize Repository





# Create repository
git init
git add .
git commit -m "Initial commit"

# Create and push to GitHub
gh repo create my-wordpress-site --public --source=. --remote=origin --push

# Or manually
git remote add origin git@github.com:username/my-wordpress-site.git
git push -u origin main






WordPress Testing Environment





Set Up WordPress in GitHub Actions





Use the setup-wordpress action to create a test environment:





# .github/workflows/ci.yml

name: WordPress CI

on:
  push:
    branches: [main, develop]
  pull_request:
    branches: [main]

jobs:
  test:
    runs-on: ubuntu-latest

    services:
      mysql:
        image: mysql:5.7
        env:
          MYSQL_ROOT_PASSWORD: root
          MYSQL_DATABASE: wordpress_test
        ports:
          - 3306:3306
        options: --health-cmd="mysqladmin ping" --health-interval=10s --health-timeout=5s --health-retries=3

    steps:
      - uses: actions/checkout@v3

      - name: Setup PHP
        uses: shivammathur/setup-php@v2
        with:
          php-version: '8.1'
          extensions: mysql, mbstring, xml
          tools: wp-cli

      - name: Install WordPress
        run: |
          wp core download --path=/tmp/wordpress
          wp config create --dbname=wordpress_test --dbuser=root --dbpass=root --dbhost=127.0.0.1 --path=/tmp/wordpress
          wp core install --url=http://localhost --title="Test Site" --admin_user=admin --admin_password=admin --admin_email=admin@test.com --path=/tmp/wordpress

      - name: Activate plugin/theme
        run: |
          # Copy your custom code
          cp -r $GITHUB_WORKSPACE/wp-content/plugins/my-plugin /tmp/wordpress/wp-content/plugins/
          wp plugin activate my-plugin --path=/tmp/wordpress

      - name: Run tests
        run: |
          ./scripts/test.sh






Create Test Script





#!/bin/bash
# scripts/test.sh

set -e

WP_PATH="/tmp/wordpress"

echo "Running WordPress tests..."

# Test 1: WordPress is installed
wp core is-installed --path=$WP_PATH

# Test 2: Database is accessible
wp db check --path=$WP_PATH

# Test 3: Plugin is active
wp plugin is-active my-plugin --path=$WP_PATH

# Test 4: WordPress version
version=$(wp core version --path=$WP_PATH)
echo "WordPress version: $version"

# Test 5: Run PHP CodeSniffer (if configured)
if command -v phpcs &> /dev/null; then
    phpcs --standard=WordPress wp-content/plugins/my-plugin/
fi

echo "✓ All tests passed!"






Make it executable:





chmod +x scripts/test.sh
git add scripts/test.sh
git commit -m "Add test script"






Automated Testing with WP-CLI





Test Categories





1. Sanity Tests





    

  • WordPress is installed
    • 




  • Database connection works
    • 




  • Required plugins are active
    • 






2. Functionality Tests





    

  • Custom plugin functions work
    • 




  • Theme renders correctly
    • 




  • Custom post types exist
    • 






3. Security Tests





    

  • No vulnerable plugins
    • 




  • WordPress core integrity
    • 




  • File permissions
    • 






4. Performance Tests





    

  • Database query count
    • 




  • Page load time
    • 




  • Cache functionality
    • 






Comprehensive Test Script





#!/bin/bash
# scripts/test.sh - Comprehensive WordPress testing

set -e

WP_PATH=${WP_PATH:-/tmp/wordpress}
RED='\033[0;31m'
GREEN='\033[0;32m'
NC='\033[0m'

test_count=0
passed=0
failed=0

run_test() {
    local test_name=$1
    local test_command=$2

    ((test_count++))
    echo -n "Test $test_count: $test_name... "

    if eval "$test_command" &>/dev/null; then
        echo -e "${GREEN}PASS${NC}"
        ((passed++))
        return 0
    else
        echo -e "${RED}FAIL${NC}"
        ((failed++))
        return 1
    fi
}

echo "========================================="
echo "WordPress Automated Testing"
echo "========================================="

# Sanity tests
run_test "WordPress installed" "wp core is-installed --path=$WP_PATH"
run_test "Database accessible" "wp db check --path=$WP_PATH"
run_test "Core files verified" "wp core verify-checksums --path=$WP_PATH"

# Plugin tests
run_test "Custom plugin active" "wp plugin is-active my-plugin --path=$WP_PATH"
run_test "No plugin errors" "wp plugin list --path=$WP_PATH --status=active --format=count"

# Theme tests
run_test "Theme activated" "wp theme is-active my-theme --path=$WP_PATH"

# Security tests
run_test "No vulnerable plugins" "! wp plugin list --path=$WP_PATH --field=update | grep -q available"

# Performance tests
run_test "Cache object working" "wp cache flush --path=$WP_PATH"

# Database tests
run_test "Database optimized" "wp db optimize --path=$WP_PATH"

echo "========================================="
echo "Test Results: $passed passed, $failed failed"
echo "========================================="

if [ $failed -gt 0 ]; then
    exit 1
fi

exit 0






Matrix Testing (Multiple PHP Versions)





jobs:
  test:
    runs-on: ubuntu-latest
    strategy:
      matrix:
        php-version: ['7.4', '8.0', '8.1']
        wordpress-version: ['6.2', '6.3', '6.4']

    name: PHP ${{ matrix.php-version }} / WP ${{ matrix.wordpress-version }}

    steps:
      - uses: actions/checkout@v3

      - name: Setup PHP ${{ matrix.php-version }}
        uses: shivammathur/setup-php@v2
        with:
          php-version: ${{ matrix.php-version }}

      - name: Install WordPress ${{ matrix.wordpress-version }}
        run: |
          wp core download --version=${{ matrix.wordpress-version }} --path=/tmp/wordpress
          # ... rest of setup

      - name: Run tests
        run: ./scripts/test.sh






This tests across 9 combinations (3 PHP × 3 WP versions).





Building the Deployment Workflow





Deployment Script Structure





#!/bin/bash
# scripts/deploy.sh

set -euo pipefail

ENVIRONMENT=$1  # staging or production
SERVER=$2       # server hostname
WP_PATH=$3      # WordPress path on server

echo "Deploying to $ENVIRONMENT ($SERVER)"

# 1. Create backup
ssh $SERVER "cd $WP_PATH && wp db export backup-$(date +%s).sql"

# 2. Pull latest code
ssh $SERVER "cd $WP_PATH && git pull origin main"

# 3. Install dependencies
ssh $SERVER "cd $WP_PATH && composer install --no-dev"

# 4. Run database migrations
ssh $SERVER "cd $WP_PATH && wp cli migrate"

# 5. Clear caches
ssh $SERVER "cd $WP_PATH && wp cache flush"
ssh $SERVER "cd $WP_PATH && wp rewrite flush"

# 6. Verify deployment
ssh $SERVER "cd $WP_PATH && wp core is-installed"

echo "✓ Deployment complete!"






SSH Key Setup





Add SSH private key to GitHub Secrets:





    

  1. Generate SSH key (if needed):
    2. 






ssh-keygen -t ed25519 -C "github-actions@example.com" -f ~/.ssh/github-actions






    

  1. Add public key to server:
    2. 






ssh-copy-id -i ~/.ssh/github-actions.pub user@your-server.com






    

  1. Add private key to GitHub:

      

    • Go to repo Settings → Secrets → Actions
      • 




    • New repository secret
      • 




    • Name: SSH_PRIVATE_KEY
      • 




    • Value: Contents of ~/.ssh/github-actions (private key)
      • 

    

    2. 






Environment Secrets Management





GitHub Secrets





Store sensitive data in GitHub Secrets:





Required secrets:





    

  • SSH_PRIVATE_KEY – SSH key for server access
    • 




  • SSH_HOST_STAGING – Staging server hostname
    • 




  • SSH_HOST_PRODUCTION – Production server hostname
    • 




  • SSH_USER – SSH username
    • 




  • WP_PATH_STAGING – WordPress path on staging
    • 




  • WP_PATH_PRODUCTION – WordPress path on production
    • 






Using Secrets in Workflows





jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3

      - name: Setup SSH
        uses: webfactory/ssh-agent@v0.7.0
        with:
          ssh-private-key: ${{ secrets.SSH_PRIVATE_KEY }}

      - name: Deploy to staging
        run: |
          ./scripts/deploy.sh \
            staging \
            ${{ secrets.SSH_HOST_STAGING }} \
            ${{ secrets.WP_PATH_STAGING }}






Environment Variables





Create environment-specific configurations:





jobs:
  deploy-staging:
    environment: staging
    env:
      WP_ENV: staging
      SSH_HOST: ${{ secrets.SSH_HOST_STAGING }}
      WP_PATH: ${{ secrets.WP_PATH_STAGING }}

  deploy-production:
    environment: production
    env:
      WP_ENV: production
      SSH_HOST: ${{ secrets.SSH_HOST_PRODUCTION }}
      WP_PATH: ${{ secrets.WP_PATH_PRODUCTION }}






Staging Deployment





Auto-Deploy to Staging





Deploy automatically on push to develop branch:





# .github/workflows/deploy-staging.yml

name: Deploy to Staging

on:
  push:
    branches: [develop]

jobs:
  deploy:
    runs-on: ubuntu-latest
    environment: staging

    steps:
      - uses: actions/checkout@v3

      - name: Setup SSH
        uses: webfactory/ssh-agent@v0.7.0
        with:
          ssh-private-key: ${{ secrets.SSH_PRIVATE_KEY }}

      - name: Deploy to staging server
        run: |
          ssh -o StrictHostKeyChecking=no ${{ secrets.SSH_USER }}@${{ secrets.SSH_HOST_STAGING }} << 'ENDSSH'
            set -e
            cd ${{ secrets.WP_PATH_STAGING }}

            # Backup database
            wp db export backup-$(date +%Y%m%d-%H%M%S).sql

            # Pull latest code
            git fetch origin
            git reset --hard origin/develop

            # Install dependencies
            composer install --no-dev --optimize-autoloader

            # Database migrations
            if [ -f scripts/migrate.sh ]; then
              ./scripts/migrate.sh
            fi

            # Clear caches
            wp cache flush
            wp rewrite flush

            # Verify
            wp core is-installed && echo "Deployment successful!"
          ENDSSH

      - name: Notify on Slack
        if: always()
        uses: 8398a7/action-slack@v3
        with:
          status: ${{ job.status }}
          text: 'Staging deployment: ${{ job.status }}'
          webhook_url: ${{ secrets.SLACK_WEBHOOK }}






Production Deployment





Manual Approval Required





Require manual approval before production deployment:





# .github/workflows/deploy-production.yml

name: Deploy to Production

on:
  workflow_dispatch:  # Manual trigger only
  release:
    types: [published]

jobs:
  deploy:
    runs-on: ubuntu-latest
    environment:
      name: production
      url: https://yoursite.com

    steps:
      - uses: actions/checkout@v3

      - name: Setup SSH
        uses: webfactory/ssh-agent@v0.7.0
        with:
          ssh-private-key: ${{ secrets.SSH_PRIVATE_KEY }}

      - name: Pre-deployment checks
        run: |
          # Verify staging is working
          curl -f https://staging.yoursite.com || exit 1

      - name: Create backup
        run: |
          ssh ${{ secrets.SSH_USER }}@${{ secrets.SSH_HOST_PRODUCTION }} \
            "cd ${{ secrets.WP_PATH_PRODUCTION }} && wp db export backups/pre-deploy-$(date +%s).sql"

      - name: Deploy to production
        run: |
          ssh ${{ secrets.SSH_USER }}@${{ secrets.SSH_HOST_PRODUCTION }} << 'ENDSSH'
            set -e
            cd ${{ secrets.WP_PATH_PRODUCTION }}

            # Enable maintenance mode
            wp maintenance-mode activate

            # Pull latest code
            git fetch origin
            git reset --hard origin/main

            # Install dependencies
            composer install --no-dev --optimize-autoloader

            # Database migrations
            if [ -f scripts/migrate.sh ]; then
              ./scripts/migrate.sh
            fi

            # Clear caches
            wp cache flush
            wp rewrite flush
            wp transient delete --all

            # Disable maintenance mode
            wp maintenance-mode deactivate

            # Verify
            wp core is-installed && echo "Production deployment successful!"
          ENDSSH

      - name: Smoke tests
        run: |
          # Test homepage
          curl -f https://yoursite.com

          # Test critical pages
          curl -f https://yoursite.com/about
          curl -f https://yoursite.com/contact

      - name: Rollback on failure
        if: failure()
        run: |
          echo "Deployment failed, initiating rollback..."
          ssh ${{ secrets.SSH_USER }}@${{ secrets.SSH_HOST_PRODUCTION }} \
            "cd ${{ secrets.WP_PATH_PRODUCTION }} && git reset --hard HEAD~1"






Protected Branches





Configure branch protection in GitHub:





    

  1. Go to Settings → Branches
    2. 




  2. Add rule for main branch
    3. 




  3. Enable:

      

    • Require pull request reviews (1+ approvals)
      • 




    • Require status checks to pass (CI tests)
      • 




    • Require branches to be up to date
      • 

    

    4. 






This ensures production only receives tested, reviewed code.





Database Migrations





Migration Script Pattern





#!/bin/bash
# scripts/migrate.sh

set -e

WP_PATH=${WP_PATH:-.}

echo "Running database migrations..."

# Migration 001: Add custom table
wp db query "
  CREATE TABLE IF NOT EXISTS wp_custom_data (
    id bigint(20) NOT NULL AUTO_INCREMENT,
    user_id bigint(20) NOT NULL,
    data longtext NOT NULL,
    created_at datetime NOT NULL,
    PRIMARY KEY (id)
  );
" --path=$WP_PATH

# Migration 002: Update post meta
wp post meta update-all custom_field new_value --from=old_value --path=$WP_PATH

# Migration 003: Create custom taxonomy
wp taxonomy register custom_taxonomy --path=$WP_PATH

echo "✓ Migrations complete!"






Version-Controlled Migrations





Use migration files:





# migrations/001-create-custom-table.sql
CREATE TABLE IF NOT EXISTS wp_custom_data (
  id bigint(20) NOT NULL AUTO_INCREMENT,
  data longtext NOT NULL,
  PRIMARY KEY (id)
);

# migrations/002-add-meta-field.sh
#!/bin/bash
wp post list --format=ids | xargs -I {} wp post meta update {} new_field default_value






Migration runner:





#!/bin/bash
# scripts/migrate.sh

WP_PATH=${WP_PATH:-.}
MIGRATIONS_DIR="migrations"

for migration in $MIGRATIONS_DIR/*; do
    echo "Running migration: $(basename $migration)"

    if [[ $migration == *.sql ]]; then
        wp db query < $migration --path=$WP_PATH
    elif [[ $migration == *.sh ]]; then
        bash $migration
    fi

    echo "✓ Completed: $(basename $migration)"
done






Rollback Strategy





Automated Rollback on Failure





- name: Deploy with rollback
  id: deploy
  run: |
    # Get current commit for rollback
    CURRENT_COMMIT=$(ssh $SERVER "cd $WP_PATH && git rev-parse HEAD")
    echo "current_commit=$CURRENT_COMMIT" >> $GITHUB_OUTPUT

    # Deploy
    ./scripts/deploy.sh

- name: Verify deployment
  id: verify
  run: |
    # Run smoke tests
    curl -f https://yoursite.com || exit 1
    ssh $SERVER "cd $WP_PATH && wp core is-installed" || exit 1

- name: Rollback on failure
  if: failure() && steps.deploy.outcome == 'success'
  run: |
    echo "Deployment verification failed, rolling back..."

    # Restore database backup
    BACKUP_FILE=$(ssh $SERVER "ls -t $WP_PATH/backups/*.sql | head -1")
    ssh $SERVER "cd $WP_PATH && wp db import $BACKUP_FILE"

    # Restore code
    ssh $SERVER "cd $WP_PATH && git reset --hard ${{ steps.deploy.outputs.current_commit }}"

    # Clear caches
    ssh $SERVER "cd $WP_PATH && wp cache flush"

    echo "✓ Rollback complete"
    exit 1






Manual Rollback Workflow





# .github/workflows/rollback.yml

name: Rollback Production

on:
  workflow_dispatch:
    inputs:
      commit_sha:
        description: 'Commit SHA to rollback to'
        required: true

jobs:
  rollback:
    runs-on: ubuntu-latest
    environment: production

    steps:
      - name: Confirm rollback
        run: |
          echo "Rolling back to commit: ${{ github.event.inputs.commit_sha }}"

      - name: Rollback code
        run: |
          ssh ${{ secrets.SSH_USER }}@${{ secrets.SSH_HOST_PRODUCTION }} \
            "cd ${{ secrets.WP_PATH_PRODUCTION }} && git reset --hard ${{ github.event.inputs.commit_sha }}"

      - name: Restore database
        run: |
          # Restore from backup (manual selection required)
          echo "Please restore database manually from backups/"






Complete GitHub Actions Workflow





Production-Ready CI/CD





# .github/workflows/wordpress-cicd.yml

name: WordPress CI/CD

on:
  push:
    branches: [main, develop]
  pull_request:
    branches: [main]
  workflow_dispatch:

env:
  PHP_VERSION: '8.1'

jobs:
  # Job 1: Run tests
  test:
    name: Test
    runs-on: ubuntu-latest

    services:
      mysql:
        image: mysql:5.7
        env:
          MYSQL_ROOT_PASSWORD: root
          MYSQL_DATABASE: wordpress_test
        ports:
          - 3306:3306

    steps:
      - uses: actions/checkout@v3

      - name: Setup PHP
        uses: shivammathur/setup-php@v2
        with:
          php-version: ${{ env.PHP_VERSION }}
          extensions: mysql, mbstring, xml
          tools: wp-cli, composer

      - name: Install WordPress
        run: |
          wp core download --path=/tmp/wordpress
          wp config create \
            --dbname=wordpress_test \
            --dbuser=root \
            --dbpass=root \
            --dbhost=127.0.0.1 \
            --path=/tmp/wordpress
          wp core install \
            --url=http://localhost \
            --title="Test Site" \
            --admin_user=admin \
            --admin_password=admin \
            --admin_email=admin@test.com \
            --path=/tmp/wordpress

      - name: Copy custom code
        run: |
          cp -r wp-content/themes/* /tmp/wordpress/wp-content/themes/
          cp -r wp-content/plugins/* /tmp/wordpress/wp-content/plugins/

      - name: Run tests
        run: ./scripts/test.sh
        env:
          WP_PATH: /tmp/wordpress

  # Job 2: Deploy to staging
  deploy-staging:
    name: Deploy to Staging
    needs: test
    if: github.ref == 'refs/heads/develop' && github.event_name == 'push'
    runs-on: ubuntu-latest
    environment: staging

    steps:
      - uses: actions/checkout@v3

      - name: Setup SSH
        uses: webfactory/ssh-agent@v0.7.0
        with:
          ssh-private-key: ${{ secrets.SSH_PRIVATE_KEY }}

      - name: Deploy
        run: |
          ./scripts/deploy.sh \
            staging \
            ${{ secrets.SSH_HOST_STAGING }} \
            ${{ secrets.WP_PATH_STAGING }}

  # Job 3: Deploy to production
  deploy-production:
    name: Deploy to Production
    needs: test
    if: github.ref == 'refs/heads/main' && github.event_name == 'workflow_dispatch'
    runs-on: ubuntu-latest
    environment:
      name: production
      url: https://yoursite.com

    steps:
      - uses: actions/checkout@v3

      - name: Setup SSH
        uses: webfactory/ssh-agent@v0.7.0
        with:
          ssh-private-key: ${{ secrets.SSH_PRIVATE_KEY }}

      - name: Deploy
        id: deploy
        run: |
          ./scripts/deploy.sh \
            production \
            ${{ secrets.SSH_HOST_PRODUCTION }} \
            ${{ secrets.WP_PATH_PRODUCTION }}

      - name: Verify
        run: |
          curl -f https://yoursite.com || exit 1

      - name: Notify
        if: always()
        uses: 8398a7/action-slack@v3
        with:
          status: ${{ job.status }}
          text: 'Production deployment: ${{ job.status }}'
          webhook_url: ${{ secrets.SLACK_WEBHOOK }}






Best Practices





Security





    

  1. Never commit secrets – Use GitHub Secrets
    2. 




  2. Restrict SSH access – Use dedicated deploy keys
    3. 




  3. Audit deployments – Enable GitHub audit log
    4. 




  4. Scan for vulnerabilities – Use GitHub’s Dependabot
    5. 






Deployment





    

  1. Always test first – Run CI tests before deploy
    2. 




  2. Use staging – Test on staging before production
    3. 




  3. Backup before deploy – Automatic database backups
    4. 




  4. Enable maintenance mode – During production deployments
    5. 




  5. Monitor after deploy – Check logs and metrics
    6. 






Code Quality





    

  1. Use linters – PHP CodeSniffer, ESLint
    2. 




  2. Run static analysis – PHPStan, Psalm
    3. 




  3. Code coverage – Track test coverage
    4. 




  4. Peer review – Require PR approvals
    5. 






Performance





    

  1. Cache workflows – Cache Composer dependencies
    2. 




  2. Parallel jobs – Run tests in parallel
    3. 




  3. Self-hosted runners – For faster deploys
    4. 






Troubleshooting





Issue 1: SSH Connection Failed





Problem: Permission denied (publickey)





Solutions:





    

  1. Verify SSH key is added to GitHub Secrets correctly
    2. 




  2. Test SSH connection:
    3. 






ssh -i ~/.ssh/github-actions user@server.com






    

  1. Check server’s ~/.ssh/authorized_keys
    2. 




  2. Verify SSH agent setup in workflow
    3. 






Issue 2: Deployment Timeout





Problem: Workflow times out during deployment





Solutions:





    

  1. Increase timeout:
    2. 






jobs:
  deploy:
    timeout-minutes: 30  # Default is 360






    

  1. Optimize deployment script
    2. 




  2. Use caching for dependencies
    3. 






Issue 3: Database Migration Failed





Problem: Migration fails, breaks site





Solutions:





    

  1. Always backup before migrations
    2. 




  2. Test migrations on staging first
    3. 




  3. Use transactions when possible:
    4. 






START TRANSACTION;
-- migration SQL
COMMIT;






    

  1. Implement rollback in migration script
    2. 






Issue 4: Cache Not Cleared





Problem: Changes don’t appear after deployment





Solutions:





    

  1. Add cache clearing to deployment:
    2. 






wp cache flush
wp rewrite flush
wp transient delete --all






    

  1. Clear CDN cache if using one
    2. 




  2. Verify opcache is reset
    3. 






Issue 5: Workflow Fails Silently





Problem: Workflow completes but deployment didn’t work





Solutions:





    

  1. Remove set -e temporarily to see errors
    2. 




  2. Add verbose logging:
    3. 






set -x  # Print commands






    

  1. Check server logs:
    2. 






ssh server "tail -f /var/log/apache2/error.log"






Next Steps





Congratulations! You’ve built a production-ready WordPress CI/CD pipeline.





Enhance Your Pipeline





    

  1. WordPress Multisite CI/CD – Deploy to network
    2. 




  2. Automated Backups – Integrate with deployment
    3. 




  3. Performance Testing – Add to CI
    4. 














Advanced Topics





Add to your pipeline:





    

  • Visual regression testing (BackstopJS, Percy)
    • 




  • Load testing (k6, Apache JBench)
    • 




  • Security scanning (OWASP ZAP)
    • 




  • Accessibility testing (pa11y)
    • 




  • SEO validation
    • 




  • Automated changelogs
    • 






Master WordPress DevOps





Want to build enterprise-grade WordPress automation?





Join WPCLI Mastery and learn:





    

  • Complete CI/CD pipeline templates
    • 




  • Multi-environment WordPress architecture
    • 




  • Blue-green deployments
    • 




  • Automated rollbacks and disaster recovery
    • 




  • Early bird course pricing ($99 vs $199)
    • 






Conclusion





Automated CI/CD pipelines eliminate deployment fear and enable rapid, confident WordPress development. The GitHub Actions workflow you built today provides:





    

  • Automated testing on every push
    • 




  • Safe staging deployments
    • 




  • Controlled production releases
    • 




  • Instant rollback capability
    • 




  • Complete audit trail
    • 






Key takeaways:





    

  • CI/CD catches errors before production
    • 




  • GitHub Actions integrates seamlessly with WordPress
    • 




  • WP-CLI makes WordPress automation possible
    • 




  • Staging → Production workflow ensures safety
    • 




  • Automated rollbacks prevent disasters
    • 




  • Database migrations need careful handling
    • 






The CI/CD pipeline you implemented today is the foundation of professional WordPress DevOps. Deploy with confidence.





Ready to implement? Start with the complete workflow and adapt to your needs.










Questions about WordPress CI/CD? Drop a comment below!





Found this helpful? Share with WordPress developers building automation.





Next: Explore advanced WordPress deployment strategies and zero-downtime techniques.


The post WordPress CI/CD Pipeline with GitHub Actions and WP-CLI appeared first on WP-CLI Mastery.

]]>
					
		
		
			
		
		WordPress Site Cloning and Migration Automation with WP-CLI
		https://wpclimastery.com/blog/wordpress-site-cloning-and-migration-automation-with-wp-cli/
		
		
		Thu, 15 Jan 2026 09:00:00 +0000
				
		
		
		
		
		
		https://wpclimastery.com/?p=143

					Cloning WordPress sites manually means exporting databases through phpMyAdmin, FTPing thousands of files, running search-replace SQL queries that break serialized data, and spending hours fixing broken configurations. One mistake destroys...


The post WordPress Site Cloning and Migration Automation with WP-CLI appeared first on WP-CLI Mastery.

]]>
										Cloning WordPress sites manually means exporting databases through phpMyAdmin, FTPing thousands of files, running search-replace SQL queries that break serialized data, and spending hours fixing broken configurations. One mistake destroys the entire clone.





WP-CLI transforms WordPress cloning and migration into a fast, automated process—clone production to staging in minutes, migrate sites between hosts reliably, and replicate environments for testing without manual intervention or data corruption.





In this guide, you’ll build a complete WordPress site cloning and migration system using WP-CLI, with automated scripts, safety checks, and verification procedures used by professional WordPress agencies.





Why Automate WordPress Cloning and Migration?





WordPress site migration manually is error-prone and doesn’t scale.





Problems with Manual Cloning/Migration





Time-consuming: Manual cloning takes 2-4 hours for medium sites.





Error-prone: Database exports fail, files get missed, URLs break.





Serialized data corruption: Manual search-replace destroys widget settings and options.





No validation: Can’t verify clone completeness or data integrity.





Not repeatable: Each clone requires same tedious manual steps.





WP-CLI Cloning/Migration Advantages





Fast: Clone complete sites in 5-10 minutes instead of hours.





Safe: WordPress-aware operations preserve serialized data.





Scriptable: One-command cloning for any site at any time.





Verifiable: Automated checks ensure complete, accurate clones.





Consistent: Same process every time guarantees reliability.





According to WordPress development surveys, agencies save 20+ hours monthly by automating site cloning for staging and development.





Basic Site Cloning





Clone a WordPress site locally with essential components.





Complete Local Clone Script







#!/bin/bash
# clone-wordpress-site.sh - Clone WordPress site locally

set -euo pipefail

SOURCE_PATH="$1"
DEST_PATH="$2"

if [ -z "$SOURCE_PATH" ] || [ -z "$DEST_PATH" ]; then
    echo "Usage: $0 <source_path> <dest_path>"
    exit 1
fi

echo "Cloning WordPress site..."
echo "Source: $SOURCE_PATH"
echo "Destination: $DEST_PATH"

# Create destination directory
mkdir -p "$DEST_PATH"

# Copy WordPress files
echo "Copying files..."
rsync -av --exclude='wp-content/cache' \
    --exclude='wp-content/backup*' \
    "$SOURCE_PATH/" "$DEST_PATH/"

# Export database from source
echo "Exporting database..."
cd "$SOURCE_PATH"
wp db export /tmp/clone-db.sql

# Create new database config for destination
cd "$DEST_PATH"

# Get source database details
SOURCE_DB=$(wp config get DB_NAME)
SOURCE_USER=$(wp config get DB_USER)
SOURCE_PASS=$(wp config get DB_PASSWORD)

# Create new database
NEW_DB="cloned_${SOURCE_DB}"
mysql -u"$SOURCE_USER" -p"$SOURCE_PASS" -e "CREATE DATABASE IF NOT EXISTS ${NEW_DB};"

# Update wp-config.php
wp config set DB_NAME "$NEW_DB"

# Import database
echo "Importing database..."
wp db import /tmp/clone-db.sql

# Cleanup
rm /tmp/clone-db.sql

# Update URLs if needed
SOURCE_URL=$(wp option get siteurl)
echo "Current site URL: $SOURCE_URL"
read -p "Enter new site URL (or press Enter to keep same): " NEW_URL

if [ -n "$NEW_URL" ]; then
    echo "Updating URLs..."
    wp search-replace "$SOURCE_URL" "$NEW_URL"
    wp option update home "$NEW_URL"
    wp option update siteurl "$NEW_URL"
fi

# Clear caches
wp cache flush
wp rewrite flush

echo "✓ Clone complete: $DEST_PATH"







Run it:







chmod +x clone-wordpress-site.sh
./clone-wordpress-site.sh /var/www/production /var/www/staging







Learn about WordPress directory structure.





Remote Site Migration





Migrate WordPress sites between servers or hosting providers.





Complete Remote Migration Script







#!/bin/bash
# migrate-wordpress-remote.sh - Migrate between servers

set -euo pipefail

SOURCE_HOST="$1"
SOURCE_PATH="$2"
DEST_PATH="$3"
OLD_URL="$4"
NEW_URL="$5"

if [ -z "$NEW_URL" ]; then
    echo "Usage: $0 <source_host> <source_path> <dest_path> <old_url> <new_url>"
    echo "Example: $0 user@old-server.com /var/www/html /var/www/html https://oldsite.com https://newsite.com"
    exit 1
fi

TEMP_DIR="/tmp/wp-migration-$"
DATE=$(date +%Y%m%d_%H%M%S)

mkdir -p "$TEMP_DIR"

echo "=== WordPress Remote Migration Started ==="
echo "From: $SOURCE_HOST:$SOURCE_PATH"
echo "To: $DEST_PATH"
echo "URL: $OLD_URL → $NEW_URL"

# Step 1: Export database from source
echo "Step 1/6: Exporting database from source..."
ssh "$SOURCE_HOST" "cd $SOURCE_PATH && wp db export - | gzip" > "$TEMP_DIR/database.sql.gz"

# Verify database export
DB_SIZE=$(stat -c%s "$TEMP_DIR/database.sql.gz")
if [ "$DB_SIZE" -lt 1000 ]; then
    echo "✗ Database export too small, aborting"
    exit 1
fi

# Step 2: Transfer files from source
echo "Step 2/6: Transferring files from source..."
rsync -avz --progress \
    --exclude='wp-content/cache/*' \
    --exclude='wp-content/backup*' \
    "$SOURCE_HOST:$SOURCE_PATH/" "$DEST_PATH/"

# Step 3: Backup destination (if exists)
if [ -d "$DEST_PATH" ]; then
    echo "Step 3/6: Backing up destination..."
    cd "$DEST_PATH"
    if wp core is-installed 2>/dev/null; then
        wp db export "/backups/dest-before-migration-$DATE.sql.gz" || true
    fi
fi

# Step 4: Import database
echo "Step 4/6: Importing database..."
cd "$DEST_PATH"
wp db import "$TEMP_DIR/database.sql.gz"

# Step 5: Update URLs
echo "Step 5/6: Updating URLs..."
wp search-replace "$OLD_URL" "$NEW_URL" --dry-run --report
wp search-replace "$OLD_URL" "$NEW_URL"
wp search-replace "//$(echo $OLD_URL | sed 's~http[s]*://~~')" "//$(echo $NEW_URL | sed 's~http[s]*://~~')"

# Update WordPress options
wp option update home "$NEW_URL"
wp option update siteurl "$NEW_URL"

# Step 6: Verify and cleanup
echo "Step 6/6: Verifying migration..."
if wp core is-installed; then
    echo "✓ WordPress installation verified"
else
    echo "✗ WordPress verification failed"
    exit 1
fi

if wp db check; then
    echo "✓ Database healthy"
else
    echo "✗ Database issues detected"
    exit 1
fi

# Clear caches
wp cache flush
wp rewrite flush

# Cleanup
rm -rf "$TEMP_DIR"

echo "=== Migration Complete ==="
echo "Site URL: $NEW_URL"
echo "Backup: /backups/dest-before-migration-$DATE.sql.gz"







Push to Production







#!/bin/bash
# push-to-production.sh - Push staging to production

STAGING_PATH="/var/www/staging"
PROD_PATH="/var/www/production"
STAGING_URL="https://staging.example.com"
PROD_URL="https://example.com"

read -p "This will overwrite production. Continue? (y/n) " -n 1 -r
echo
if [[ ! $REPLY =~ ^[Yy]$ ]]; then
    exit 0
fi

# Backup production first
cd "$PROD_PATH"
echo "Backing up production..."
wp db export "/backups/prod-$(date +%Y%m%d_%H%M%S).sql.gz"

# Export from staging
cd "$STAGING_PATH"
echo "Exporting staging..."
wp db export /tmp/staging-push.sql.gz

# Copy files
echo "Copying files..."
rsync -av --delete \
    --exclude='wp-config.php' \
    "$STAGING_PATH/" "$PROD_PATH/"

# Import to production
cd "$PROD_PATH"
echo "Importing database..."
wp db import /tmp/staging-push.sql.gz

# Update URLs
echo "Updating URLs for production..."
wp search-replace "$STAGING_URL" "$PROD_URL"
wp option update home "$PROD_URL"
wp option update siteurl "$PROD_URL"

# Clear caches
wp cache flush
wp rewrite flush

# Cleanup
rm /tmp/staging-push.sql.gz

echo "✓ Staging pushed to production"







Advanced Cloning Features





Add professional features to cloning automation.





Selective Cloning







#!/bin/bash
# selective-clone.sh - Clone only specific components

SOURCE_PATH="$1"
DEST_PATH="$2"
CLONE_TYPE="$3"  # database, files, plugins, themes, uploads

case "$CLONE_TYPE" in
    database)
        echo "Cloning database only..."
        cd "$SOURCE_PATH"
        wp db export /tmp/db-clone.sql.gz
        cd "$DEST_PATH"
        wp db import /tmp/db-clone.sql.gz
        rm /tmp/db-clone.sql.gz
        ;;

    files)
        echo "Cloning files only..."
        rsync -av "$SOURCE_PATH/" "$DEST_PATH/"
        ;;

    plugins)
        echo "Cloning plugins..."
        rsync -av "$SOURCE_PATH/wp-content/plugins/" "$DEST_PATH/wp-content/plugins/"
        ;;

    themes)
        echo "Cloning themes..."
        rsync -av "$SOURCE_PATH/wp-content/themes/" "$DEST_PATH/wp-content/themes/"
        ;;

    uploads)
        echo "Cloning uploads..."
        rsync -av "$SOURCE_PATH/wp-content/uploads/" "$DEST_PATH/wp-content/uploads/"
        ;;

    *)
        echo "Usage: $0 <source> <dest> <database|files|plugins|themes|uploads>"
        exit 1
        ;;
esac

echo "✓ Selective clone complete"







Clone with Sanitization







#!/bin/bash
# clone-sanitized.sh - Clone for development, remove sensitive data

SOURCE_PATH="$1"
DEST_PATH="$2"

# Clone site
bash /usr/local/bin/clone-wordpress-site.sh "$SOURCE_PATH" "$DEST_PATH"

cd "$DEST_PATH"

echo "Sanitizing clone for development..."

# Deactivate security plugins
wp plugin deactivate wordfence sucuri-scanner --quiet

# Remove sensitive data
echo "Removing sensitive user data..."

# Anonymize user emails
for user_id in $(wp user list --field=ID); do
    USERNAME=$(wp user get $user_id --field=user_login)
    wp user update $user_id --user_email="${USERNAME}@example.test"
done

# Remove real passwords (force password reset)
for user_id in $(wp user list --field=ID); do
    wp user update $user_id --user_pass="development"
done

# Remove payment gateway credentials
wp option update woocommerce_stripe_settings '{"enabled":"no"}'
wp option update woocommerce_paypal_settings '{"enabled":"no"}'

# Disable external services
wp plugin deactivate google-analytics mailchimp --quiet

# Enable debug mode
wp config set WP_DEBUG true --raw
wp config set WP_DEBUG_LOG true --raw

echo "✓ Clone sanitized for development"







Multi-Environment Sync





Synchronize WordPress across development, staging, and production.





Environment Sync System







#!/bin/bash
# sync-environments.sh - Sync between dev/staging/prod

OPERATION="$1"  # pull or push
ENV_FROM="$2"   # dev, staging, prod
ENV_TO="$3"     # dev, staging, prod

# Environment paths
declare -A PATHS=(
    ["dev"]="/var/www/dev"
    ["staging"]="/var/www/staging"
    ["prod"]="/var/www/production"
)

# Environment URLs
declare -A URLS=(
    ["dev"]="http://dev.local"
    ["staging"]="https://staging.example.com"
    ["prod"]="https://example.com"
)

if [ -z "$ENV_TO" ]; then
    echo "Usage: $0 <pull|push> <from_env> <to_env>"
    echo "Environments: dev, staging, prod"
    exit 1
fi

SOURCE_PATH="${PATHS[$ENV_FROM]}"
DEST_PATH="${PATHS[$ENV_TO]}"
SOURCE_URL="${URLS[$ENV_FROM]}"
DEST_URL="${URLS[$ENV_TO]}"

echo "Syncing $ENV_FROM → $ENV_TO"

# Confirmation for production
if [ "$ENV_TO" == "prod" ]; then
    read -p "WARNING: Syncing to production. Continue? (y/n) " -n 1 -r
    echo
    if [[ ! $REPLY =~ ^[Yy]$ ]]; then
        exit 0
    fi
fi

# Backup destination
cd "$DEST_PATH"
echo "Backing up $ENV_TO..."
wp db export "/backups/${ENV_TO}-before-sync-$(date +%Y%m%d).sql.gz"

# Clone
cd "$SOURCE_PATH"
wp db export /tmp/env-sync.sql.gz

rsync -av \
    --exclude='wp-config.php' \
    --exclude='wp-content/cache' \
    "$SOURCE_PATH/" "$DEST_PATH/"

cd "$DEST_PATH"
wp db import /tmp/env-sync.sql.gz

# Update URLs
wp search-replace "$SOURCE_URL" "$DEST_URL"
wp option update home "$DEST_URL"
wp option update siteurl "$DEST_URL"

# Clear caches
wp cache flush
wp rewrite flush

rm /tmp/env-sync.sql.gz

echo "✓ Environment sync complete: $ENV_FROM → $ENV_TO"







Clone Verification





Validate clones are complete and functional.





Complete Verification Script







#!/bin/bash
# verify-clone.sh - Verify WordPress clone

CLONE_PATH="$1"

if [ -z "$CLONE_PATH" ]; then
    echo "Usage: $0 <clone_path>"
    exit 1
fi

cd "$CLONE_PATH"

echo "Verifying WordPress clone..."

# Check WordPress is installed
if ! wp core is-installed 2>/dev/null; then
    echo "✗ WordPress not properly installed"
    exit 1
fi
echo "✓ WordPress installed"

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

# Verify post count matches
# (Would need original count passed in for real comparison)
POST_COUNT=$(wp post list --format=count)
echo "✓ Posts: $POST_COUNT"

# Verify user count
USER_COUNT=$(wp user list --format=count)
echo "✓ Users: $USER_COUNT"

# Verify plugins
PLUGIN_COUNT=$(wp plugin list --format=count)
echo "✓ Plugins: $PLUGIN_COUNT"

# Check for broken URLs
SITE_URL=$(wp option get siteurl)
echo "Site URL: $SITE_URL"

# Test site accessibility
if curl -f -s "$SITE_URL" > /dev/null; then
    echo "✓ Site accessible"
else
    echo "✗ Site not accessible"
    exit 1
fi

# Verify file permissions
if [ -w wp-content ]; then
    echo "✓ wp-content writable"
else
    echo "✗ wp-content not writable"
fi

echo "✓ Clone verification complete"







Next Steps





You now have complete WordPress site cloning and migration automation capabilities.









Week 1: Basic cloning





    

  • Practice local clones
    • 




  • Test database operations
    • 




  • Master URL replacement
    • 






Week 2: Remote migrations





    

  • Set up SSH access
    • 




  • Transfer between servers
    • 




  • Handle production pushes
    • 






Week 3: Advanced features





    

  • Selective cloning
    • 




  • Data sanitization
    • 




  • Multi-environment sync
    • 






Week 4: Production deployment





    

  • Build verification systems
    • 




  • Automate complete workflows
    • 




  • Document procedures
    • 






Advanced Topics





    

  1. Blue-Green Deployments – Zero-downtime migrations
    2. 




  2. Database Sync Strategies – Incremental updates
    3. 




  3. Large Site Optimization – Handle massive WordPress sites
    4. 






Get More Resources





Download cloning scripts including:





    

  • Complete automation system
    • 




  • Verification tools
    • 




  • Multi-environment management
    • 






Join our email course for:





    

  • Weekly WP-CLI tutorials
    • 




  • Migration best practices
    • 




  • DevOps workflows
    • 






Conclusion





WordPress site cloning and migration automation with WP-CLI transforms hours of manual work into fast, reliable, one-command operations you can trust.





What we covered:





✅ Complete local site cloning automation 
✅ Remote migration between servers 
✅ Advanced selective and sanitized cloning 
✅ Multi-environment synchronization 
✅ Clone verification and validation 
✅ Production-ready workflows





Master these techniques, and you’ll clone WordPress sites effortlessly—whether creating staging environments, migrating to new hosts, or replicating sites for development.





Ready for more? Learn WordPress backup automation or deployment pipelines.





Questions about WordPress cloning and migration? Drop a comment below!





Found this helpful? Share with other WordPress developers and agencies.


The post WordPress Site Cloning and Migration Automation with WP-CLI appeared first on WP-CLI Mastery.

]]>