PHP 8.2 หมดซัพพอร์ต 31 ธ.ค. 2026: ย้ายไปรุ่นไหน WordPress, Laravel และ RHEL กระทบอย่างไร

หลัง PHP 8.2 หมดซัพพอร์ต WordPress และ Laravel ต้องใช้ PHP รุ่นไหน

หน้า Requirements ของ WordPress แนะนำให้โฮสต์รองรับ PHP 8.3 ขึ้นไป ร่วมกับ MariaDB 10.11 หรือ MySQL 8.0 ขึ้นไป WordPress ยังทำงานบน PHP 7.4 ขึ้นไปได้ในสภาพแวดล้อมเก่า แต่หน้าเดียวกันเตือนว่ารุ่นเหล่านั้นหมดอายุแล้วและอาจทำให้เว็บเสี่ยงต่อช่องโหว่ นอกจากตัว WordPress แล้ว ปลั๊กอินและธีมแต่ละตัวมีข้อกำหนด PHP ของตัวเอง จึงต้องทดสอบด้วย

ฝั่ง Laravel นโยบายคือแก้บั๊ก 18 เดือนและแพตช์ความปลอดภัย 2 ปีต่อรุ่น ตารางในเอกสาร Laravel 13 ระบุว่า

แอป Laravel 12 บน PHP 8.2 จึงมีเส้นตายซ้อนกัน 2 ชั้น คือ PHP 8.2 หมดซัพพอร์ตสิ้นปีนี้ และ Laravel 12 หมดแพตช์ความปลอดภัย 24 กุมภาพันธ์ 2027 ทางที่ประหยัดแรงคือขึ้น PHP 8.3 ขึ้นไปก่อน ซึ่ง Laravel 12 รองรับ แล้วต่อด้วย Laravel 13 ที่ต้องใช้ PHP 8.3 ขึ้นไปอยู่แล้ว

ใช้ PHP 8.2 จาก Red Hat หรือ Debian วันหมดอายุต่างกันอย่างไร

วันที่ PHP 8.2 หมดซัพพอร์ต 31 ธันวาคม 2026 เป็นวันของ php.net สำหรับซอร์สและรุ่นที่ทีม PHP ออกเอง ส่วนแพ็กเกจที่มากับดิสทริบิวชัน Linux ผู้ขายจะดูแลตามรอบของตัวเอง

• Red Hat Enterprise Linux หน้าวงจรชีวิต Application Streams ระบุว่า PHP 8.2 เข้ามาใน RHEL 8.10 และ RHEL 9.4 เมื่อพฤษภาคม 2024 และมีวันเลิกดูแล (retirement) คือพฤษภาคม 2029 ส่วน RHEL 10 มี PHP 8.3 ตั้งแต่รุ่น 10.0 และ PHP 8.4 ตั้งแต่ 10.2 ซึ่งดูแลถึงพฤษภาคม 2029 เช่นกัน
• Debian ชุดแพ็กเกจของ Debian 12 (bookworm) ใช้ PHP 8.2 เป็นค่าเริ่มต้น ส่วน Debian 13 (trixie) ใช้ PHP 8.4 หน้าข้อมูลรุ่นระบุว่า Debian 12 ได้ Long Term Support ถึง 30 มิถุนายน 2028 เฉพาะสถาปัตยกรรม i386, amd64, armhf, arm64 และ ppc64el

ข้อนี้ไม่ได้แปลว่าผู้ใช้ RHEL หรือ Debian ไม่ต้องทำอะไร ผู้ขายนำการแก้ไขมาใส่ในแพ็กเกจเอง (backport) โดยเลขเวอร์ชันอาจไม่เปลี่ยน ทีมจึงต้องติดตามประกาศของผู้ขายเอง และไลบรารีจาก Composer หรือปลั๊กอิน WordPress ก็อาจเลิกรองรับ PHP 8.2 ตามรอบของ php.net โดยไม่สนว่าดิสทริบิวชันยังดูแลอยู่ ส่วน PHP ที่ติดตั้งจากคลังของบุคคลที่สามหรือคอมไพล์เองจะไม่ได้ประโยชน์จากรอบของผู้ขายเลย

สิ่งที่ต้องตรวจก่อน PHP 8.2 หมดซัพพอร์ต

1. ทำบัญชีว่า PHP 8.2 อยู่ที่ไหนบ้าง ทั้งเซิร์ฟเวอร์ โฮสติ้งแบบแชร์ คอนเทนเนอร์ที่อ้าง image PHP 8.2 และเครื่อง CI ระบบเล็กที่ถูกลืมคือจุดที่ตกหล่นจากการอัปเดตได้ง่ายที่สุด
2. แยกว่าแต่ละเครื่องได้ PHP มาจากไหน แพ็กเกจของ RHEL หรือ Debian ใช้วันของผู้ขาย ส่วนรุ่นจาก php.net คลังบุคคลที่สาม หรือ image ที่สร้างเอง ใช้วันที่ PHP 8.2 หมดซัพพอร์ตตาม php.net คือ 31 ธันวาคม 2026
3. ตรวจข้อกำหนด PHP ของโค้ด เช่น ค่า require.php ใน composer.json รุ่นของเฟรมเวิร์ก และส่วนขยาย (extension) ที่ต้องใช้ แล้วอ่าน Migration guide ของรุ่นปลายทาง
4. ทดสอบบนสำเนาก่อนเปลี่ยนจริง โดยเฉพาะเว็บ WordPress ที่มีปลั๊กอินจำนวนมาก และกำหนดวันสลับให้เสร็จก่อนช่วงวันหยุดปลายปี

ถ้าย้ายไม่ทันก่อน PHP 8.2 หมดซัพพอร์ต

บางระบบอาจย้ายไม่ทันสิ้นปี เช่น ระบบที่ผู้รับจ้างพัฒนาไว้นานแล้วและไม่มีคนดูแลโค้ด ทางที่มีเอกสารรองรับในตอนนี้คือย้ายไปใช้แพ็กเกจ PHP 8.2 ของดิสทริบิวชันที่ผู้ขายยังดูแลอยู่ เช่น RHEL 8 หรือ 9 ซึ่ง Red Hat ระบุวันเลิกดูแลไว้ที่พฤษภาคม 2029 แต่ควรมองเป็นทางชั่วคราวเท่านั้น เพราะไลบรารีและปลั๊กอินจะทยอยเลิกรองรับ PHP 8.2 ไปเรื่อย ๆ

ระหว่างที่ยังค้างอยู่หลัง PHP 8.2 หมดซัพพอร์ต ควรลดความเสี่ยงด้วยการจำกัดว่าใครเข้าถึงระบบได้ ปิดหน้าที่ไม่จำเป็นจากอินเทอร์เน็ต เก็บ log ให้ตรวจย้อนได้ และกำหนดวันย้ายที่แน่นอนพร้อมเจ้าของงาน แทนที่จะปล่อยไว้โดยไม่มีแผน

ผลต่อองค์กรไทยและทีมพัฒนา

เว็บ WordPress หรือ Laravel ที่อยู่บนโฮสติ้งแบบแชร์ใช้ PHP รุ่นที่ผู้ให้บริการเปิดให้เลือกเท่านั้น เจ้าของเว็บจึงต้องรู้ทั้งรุ่นที่ใช้อยู่และแผนของผู้ให้บริการ เหตุการณ์ PHP2Shell ที่หน่วยงานไทยต้องออกมาตรการรับมือ แสดงให้เห็นว่าการรู้ว่าเว็บของตัวเองใช้ PHP รุ่นไหนสำคัญแค่ไหน

• ถามผู้ให้บริการโฮสติ้งตอนนี้ ว่าจะย้ายลูกค้าออกจาก PHP 8.2 เมื่อไร และเปิดให้เลือก PHP 8.3, 8.4 หรือ 8.5 ได้หรือยัง
• ทีมพัฒนาใส่การย้าย PHP ในแผนงานเดือนพฤศจิกายน แทนที่จะรอจนสัปดาห์สุดท้ายของปี และถือโอกาสเลือกรุ่นที่ซัพพอร์ตยาวถึงปี 2028–2029
• ฝ่ายไอทีที่ใช้ RHEL หรือ Debian บันทึกวันของผู้ขายไว้ในทะเบียนระบบ และตรวจว่าแอปไม่ได้ติดตั้ง PHP จากคลังภายนอกซ้อนไว้
• ติดตามข่าวรอบซัพพอร์ตของภาษาและเฟรมเวิร์กอื่นได้ที่หมวดการพัฒนาซอฟต์แวร์