ทำไมการอัปเกรด PHP ถึงทำให้เว็บไซต์ WordPress พัง
การอัปเกรด PHP (ภาษาโปรแกรมที่ใช้สร้างเว็บไซต์ WordPress) เป็นเรื่องที่หลีกเลี่ยงไม่ได้ เพราะเวอร์ชันเก่าจะหมดระยะเวลาการสนับสนุนด้านความปลอดภัย ในวันที่ 31 ธันวาคม 2026 นี้ เวอร์ชัน 8.2 จะสิ้นสุดการสนับสนุนอย่างเป็นทางการ ซึ่งผู้ให้บริการโฮสติ้ง (บริษัทที่ให้เช่าพื้นที่เก็บเว็บไซต์) มักจะทยอยอัปเกรดให้เราโดยอัตโนมัติ
เปรียบเทียบง่ายๆ เหมือนกับการอัปเดตระบบปฏิบัติการในมือถือ ถ้าเราไม่ทำตามรอบที่เขากำหนด วันหนึ่งแอปพลิเคชันที่เราใช้จะเริ่มทำงานไม่ได้ เพราะโค้ดข้างในมันเก่าเกินกว่าจะคุยกับระบบใหม่รู้เรื่อง การอัปเกรด PHP ก็เช่นกัน มันคือการเปลี่ยนเครื่องยนต์ของเว็บไซต์ให้ทันสมัยขึ้นเพื่อความปลอดภัยและประสิทธิภาพที่สูงกว่าเดิม
มือใหม่หลายคนมักตกใจเมื่อเห็นข้อความแจ้งเตือนสีแดงเต็มหน้าจอหลังจากเปลี่ยนเวอร์ชัน PHP จริงๆ แล้ว การแจ้งเตือน (Notice) ส่วนใหญ่ไม่ใช่จุดที่ทำให้เว็บล่ม แต่มันคือการแจ้งว่า "โค้ดตรงนี้เก่าแล้วนะ ควรปรับปรุงในอนาคต" ซึ่งเราสามารถค่อยๆ แก้ไปได้โดยไม่ต้องรีบร้อนจนเสียสติ
แยกให้ออกระหว่าง "คำเตือน" กับ "ข้อผิดพลาดร้ายแรง"
เวลาเราอัปเกรด PHP สิ่งแรกที่มักจะโผล่มาในบันทึกการทำงานของระบบ (Log) คือข้อความจำพวก Deprecated (สิ่งที่จะถูกยกเลิกในอนาคต) เช่น การสร้างคุณสมบัติของคลาสแบบไดนามิก ซึ่ง PHP จะฟ้องว่านี่เป็นวิธีที่ไม่แนะนำให้ใช้แล้วในอนาคต
ตัวอย่างเช่น หากในโค้ดเดิมมีการเรียกใช้งานฟังก์ชันที่รับค่าว่างเข้ามา แต่ PHP เวอร์ชันใหม่เข้มงวดขึ้นในการตรวจสอบข้อมูล มันจะแสดงคำเตือนว่าห้ามส่งค่าว่าง (Null) เข้ามายังพารามิเตอร์ (ตัวแปรที่รับค่าเข้าฟังก์ชัน) ตรงนี้แหละที่มือใหม่มักจะตื่นตระหนก ทั้งที่จริงๆ แล้วเว็บไซต์ยังเปิดใช้งานได้ตามปกติ
ให้จำไว้ว่าถ้าเห็นคำว่า Deprecated หรือ Notice นั่นแปลว่าเว็บไซต์ของคุณยังทำงานได้ แต่มันเป็น "รายการสิ่งที่ต้องทำ" (To-do list) เพื่อให้โค้ดของคุณมีมาตรฐานที่ดีขึ้นในระยะยาว ไม่ใช่เหตุฉุกเฉินที่ต้องรีบแก้ไขเดี๋ยวนี้ครับ
// ตัวอย่างโค้ดที่อาจทำให้เกิดคำเตือนใน PHP รุ่นใหม่
// การส่งค่าว่างเข้าไปในฟังก์ชันที่ต้องการตัวอักษร
strlen(null);
// คำอธิบาย:
// strlen คือฟังก์ชันนับจำนวนตัวอักษร
// ใน PHP 8.1 เป็นต้นไป การใส่ค่า null เข้าไปจะทำให้เกิดคำเตือน Deprecated
// ผลลัพธ์: เว็บไซต์ไม่ล่ม แต่จะมีบันทึกแจ้งเตือนใน Debug Log
ในโค้ดตัวอย่างข้างต้น เรากำลังเรียกใช้ฟังก์ชัน strlen เพื่อหาความยาวของข้อความ แต่เราดันส่งค่า null เข้าไปโดยไม่ได้ตั้งใจ ซึ่ง PHP รุ่นเก่าอาจจะยอมให้ผ่านไปได้ แต่รุ่นใหม่จะเตือนว่าไม่ควรทำแบบนี้ครับ
สาเหตุหลักที่ทำให้เว็บไซต์กลายเป็น "หน้าจอสีขาว"
สิ่งที่น่ากลัวจริงๆ คือ Fatal Error (ข้อผิดพลาดร้ายแรง) ซึ่งจะทำให้หน้าเว็บกลายเป็นสีขาวสนิทหรือขึ้นข้อความว่า "There has been a critical error" สาเหตุส่วนใหญ่มาจากการที่ฟังก์ชันบางอย่างถูกลบออกจาก PHP รุ่นใหม่ไปแล้ว ทำให้โค้ดที่เคยเขียนไว้เรียกใช้งานไม่ได้อีกต่อไป
ตัวอย่างที่พบบ่อยคือการใช้ฟังก์ชันเก่าอย่าง create_function หรือ each ซึ่งถูกถอดออกไปตั้งแต่ PHP 8.0 หากปลั๊กอินหรือธีมที่เราใช้งานยังมีการเรียกใช้ฟังก์ชันเหล่านี้อยู่ เว็บไซต์จะหยุดทำงานทันทีเพราะระบบหาคำสั่งเหล่านั้นไม่เจอแล้ว
สถานการณ์นี้เปรียบเหมือนเราพยายามสั่งงานพนักงานด้วยรหัสลับที่เขาเลิกใช้ไปแล้ว เมื่อเขาฟังไม่เข้าใจ เขาก็เลือกที่จะหยุดทำงานไปเลย ดังนั้นการตรวจสอบว่าปลั๊กอินที่เราใช้อยู่รองรับ PHP เวอร์ชันใหม่หรือไม่ จึงเป็นขั้นตอนที่สำคัญที่สุดก่อนจะกดปุ่มอัปเกรดครับ
// ตัวอย่างฟังก์ชันที่ถูกลบไปแล้วใน PHP 8.0
$callback = create_function('$a', 'return $a * 2;');
// คำอธิบาย:
// create_function เป็นฟังก์ชันที่ล้าสมัยและถูกลบออกไปแล้ว
// หากโค้ดเก่าของคุณยังใช้คำสั่งนี้อยู่ จะเกิด Fatal Error ทันที
// ผลลัพธ์: เว็บไซต์หยุดทำงาน (หน้าขาว) เพราะ PHP หาคำสั่งนี้ไม่เจอ
เมื่อรันโค้ดนี้ใน PHP 8.0 ขึ้นไป ระบบจะแจ้งว่า Call to undefined function ซึ่งหมายถึง "เรียกใช้ฟังก์ชันที่ไม่รู้จัก" นั่นเองครับ
กับดักที่มองไม่เห็น: ตัวสร้างคลาสแบบเก่า
อีกหนึ่งปัญหาที่ตรวจจับได้ยากมากคือ Constructor (ฟังก์ชันที่ทำงานทันทีเมื่อสร้างวัตถุ) แบบเก่า ก่อน PHP 8.0 เราสามารถตั้งชื่อฟังก์ชันให้เหมือนกับชื่อคลาสเพื่อใช้เป็นตัวสร้างวัตถุได้ แต่ในเวอร์ชันปัจจุบัน มันถูกมองว่าเป็นแค่ฟังก์ชันธรรมดาที่ไม่ยอมทำงานอัตโนมัติ
ปัญหานี้ร้ายกาจเพราะมันไม่มีข้อความแจ้งเตือนข้อผิดพลาด (Error) ขึ้นมาให้เห็นเลย วัตถุ (Object) ของคุณจะถูกสร้างขึ้นมาแบบไม่สมบูรณ์ เพราะตัวสร้างไม่ได้ถูกเรียกใช้งาน แล้วเว็บไซต์จะไปพังเอาในขั้นตอนถัดๆ ไปที่พยายามดึงข้อมูลจากวัตถุนั้นมาใช้ ทำให้ไล่หาบั๊กได้ยากมาก
ถ้าคุณกำลังดูแลเว็บไซต์ WordPress เก่าๆ ให้ลองเปิดดูไฟล์โค้ดของปลั๊กอินหรือธีม หากเจอชื่อฟังก์ชันที่เหมือนกับชื่อคลาสในไฟล์เดียวกัน ให้สันนิษฐานไว้ก่อนเลยว่านี่คือระเบิดเวลาที่รอวันทำงานเมื่อย้ายไปใช้ PHP 8.0 ขึ้นไปครับ
// ตัวอย่าง Constructor แบบเก่าที่อันตราย
class Old_Widget {
function Old_Widget() {
// ใน PHP 7 นี่คือตัวสร้างวัตถุ
// ใน PHP 8 นี่คือฟังก์ชันธรรมดาที่ไม่มีใครเรียกใช้
$this->settings = array();
}
}
// อธิบาย:
// ถ้าคลาสนี้ถูกเรียกใช้ใน PHP 8 ตัวแปร $this->settings จะไม่ถูกกำหนดค่า
// ผลลัพธ์: โปรแกรมทำงานต่อได้ แต่จะไปพังในบรรทัดถัดไปที่เรียกใช้ $this->settings
วิธีแก้คือต้องเปลี่ยนชื่อฟังก์ชัน Old_Widget() ให้เป็น __construct() ตามมาตรฐานใหม่ของ PHP เพื่อให้ระบบเข้าใจว่านี่คือฟังก์ชันเริ่มต้นทำงานของคลาสนั่นเองครับ
อย่าปิดการแจ้งเตือนจนมองไม่เห็นความจริง
มือใหม่มักจะตั้งค่าให้เว็บไซต์ "เงียบ" เพื่อไม่ให้ลูกค้าเห็นข้อความแจ้งเตือน แต่การทำแบบนั้นเหมือนการปิดตาตัวเองเวลาขับรถ ในไฟล์ wp-config.php ของ WordPress เราสามารถตั้งค่าให้ระบบจดบันทึกความผิดพลาดไว้ในไฟล์แทนที่จะแสดงให้คนทั่วไปเห็น
ผมแนะนำให้เปิดใช้งาน WP_DEBUG_LOG เพื่อให้มันเขียนข้อมูลลงในไฟล์ debug.log ในโฟลเดอร์ wp-content วิธีนี้จะช่วยให้คุณเห็นว่าเกิดอะไรขึ้นกับเว็บไซต์บ้างโดยที่หน้าเว็บยังดูปกติสำหรับผู้เข้าชมทั่วไป นี่คือหัวใจสำคัญของการแก้บั๊ก เพราะเราต้องเห็นข้อมูลก่อนถึงจะแก้ปัญหาได้ถูกจุด
อย่ากลัวที่จะเห็นข้อความแจ้งเตือนเหล่านั้น เพราะมันคือแผนที่นำทางที่จะบอกคุณว่าไฟล์ไหน บรรทัดไหนที่กำลังมีปัญหา การมีบันทึกเหล่านี้ไว้จะช่วยให้คุณทำงานได้อย่างมั่นใจมากขึ้น ไม่ต้องเดาสุ่มว่าเว็บไซต์พังเพราะอะไรครับ
// การตั้งค่าใน wp-config.php เพื่อตรวจสอบปัญหา
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true ); // บันทึกข้อมูลลงไฟล์ debug.log
define( 'WP_DEBUG_DISPLAY', false ); // ปิดการแสดงข้อความบนหน้าเว็บ
// อธิบาย:
// บรรทัดแรกเปิดระบบดีบั๊ก บรรทัดสองให้เขียนไฟล์ บรรทัดสามซ่อนข้อความจากผู้ใช้
// ผลลัพธ์: ปัญหาจะถูกบันทึกไว้ในไฟล์ debug.log ให้เราเปิดอ่านได้เงียบๆ
หลังจากตั้งค่านี้ ให้ลองเข้าหน้าเว็บไซต์และกดคลิกเมนูต่างๆ ดู หากมีปัญหา ระบบจะบันทึกข้อความแจ้งเตือนลงในไฟล์ debug.log ทันทีครับ
ขั้นตอนการอัปเกรดให้ปลอดภัยที่สุด
การอัปเกรด PHP ไม่ใช่เรื่องที่ต้องทำในคืนเดียวแล้วจบไป คุณควรทำเป็นขั้นตอนเพื่อป้องกันความเสียหายที่อาจเกิดขึ้น เริ่มจากการสำรองข้อมูล (Backup) เว็บไซต์ทั้งหมดไว้ก่อนเสมอ แล้วสร้าง Staging (เว็บไซต์จำลองที่เหมือนตัวจริง) ขึ้นมาเพื่อทดสอบการอัปเกรดในนั้นก่อน
เมื่อเปลี่ยน PHP ในตัวจำลองแล้ว ให้ลองคลิกใช้งานเมนูต่างๆ ที่สำคัญ เช่น ระบบตะกร้าสินค้า ระบบฟอร์มติดต่อ หรือระบบสมาชิก เพราะปัญหาบางอย่างไม่ได้เกิดขึ้นทันทีที่เปิดหน้าเว็บ แต่อาจจะเกิดขึ้นตอนที่มีการบันทึกข้อมูลหรือส่งอีเมล ถ้าตัวจำลองรอดค่อยดำเนินการกับเว็บไซต์จริง
หากคุณใช้เครื่องมืออย่าง CompatNav (ปลั๊กอินตรวจเช็คความเข้ากันได้ของโค้ด) มันจะช่วยวิเคราะห์ไฟล์ทั้งหมดในเซิร์ฟเวอร์ของคุณว่ามีจุดไหนที่เสี่ยงจะพังบ้าง วิธีนี้จะช่วยลดเวลาในการไล่หาโค้ดทีละบรรทัดได้มหาศาลครับ
- สำรองข้อมูลเว็บไซต์ทั้งหมด
- สร้างเว็บไซต์จำลอง (Staging) ขึ้นมาทดสอบ
- เปลี่ยนเวอร์ชัน PHP ในเว็บไซต์จำลอง
- ตรวจสอบปลั๊กอินและธีมผ่านเครื่องมือเช็คความเข้ากันได้
- แก้ไขจุดที่พัง และทดสอบการใช้งานจริงทุกฟังก์ชัน
- อัปเกรดเว็บไซต์จริงเมื่อมั่นใจแล้ว
สรุป: เตรียมตัวดีมีชัยไปกว่าครึ่ง
การอัปเกรด PHP ไม่ใช่เรื่องน่ากลัวถ้าเราเตรียมตัวมาดี หัวใจสำคัญคือการ หมั่นสังเกต Log และ ทดสอบบนสภาพแวดล้อมจำลอง ก่อนเสมอ อย่ารอให้โฮสติ้งบังคับอัปเกรดจนเราไม่มีเวลาเตรียมตัว เพราะนั่นคือจุดที่ทำให้หลายคนต้องปวดหัวกับเว็บไซต์ล่มแบบกะทันหัน
จำไว้ว่าในฐานะโปรแกรมเมอร์หรือผู้ดูแลเว็บไซต์ การเห็นข้อความแจ้งเตือนคือโอกาสในการพัฒนาเว็บไซต์ให้ดียิ่งขึ้น ไม่ใช่เรื่องแย่ครับ หากคุณเจอข้อความที่แปลไม่ออก ให้ลองค้นหาใน Google หรือศึกษาจากคู่มือการแก้ปัญหาทั่วไป แล้วคุณจะพบว่าปัญหาเหล่านั้นมีวิธีแก้ที่ชัดเจนและทำตามได้ไม่ยากเลย
สุดท้ายนี้ ลองนำเครื่องมืออย่างปลั๊กอินตรวจเช็คโค้ดมาลองสแกนเว็บไซต์ตัวเองตั้งแต่วันนี้ดูครับ การทำความสะอาดโค้ดทีละนิดก่อนถึงกำหนดเวลาจะช่วยให้คุณเปลี่ยนผ่านสู่ PHP เวอร์ชันใหม่ได้อย่างราบรื่นและไม่มีสะดุด ขอให้สนุกกับการพัฒนาเว็บไซต์ให้ปลอดภัยและทันสมัยอยู่เสมอครับ
ที่มา: What actually breaks in WordPress when you upgrade PHP (and how to check before your host does it) — DEV Community: laravel