PHP 8.2 หมดอายุ 31 ธ.ค. 2569: ต้องทำอะไรตอนนี้

PHP 8.2 จะหมดอายุการซัพพอร์ต (End of Life) ในวันที่ 31 ธันวาคม 2569 หลังวันนั้นโปรเจกต์ PHP จะไม่ออกการแก้ไขความปลอดภัยให้ PHP 8.2 อีก เว็บไซต์ของคุณยังทำงานต่อได้ แต่บั๊ก PHP ร้ายแรงครั้งถัดไป เหมือน PHP2Shell เมื่อเดือนตุลาคม จะไม่ถูกแก้สำหรับ 8.2 ทางออกคือย้ายไป PHP 8.4 (รับการแก้ไขความปลอดภัยถึง 31 ธันวาคม 2571) หรือไป 8.3 (ถึง 31 ธันวาคม 2570) หากมี plugin หรือเฟรมเวิร์กที่คุณใช้ยังไม่รองรับ 8.4 สำหรับเว็บไซต์ WordPress ที่ plugin อัปเดตครบ มักใช้เวลาทดสอบเพียงไม่กี่ชั่วโมง ส่วนโค้ดเก่าที่เขียนเอง plugin ที่เลิกพัฒนาแล้ว และ Docker image จะใช้เวลานานกว่า จึงควรเริ่มในเดือนพฤศจิกายน ไม่ใช่วันที่ 30 ธันวาคม

End of Life หมายความว่าอะไร และไม่ได้หมายความว่าอะไร

• เว็บไซต์ของคุณไม่ได้หยุดทำงานในวันที่ 1 มกราคม PHP 8.2 ยังใช้งานได้ สิ่งที่หยุดคือการส่งการแก้ไขจาก php.net และ Docker image ทางการจะไม่ได้รับการอัปเดตอีก
• ความเสี่ยงเพิ่มขึ้นเรื่อยๆ ช่องโหว่ความปลอดภัยทุกตัวที่พบใน PHP หลัง 31 ธันวาคมจะยังเปิดอยู่บน 8.2 ในเดือนตุลาคม 2569 PHP2Shell แสดงให้เห็นว่าเรื่องนี้สำคัญเพียงใด: การโจมตีเริ่มขึ้นในวันที่การแก้ไขออกมา
• โฮสต์อาจย้ายเวอร์ชันให้คุณ โฮสต์จำนวนมากเปลี่ยนเว็บไซต์ไปใช้ PHP เวอร์ชันใหม่หลัง End of Life บางครั้งแจ้งล่วงหน้าน้อยมาก และบางแห่งคิดเงินเพิ่มหากต้องการคงเวอร์ชันเก่าไว้ การบังคับเปลี่ยนบนเว็บไซต์ที่ไม่เคยทดสอบคือสาเหตุของข้อความ “There has been a critical error on this website”
• ลีนุกซ์ดิสทริบิวชันเป็นกรณีพิเศษ บางดิสทริบิวชันยังคงแพตช์แพ็กเกจ PHP 8.2 ของตัวเองตราบเท่าที่ยังซัพพอร์ตดิสทริบิวชันนั้น หากเซิร์ฟเวอร์ของคุณรัน PHP จากแพ็กเกจของดิสทริบิวชัน ให้ตรวจสอบ security tracker ของดิสทริบิวชันนั้น เรื่องนี้ไม่ใช่กับ build จาก php.net, Docker image ทางการ หรือแผงควบคุมโฮสติ้งส่วนใหญ่

เวอร์ชัน PHP และวันสิ้นสุดการซัพพอร์ต

เวอร์ชัน	วันที่ออก	แก้บั๊กถึง	แก้ไขความปลอดภัยถึง
PHP 8.1 และเก่ากว่า	2564 หรือก่อนหน้า	สิ้นสุดแล้ว	สิ้นสุดแล้ว (8.1 เมื่อ 31 ธันวาคม 2568)
PHP 8.2	8 ธันวาคม 2565	สิ้นสุดเมื่อ 31 ธันวาคม 2567	31 ธันวาคม 2569
PHP 8.3	23 พฤศจิกายน 2566	สิ้นสุดเมื่อ 31 ธันวาคม 2568	31 ธันวาคม 2570
PHP 8.4	21 พฤศจิกายน 2567	31 ธันวาคม 2569	31 ธันวาคม 2571
PHP 8.5	20 พฤศจิกายน 2568	31 ธันวาคม 2570	31 ธันวาคม 2572

PHP แต่ละเวอร์ชันได้รับการแก้บั๊กสองปี แล้วตามด้วยการแก้ไขความปลอดภัยอย่างเดียวอีกสองปี หากคุณใช้ 8.1 หรือเก่ากว่า คุณอยู่โดยไม่มีการแก้ไขใดๆ แล้ว ควรวางแผนอัปเกรดตัวนั้นก่อน

ควรย้ายไปเวอร์ชันไหน

• PHP 8.4 สำหรับเว็บไซต์ส่วนใหญ่ รองรับถึงสิ้นปี 2571 คุณจึงไม่ต้องทำเรื่องนี้ซ้ำในปีหน้า WordPress 6.8 ขึ้นไปรองรับ
• PHP 8.3 หากมีบางอย่างขวาง 8.4 เช่น plugin เก่า ธีม หรือไลบรารีที่ยังไม่อัปเดต ซื้อเวลาให้คุณหนึ่งปี ถึง 31 ธันวาคม 2570
• PHP 8.5 หากเริ่มใหม่หรือสแตกของคุณเป็นเวอร์ชันล่าสุด WordPress รองรับตั้งแต่ 6.9 ส่วน Laravel 12 และ 13 รองรับ plugin จำนวนมากจะผ่านการทดสอบบน 8.5 ช้ากว่า 8.4

สำหรับ Laravel เวอร์ชัน PHP กับเวอร์ชัน Laravel ต้องไปด้วยกัน Laravel 11 รันบน PHP 8.2 ถึง 8.4 แต่การแก้ไขความปลอดภัยของ Laravel เองสิ้นสุดเมื่อ 12 มีนาคม 2569 Laravel 12 รันบน 8.2 ถึง 8.5 และได้รับการแก้ไขความปลอดภัยถึง 24 กุมภาพันธ์ 2570 Laravel 13 ต้องใช้ PHP 8.3 ขึ้นไป แอปบน Laravel 10 หรือ 11 เป็นจังหวะที่ดีที่จะย้ายทั้งสองอย่างพร้อมกัน

ตรวจสอบว่าคุณใช้ PHP เวอร์ชันไหน

• WordPress: Tools, Site Health, Info แล้วดูในส่วน Server จะแสดงเวอร์ชัน PHP
• แผงควบคุมโฮสติ้ง: cPanel, Plesk, DirectAdmin และโฮสต์แบบจัดการให้ส่วนใหญ่แสดงไว้ใต้ PHP settings หรือ “Select PHP version”
• เซิร์ฟเวอร์ของคุณเอง: php -v ในคอมมานด์ไลน์ เว็บเซิร์ฟเวอร์อาจใช้เวอร์ชันต่างจากคอมมานด์ไลน์ จึงควรตรวจหน้า phpinfo() ด้วย แล้วลบทิ้งทันที
• Docker: ดูบรรทัด FROM ใน Dockerfile (เช่น php:8.2-fpm) หรือรัน docker run --rm your-image php -v

คู่มือ PHP 8.2 end of life ของ MigrateXtoY จากเราลงลึกกว่านี้ว่าอะไรจะพังในแต่ละแพลตฟอร์ม (WordPress, WooCommerce, Magento, Laravel, Drupal) และมีเครื่องมืออะไรช่วยได้บ้าง

อะไรอาจพังเมื่ออัปเกรด

การย้ายจาก 8.2 ไป 8.3 หรือ 8.4 เป็นก้าวเล็กๆ เมื่อเทียบกับการข้ามจาก PHP 7 ไป 8 การเปลี่ยนแปลงส่วนใหญ่คือคำเตือน deprecation ใหม่ ซึ่งทำให้ log เต็มแต่ไม่ทำให้เว็บไซต์หยุด สิ่งที่ทำให้เว็บไซต์พังจริงๆ มีดังนี้

• plugin และธีมที่ไม่มีใครอัปเดตมาหลายปี เป็นสาเหตุที่พบบ่อยที่สุดของหน้าจอขาวหรือ critical error หลังเปลี่ยน PHP
• extension ที่ถูกถอดออก PHP 8.4 ไม่มี IMAP, OCI8, PDO_OCI และ Pspell มาให้อีก ย้ายไปอยู่ใน PECL plugin ที่อ่านกล่องจดหมายด้วย imap_open() หรือแอปที่เชื่อมต่อ Oracle ต้องติดตั้ง extension แยกต่างหากหรือหาตัวแทน
• โค้ดที่เขียนเองซึ่งมีคำเตือนที่ถูกเมินมาตลอด deprecation จากเวอร์ชันก่อนๆ กลายเป็น error ในเวอร์ชันหลังๆ หาก log ของคุณเต็มไปด้วยคำเตือนเหล่านี้ ให้แก้ตอนนี้
• Composer dependency ที่กำหนดช่วง PHP ไว้เข้มงวด คำสั่ง composer why-not php 8.4 จะแสดงรายชื่อแพ็กเกจที่ขวางการอัปเกรด

วิธีอัปเกรดโดยไม่มี downtime

1. สำรองข้อมูล ทั้งไฟล์และฐานข้อมูล เก็บไว้นอกเซิร์ฟเวอร์
2. อัปเดตทุกอย่างอื่นก่อน: WordPress core, plugin และธีม หรือแพ็กเกจ Laravel และ Composer ของคุณ ลบ plugin ที่ไม่ได้ใช้
3. ทดสอบบนสำเนา โฮสต์ส่วนใหญ่มีเว็บไซต์ staging ให้ สลับสำเนาไปใช้ PHP เวอร์ชันใหม่และเปิดการบันทึก error (WP_DEBUG_LOG ใน WordPress, log ของ Laravel สำหรับ Laravel)
4. คลิกทดสอบสิ่งที่สร้างรายได้: ฟอร์ม เช็คเอาต์ การชำระเงิน การล็อกอิน การค้นหา งานตามกำหนดเวลา และอีเมลที่เว็บไซต์ส่งออก
5. อ่าน error log แก้ fatal error ก่อนขึ้นระบบจริง ส่วน deprecation จดไว้แก้ทีหลัง
6. สลับเว็บไซต์จริงในช่วงที่เงียบ และเก็บเวอร์ชันเก่าไว้ให้เลือกได้ในแผงควบคุมโฮสติ้ง เพื่อให้ย้อนกลับได้เร็ว
7. สำหรับ Docker: เปลี่ยนบรรทัด FROM build ใหม่ด้วย docker build --pull ตรวจพื้นที่ดิสก์ว่างก่อน build และ deploy ทุก container ใหม่

หากเว็บไซต์พังหลังสลับเวอร์ชันอยู่ดี เช็กลิสต์ของเราเรื่อง เว็บไซต์ WordPress ที่ล่ม อธิบายเรื่อง recovery mode และวิธี roll back

จากงานจริงของเรา: สองรูปแบบที่เส้นตาย PHP มาถึง

เมื่อวันที่ 21 ตุลาคม เราแพตช์แพลตฟอร์ม Laravel ของลูกค้ารายหนึ่งเพื่อรับมือ PHP2Shell แพลตฟอร์มนี้รันใน Docker บน PHP 8.2 บนเซิร์ฟเวอร์คลาวด์เครื่องเดียว การอัปเดตต้องแก้สามอย่างก่อน: Docker image ทางการยังไม่มีเวอร์ชันที่แพตช์แล้ว เราจึง build base image เอง ดิสก์เต็ม 100% เราจึงขยายเป็นสองเท่าจาก 15 เป็น 30 GB และมีมากกว่าเว็บไซต์ที่เปิดสู่อินเทอร์เน็ต เราจึงปิดทุกพอร์ตยกเว้น 80 และ 443 แพลตฟอร์มรัน PHP 8.2.35 ได้ภายในวันเดียวกัน แต่ 8.2.35 แค่ซื้อเวลา: แพลตฟอร์มเดียวกันนี้ตอนนี้ต้องเจอเส้นตาย 31 ธันวาคม และการอัปเกรดในเดือนพฤศจิกายนง่ายกว่าตอนเกิดเหตุฉุกเฉินครั้งหน้า

รูปแบบที่สองคือเรื่องขนาด เราดูแลเว็บไซต์ WordPress มากกว่า 50 เว็บให้เอเจนซี่ออกแบบชาวดัตช์แห่งหนึ่งภายใต้ชื่อของเขา ประมาณ 10 ชั่วโมงต่อเดือนตั้งแต่กรกฎาคม 2569 เมื่อ PHP2Shell ถูกเผยแพร่ เราลงมือกับเว็บไซต์ของเขาภายในไม่กี่นาที วันสิ้นสุดการซัพพอร์ตคืองานเดียวกันในเวอร์ชันช้า: รายการเว็บไซต์ เส้นตาย และการตรวจทีละเว็บ ไม่ว่าคุณจะดูแลหนึ่งเว็บหรือห้าสิบเว็บ งานก็เหมือนกัน: รู้ว่าแต่ละเว็บรันเวอร์ชันไหน ทดสอบก่อนที่โฮสต์จะสลับให้ และมีทางย้อนกลับ

อ่านเพิ่มเกี่ยวกับสิ่งที่เกิดขึ้นในเดือนตุลาคม: PHP2Shell: สิ่งที่ควรทำตอนนี้กับเว็บไซต์ WordPress หรือ Laravel ของคุณ

ค่าใช้จ่าย

ตัวเลือก	ราคา ไม่รวมภาษีมูลค่าเพิ่ม	ควรรู้
ทำเอง	เวลาของคุณ	เหมาะกับเว็บไซต์ WordPress ที่ plugin เป็นเวอร์ชันล่าสุดและมีสำเนา staging ที่โฮสต์
บริษัทโฮสติ้งของคุณ	มักรวมอยู่แล้ว	โฮสต์ส่วนใหญ่สลับเวอร์ชันให้ แต่น้อยรายที่ทดสอบเว็บไซต์ของคุณหรือแก้สิ่งที่พัง
บัตรชั่วโมง WDDW	฿25,900 สำหรับ 14 ชั่วโมง	ชั่วโมงที่ชำระล่วงหน้าสำหรับการอัปเกรด การทดสอบ และการแก้ไข โดยยังเหลือชั่วโมงสำหรับการอัปเดตตามปกติ
บริการช่วยเหลือฉุกเฉิน WDDW	฿2,200 ต่อชั่วโมง ไม่มีขั้นต่ำ	หากโฮสต์สลับเวอร์ชันไปแล้วและเว็บไซต์ล่ม: นักพัฒนาอาวุโสเริ่มงานภายในวันเดียวกัน

อยากให้อัปเดต PHP และ plugin เป็นงานประจำทุกเดือนแทนที่จะต้องรีบทำ? ดู ค่าบำรุงรักษาเว็บไซต์ เอเจนซี่ที่มีเว็บไซต์ลูกค้าจำนวนมากอ่านได้ว่าเราทำงานภายใต้ชื่อของเขาอย่างไรใน การบำรุงรักษา WordPress สำหรับเอเจนซี่

อัปเกรดก่อนถึงเส้นตาย

ส่งที่อยู่เว็บไซต์ของคุณมาให้เรา นักพัฒนาอาวุโสจะตรวจว่าเว็บไซต์รัน PHP เวอร์ชันไหน ทดสอบบน PHP 8.4 บนสำเนา แก้สิ่งที่พัง และสลับเว็บไซต์จริงโดยมีทางย้อนกลับ WordPress, WooCommerce, Laravel หรือ Docker: เราทำงานกับโฮสติ้งที่คุณมีอยู่ ติดต่อเรา → หรือหากเว็บไซต์ล่มอยู่แล้ว ขอความช่วยเหลือฉุกเฉิน

เปิดเอเจนซี่อยู่? เราอัปเกรดเว็บไซต์ลูกค้าของคุณภายใต้ชื่อของคุณ ภายใต้ NDA จนถึง 31 ธันวาคม: ซื้อบัตรชั่วโมง 2 ใบ แถมฟรี 1 ใบ ดูข้อเสนอสำหรับเอเจนซี่ →

ตรวจสอบข้อเท็จจริงเมื่อ 6 พฤศจิกายน 2569 แหล่งที่มา: PHP supported versions, PHP 8.4 migration guide, WordPress PHP compatibility, Laravel support policy