WordPress

สร้าง WordPress Staging Site บน cPanel ทดสอบก่อน Deploy

ตั้ง Staging Environment ด้วย Softaculous หรือ Subdomain ทดสอบ Plugin และ Theme อย่างปลอดภัยก่อนนำขึ้น Production

สร้าง WordPress Staging Site บน cPanel ทดสอบก่อน Deploy

Staging Site คืออะไร และทำไมต้องมี?

Staging Site คือสำเนาของเว็บไซต์ Production ที่ทำงานในสภาพแวดล้อมแยกต่างหาก ใช้สำหรับทดสอบการเปลี่ยนแปลงทุกประเภท ไม่ว่าจะเป็นการอัปเดต WordPress Core, ติดตั้ง Plugin ใหม่, ปรับ Theme หรือแก้ไข Code ก่อนที่จะ Push ขึ้นเว็บจริง

หากคุณเคยอัปเดต Plugin แล้วหน้าเว็บพัง หรือเปลี่ยน Theme แล้ว Layout หายหมด คุณจะเข้าใจทันทีว่า Staging Site มีคุณค่าแค่ไหน ความเสียหายที่เกิดบน Staging ไม่มีผลต่อผู้เข้าชมจริงเลยแม้แต่น้อย

วิธีที่ 1: สร้าง Staging ด้วย Softaculous บน cPanel

Softaculous เป็นตัวติดตั้ง WordPress ยอดนิยมที่มาพร้อมกับ cPanel ของ Hosting หลายเจ้า และมีฟีเจอร์ Staging ในตัวที่ใช้งานได้ง่ายมาก

  1. เข้า cPanel แล้วคลิก Softaculous Apps Installer
  2. ไปที่ WordPress แล้วคลิก Installations เพื่อดู WordPress ที่ติดตั้งอยู่
  3. คลิกไอคอน Clone (รูปสำเนา) หน้าติดตั้งที่ต้องการทำ Staging
  4. กรอก Subdomain URL ปลายทาง เช่น staging.yourdomain.com
  5. เลือก Database Name ใหม่ให้ไม่ซ้ำกับ Production
  6. คลิก Clone Installation แล้วรอให้เสร็จ (ประมาณ 1-3 นาที)

เมื่อ Clone เสร็จ Softaculous จะสร้าง WordPress ใหม่ที่ subdomain พร้อม Database และไฟล์ทั้งหมดจาก Production โดยอัตโนมัติ

หมายเหตุ: Softaculous บางเวอร์ชันอาจแสดงปุ่มว่า "Staging" แทน "Clone" ขึ้นอยู่กับเวอร์ชันของ Hosting ผลลัพธ์เหมือนกันทุกประการ

วิธีที่ 2: สร้าง Staging ด้วย Subdomain + File Manager

หากต้องการควบคุมเองแบบ Manual หรือ Softaculous ไม่มีฟีเจอร์ Clone ให้ทำตามขั้นตอนนี้

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

  1. ใน cPanel เปิด Subdomains
  2. กรอก subdomain เช่น staging → Document Root จะเป็น public_html/staging
  3. คลิก Create

ขั้นตอนที่ 2: คัดลอกไฟล์

  1. เปิด File Manager ใน cPanel
  2. เลือกไฟล์และโฟลเดอร์ทั้งหมดใน public_html (ยกเว้นโฟลเดอร์ staging ที่เพิ่งสร้าง)
  3. คลิก Copy แล้วปลายทางเป็น /public_html/staging
  4. รอให้การคัดลอกเสร็จสมบูรณ์

ขั้นตอนที่ 3: สร้างฐานข้อมูลใหม่

  1. ไปที่ MySQL Databases ใน cPanel
  2. สร้าง Database ใหม่ เช่น myuser_staging
  3. สร้าง Database User ใหม่ (หรือใช้ User เดิมได้) แล้ว Add User เข้า Database นั้น
  4. ไปที่ phpMyAdmin เลือก Database เดิม (Production) แล้ว Export ทั้งหมด
  5. Import ไฟล์ SQL นั้นเข้า Database ใหม่ที่สร้าง

ขั้นตอนที่ 4: แก้ไข wp-config.php ใน Staging

เปิดไฟล์ /public_html/staging/wp-config.php แล้วแก้ค่า Database ให้ตรงกับที่สร้างใหม่

// แก้ไขค่าเหล่านี้ใน wp-config.php ของ Staging
define( 'DB_NAME',     'myuser_staging' );
define( 'DB_USER',     'myuser_dbuser' );
define( 'DB_PASSWORD', 'your_db_password' );
define( 'DB_HOST',     'localhost' );

// เพิ่มบรรทัดนี้เพื่อป้องกัน Search Engine index Staging
define( 'DISALLOW_FILE_EDIT', true );

ขั้นตอนที่ 5: อัปเดต URL ใน Database

เนื่องจาก WordPress เก็บ URL ไว้ใน Database คุณต้องเปลี่ยน URL Production เป็น URL Staging ก่อนใช้งาน ทำได้ง่ายสุดผ่าน phpMyAdmin โดยรัน SQL ดังนี้

-- เปลี่ยน siteurl และ home ใน wp_options
UPDATE wp_options
SET option_value = 'https://staging.yourdomain.com'
WHERE option_name IN ('siteurl', 'home');

-- เปลี่ยน URL ที่อยู่ใน Post Content (ถ้ามี absolute URL)
UPDATE wp_posts
SET post_content = REPLACE(
  post_content,
  'https://yourdomain.com',
  'https://staging.yourdomain.com'
);

-- เปลี่ยน URL ใน Post Meta
UPDATE wp_postmeta
SET meta_value = REPLACE(
  meta_value,
  'https://yourdomain.com',
  'https://staging.yourdomain.com'
)
WHERE meta_value LIKE '%yourdomain.com%';
Tip: หากไม่สะดวกใช้ SQL ตรงๆ ลองใช้ Plugin ชื่อ Better Search Replace บน Staging ซึ่งทำหน้าที่เดียวกันผ่านหน้าจอ WordPress Admin ได้เลย ปลอดภัยและมี Preview ก่อน Replace จริง

ป้องกัน Search Engine ไม่ให้ Index Staging Site

สิ่งสำคัญที่สุดที่ต้องทำทันทีหลังตั้ง Staging คือปิดกั้นไม่ให้ Google หรือ Bot อื่นๆ เข้ามา Index เนื่องจากเนื้อหาซ้ำกับ Production จะทำให้ SEO เสียหายได้

  1. เข้า WordPress Admin ของ Staging
  2. ไปที่ Settings → Reading
  3. ติ๊กถูกที่ "Discourage search engines from indexing this site"
  4. คลิก Save Changes

นอกจากนี้ยังสามารถสร้าง .htaccess เพื่อใส่ Password Protection ไว้ด้วย เพื่อให้เฉพาะทีมงานเข้าถึง Staging ได้

# ใส่ไว้ใน .htaccess ของโฟลเดอร์ staging
AuthType Basic
AuthName "Staging Area - Restricted"
AuthUserFile /home/cpanel_user/staging_htpasswd
Require valid-user
Tip: สร้างไฟล์ .htpasswd ได้จาก cPanel → Directory Privacy โดยไม่ต้องสร้างด้วยมือ แค่คลิกเปิดใช้งานและตั้ง Username/Password ก็เสร็จ

Push Staging กลับ Production อย่างปลอดภัย

เมื่อทดสอบบน Staging จนมั่นใจแล้ว ขั้นตอนการ Push กลับ Production สำหรับ cPanel Hosting ทำได้ดังนี้


ตรวจสอบว่า Staging Site ทำงานถูกต้อง

หลังตั้ง Staging เสร็จ ให้ตรวจสอบด้วยขั้นตอนเหล่านี้ผ่าน phpMyAdmin หรือ WordPress Admin

-- 1. ตรวจสอบ URL ที่บันทึกใน Database ว่าเป็น Staging URL แล้ว
SELECT option_name, option_value
FROM wp_options
WHERE option_name IN ('siteurl', 'home');

-- 2. ตรวจสอบ User ที่มีสิทธิ์ Admin
SELECT user_login, user_email
FROM wp_users
JOIN wp_usermeta ON wp_users.ID = wp_usermeta.user_id
WHERE meta_key = 'wp_capabilities'
AND meta_value LIKE '%administrator%';

-- 3. ตรวจสอบ Search Engine Visibility (ต้องเป็น 1 = ปิด)
SELECT option_value FROM wp_options
WHERE option_name = 'blog_public';

-- 4. นับ Post ที่ Published ให้ตรงกับ Production
SELECT post_status, COUNT(*) as total
FROM wp_posts
WHERE post_type = 'post'
GROUP BY post_status;

-- 5. ตรวจสอบ Active Plugins
SELECT option_value FROM wp_options
WHERE option_name = 'active_plugins';
Tip: หาก blog_public คืนค่า 1 แสดงว่าเว็บยังอนุญาต Search Engine Index อยู่ ต้องเข้าไปแก้ที่ Settings → Reading ทันที มิฉะนั้น Google อาจ Index Staging Site และส่งผลเสียต่อ SEO ของ Production

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

Error: "Too many redirects" เมื่อเปิด Staging

เกิดจาก URL ใน Database ยังเป็น Production URL หรือมีการตั้ง Force HTTPS ใน .htaccess ที่ขัดแย้งกัน แก้ไขโดยตรวจสอบค่า siteurl และ home ใน wp_options ให้ตรงกับ Staging URL และลองลบบรรทัด HTTPS Redirect ใน .htaccess ชั่วคราว

Error: "Error establishing a database connection"

ค่า Database ใน wp-config.php ของ Staging ผิด ให้เปิดไฟล์นั้นแล้วตรวจสอบ DB_NAME, DB_USER, DB_PASSWORD ให้ตรงกับ Database และ User ที่สร้างใหม่สำหรับ Staging โดยเฉพาะ

// ตรวจสอบค่าเหล่านี้ใน wp-config.php
define( 'DB_NAME',     'myuser_staging' );  // ชื่อ DB ใหม่
define( 'DB_USER',     'myuser_dbuser' );   // User ที่มีสิทธิ์ DB ใหม่
define( 'DB_PASSWORD', 'correct_password' );
define( 'DB_HOST',     'localhost' );

Error: รูปภาพหายหรือ Broken Image บน Staging

เกิดเมื่อ URL ของรูปภาพใน Database ยังอ้างอิง Production Domain อยู่ ใช้ Plugin Better Search Replace หรือรัน SQL เพื่อ Replace URL ทั้งหมดในตาราง wp_posts และ wp_postmeta ให้เป็น Staging URL แทน

Error: Staging ไม่มี HTTPS หรือ SSL Certificate

Subdomain ใหม่ต้องออก SSL ใหม่แยกต่างหาก เข้า cPanel → SSL/TLSLet's Encrypt SSL แล้วเลือก Subdomain ที่สร้างสำหรับ Staging จากนั้น Issue Certificate ใหม่ได้เลยฟรี

Error: Plugin บาง Plugin ไม่ทำงานเหมือน Production

บาง Plugin ผูกกับ Domain หรือ License Key ที่ Production ทำให้ทำงานไม่ได้บน Staging โดยเฉพาะ Plugin Premium ให้ตรวจสอบหน้า License ของ Plugin นั้น และ Deactivate ชั่วคราวบน Production หากจำเป็น หรือซื้อ License แบบ Dev/Staging ที่หลาย Plugin มีให้


คำถามที่พบบ่อย

Q: Staging Site จะกระทบ Performance ของ Production ไหม?

A: ไม่กระทบ เพราะ Staging ทำงานบน Subdomain แยก มี Database แยก และไฟล์แยกจาก Production อย่างสมบูรณ์ อย่างไรก็ตาม ทั้งสองแชร์ทรัพยากร Server เดียวกัน (CPU/RAM) บน Shared Hosting ดังนั้นหากรัน Load Test บน Staging อาจส่งผลกระทบเล็กน้อยต่อความเร็วของ Production ได้

Q: ต้องสร้าง Staging ใหม่ทุกครั้งที่อยากทดสอบไหม?

A: ไม่จำเป็น Staging Site สามารถคงอยู่ถาวรได้ แต่ควร Sync ข้อมูลจาก Production ก่อนทดสอบครั้งใหม่เสมอ เพื่อให้ Environment ใกล้เคียง Production มากที่สุด Softaculous มีปุ่ม "Sync" ให้ทำสิ่งนี้ได้ง่าย หรือจะ Clone ใหม่ทุกครั้งก็ได้หากต้องการความสดใหม่ 100%

Q: จะรู้ได้อย่างไรว่า Staging พร้อม Push Production แล้ว?

A: ทดสอบ Checklist เหล่านี้ก่อน Push: (1) ฟังก์ชันทุกอย่างบน Staging ทำงานถูกต้อง (2) ทดสอบด้วย Browser หลายชนิดและ Mobile (3) ไม่มี PHP Error ใน Log (4) Page Speed ไม่ลดลงผิดปกติ (5) Form และ WooCommerce Checkout ทดสอบแล้ว หากทุกอย่างผ่าน ค่อย Push ขึ้น Production พร้อม Backup ก่อนเสมอ