สร้างเว็บทดสอบ (Staging) ก่อนอัปเดตเว็บจริง

การอัปเดตปลั๊กอินบนเว็บจริงแล้วเว็บพังเป็นสถานการณ์ที่เกิดขึ้นบ่อยและเสียหายมากสำหรับร้านค้าออนไลน์ เว็บทดสอบคือสำเนาที่หน้าตาและข้อมูลเหมือนของจริง ใช้ทดลองก่อนว่าจะมีปัญหาหรือไม่

คู่มือนี้สร้างเว็บทดสอบด้วยคำสั่ง ซึ่งทำซ้ำได้และควบคุมได้มากกว่าการใช้ปลั๊กอิน พร้อมขั้นตอนป้องกันสองอย่างที่สำคัญมากและมักถูกลืม คือกัน Google เก็บดัชนีและกันการส่งอีเมลหาลูกค้าจริง

สิ่งที่ต้องเตรียม

• สิทธิ์ SSH และ WP-CLI บนเซิร์ฟเวอร์
• โดเมนย่อยสำหรับเว็บทดสอบ เช่น staging.example.com
• พื้นที่ดิสก์เท่ากับขนาดเว็บจริง

ขั้นตอนที่ 1: สร้างโครงสร้าง

sudo mkdir -p /var/www/staging.example.com
sudo chown -R www-data:www-data /var/www/staging.example.com

# คัดลอกไฟล์ทั้งหมด
sudo rsync -a --exclude='wp-content/cache/' \
  /var/www/example.com/ /var/www/staging.example.com/

ขั้นตอนที่ 2: สร้างฐานข้อมูลและคัดลอกข้อมูล

sudo mysql -e "CREATE DATABASE wp_staging CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;"
sudo mysql -e "CREATE USER 'wp_staging'@'localhost' IDENTIFIED BY 'รหัสผ่าน';"
sudo mysql -e "GRANT ALL ON wp_staging.* TO 'wp_staging'@'localhost';"

cd /var/www/example.com
wp db export /tmp/prod-dump.sql

cd /var/www/staging.example.com
wp config set DB_NAME wp_staging
wp config set DB_USER wp_staging
wp config set DB_PASSWORD 'รหัสผ่าน'
wp db import /tmp/prod-dump.sql
rm /tmp/prod-dump.sql

ขั้นตอนที่ 3: แทนที่ URL ทั้งหมด

URL ของเว็บถูกเก็บไว้หลายที่ รวมถึงในข้อมูลที่เข้ารหัสแบบ serialize ซึ่งการใช้คำสั่ง SQL แทนที่ตรง ๆ จะทำให้ข้อมูลเสียหาย ต้องใช้ WP-CLI ที่จัดการเรื่องนี้ให้

cd /var/www/staging.example.com

wp search-replace 'https://example.com' 'https://staging.example.com' \
  --all-tables --precise --recurse-objects --dry-run

# ตรวจผลแล้วรันจริง
wp search-replace 'https://example.com' 'https://staging.example.com' \
  --all-tables --precise --recurse-objects

wp option get siteurl
wp option get home

รันแบบ --dry-run ก่อนเสมอ เพื่อดูว่าจะแทนที่กี่จุดและในตารางไหนบ้าง

ขั้นตอนที่ 4: กัน Google เก็บดัชนี

ขั้นตอนนี้สำคัญมาก หากเว็บทดสอบถูกเก็บดัชนี จะกลายเป็นเนื้อหาซ้ำที่แข่งกับเว็บจริงในผลการค้นหา

wp option update blog_public 0
wp option get blog_public

เพิ่มการป้องกันอีกชั้นที่ระดับเว็บเซิร์ฟเวอร์ ซึ่งแน่นอนกว่าเพราะไม่ขึ้นกับการตั้งค่าใน WordPress

sudo nano /etc/nginx/sites-available/staging.example.com

server {
    listen 443 ssl;
    server_name staging.example.com;
    root /var/www/staging.example.com;

    add_header X-Robots-Tag "noindex, nofollow, noarchive" always;

    # รหัสผ่านอีกชั้น กันทั้งบอตและคนที่ไม่เกี่ยวข้อง
    auth_basic "Staging";
    auth_basic_user_file /etc/nginx/.staging-users;

    location = /robots.txt {
        add_header Content-Type text/plain;
        return 200 "User-agent: *\nDisallow: /\n";
    }

    # ... ส่วนที่เหลือเหมือนเว็บจริง
}

sudo htpasswd -c /etc/nginx/.staging-users staging
sudo nginx -t && sudo systemctl reload nginx

ขั้นตอนที่ 5: กันการส่งอีเมลหาลูกค้าจริง

ข้อผิดพลาดที่เสียหายที่สุดคือการทดสอบระบบสั่งซื้อบนเว็บทดสอบแล้วอีเมลยืนยันถูกส่งไปหาลูกค้าจริง

cd /var/www/staging.example.com
wp plugin install wp-mail-logging --activate

หรือปิดการส่งอีเมลทั้งหมดด้วยโค้ดใน wp-config.php

// ปิดการส่งอีเมลบนเว็บทดสอบ
if (!function_exists('wp_mail')) {
    function wp_mail($to, $subject, $message, $headers = '', $attachments = array()) {
        error_log('อีเมลถูกระงับบน staging: ' . $subject . ' -> ' . print_r($to, true));
        return true;
    }
}

วิธีนี้ใช้ได้เพราะ WordPress ประกาศ wp_mail เฉพาะเมื่อยังไม่มีฟังก์ชันนี้อยู่ วางไว้ในไฟล์ปลั๊กอินที่โหลดก่อน เช่นใน wp-content/mu-plugins/

ปิดระบบชำระเงินจริงด้วย เปลี่ยนไปใช้โหมดทดสอบของทุกช่องทาง และตัดการเชื่อมต่อกับระบบภายนอก เช่น ระบบขนส่งและระบบบัญชี

ขั้นตอนที่ 6: ทำเครื่องหมายให้เห็นชัดว่าเป็นเว็บทดสอบ

// ใส่ใน mu-plugins แสดงแถบเตือนบนหน้าหลังบ้าน
add_action('admin_notices', function () {
    echo '<div class="notice notice-warning"><p>'
       . '<strong>นี่คือเว็บทดสอบ (Staging)</strong> การเปลี่ยนแปลงที่นี่ไม่มีผลกับเว็บจริง'
       . '</p></div>';
});

add_action('wp_body_open', function () {
    echo '<div style="background:#c00;color:#fff;text-align:center;padding:6px;font-weight:600">'
       . 'STAGING — ข้อมูลในหน้านี้ใช้สำหรับทดสอบเท่านั้น</div>';
});

ขั้นตอนที่ 7: ใช้งานและซิงก์ข้อมูลใหม่

เมื่อต้องการดึงข้อมูลล่าสุดจากเว็บจริงมาทดสอบอีกครั้ง เขียนเป็นสคริปต์ให้ทำซ้ำได้

sudo nano /usr/local/bin/refresh-staging.sh

#!/bin/bash
set -euo pipefail

PROD=/var/www/example.com
STG=/var/www/staging.example.com

# สำรอง staging เดิมไว้ก่อน เผื่อมีงานค้างอยู่
cd "$STG" && wp db export "/tmp/staging-before-$(date +%F-%H%M).sql"

# คัดลอกไฟล์ ยกเว้นคอนฟิกและแคช
rsync -a --delete \
  --exclude='wp-config.php' \
  --exclude='wp-content/cache/' \
  --exclude='wp-content/mu-plugins/staging-guard.php' \
  "$PROD/" "$STG/"

# คัดลอกฐานข้อมูล
cd "$PROD" && wp db export /tmp/prod.sql
cd "$STG" && wp db import /tmp/prod.sql
rm -f /tmp/prod.sql

# ตั้งค่าเฉพาะของ staging กลับคืน
wp search-replace 'https://example.com' 'https://staging.example.com' \
  --all-tables --precise --recurse-objects --quiet
wp option update blog_public 0
wp cache flush

echo "refresh staging เสร็จแล้ว"

ขั้นตอนที่ 8: นำการเปลี่ยนแปลงกลับขึ้นเว็บจริง

อย่าคัดลอกฐานข้อมูลจาก staging ทับเว็บจริง เพราะจะทับออเดอร์และความคิดเห็นที่เกิดขึ้นระหว่างนั้น

แนวทางที่ถูกต้องคือ

• โค้ดและธีม คัดลอกไฟล์ขึ้นไป หรือดีกว่านั้นคือใช้ Git แล้วดึงบนเว็บจริง
• การอัปเดตปลั๊กอิน ทดสอบบน staging แล้วไปกดอัปเดตบนเว็บจริงตามปกติ
• การตั้งค่า จดไว้แล้วตั้งซ้ำบนเว็บจริง หรือส่งออกเฉพาะ option ที่เกี่ยวข้อง

# ส่งออกเฉพาะบางตาราง เช่น ตารางของปลั๊กอินที่เพิ่งตั้งค่า
cd /var/www/staging.example.com
wp db export /tmp/settings.sql --tables=wp_options

ทำบนเว็บจริงในช่วงที่มีผู้ใช้น้อย และสำรองข้อมูลก่อนเสมอ

ปัญหาที่พบบ่อย

เว็บทดสอบเด้งกลับไปเว็บจริง

URL ในฐานข้อมูลยังไม่ถูกแทนที่ครบ ตรวจด้วย wp option get siteurl และรัน search-replace ซ้ำพร้อม --all-tables

Google เจอเว็บทดสอบในผลการค้นหา

ขอให้ลบออกผ่าน Search Console และตั้ง X-Robots-Tag พร้อม Basic Auth ตามขั้นตอนที่ 4 ทันที

อีเมลถูกส่งไปหาลูกค้าจริง

ปิดการส่งอีเมลตามขั้นตอนที่ 5 ก่อน ทดสอบใด ๆ เสมอ และวางไฟล์ไว้ใน mu-plugins ซึ่งไม่ถูกเขียนทับเมื่อซิงก์ไฟล์

รูปภาพไม่ขึ้น

ตรวจสิทธิ์ของโฟลเดอร์ wp-content/uploads และตรวจว่า URL ของรูปถูกแทนที่แล้ว รวมถึงรูปที่อ้างในเนื้อหาแบบพาธเต็ม

ต้องการโฮสติ้งที่มีระบบ Staging ในตัวพร้อมทีมดูแล ติดต่อ THAI DATA CLOUD ได้ที่ https://thaidata.cloud/contact/