การเปลี่ยนไปใช้ PHP 8.x ในสี่ขั้นตอน – บทสัมภาษณ์กับ Juliette Reinders Folmer

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

ในบทความนี้ เราจะจัดการกับคำถามเหล่านี้ (และอีกมากมาย) และดูสิ่งที่เกี่ยวข้องในการเปลี่ยนไปใช้ PHP 8.x อย่างราบรื่นสำหรับไซต์ WordPress ปลั๊กอิน หรือธีมของคุณ รวมถึงแผนงาน

เราจะทำสิ่งนี้โดยอ้างอิงจากการสัมภาษณ์ผู้เชี่ยวชาญ PHP Juliette Reinders Folmer เธออุทิศชีวิตประจำวันส่วนใหญ่ให้กับการเขียนโปรแกรมและทุกสิ่งรอบตัว โดยเน้นไปที่โครงการโอเพ่นซอร์สเป็นหลัก รวมถึง WordPress

คุณพร้อมที่จะเปลี่ยนได้อย่างราบรื่นหรือยัง? สงสัยเกี่ยวกับแผนทีละขั้นตอนของเราหรือไม่? ถ้าอย่างนั้นมาดำน้ำกันเลย!

PHP 8.x — มีอะไรเปลี่ยนแปลงบ้าง

สำหรับภาพรวมของการเปลี่ยนแปลง เราขอแนะนำบทความด้านล่าง:

• บันทึกประจำรุ่นสำหรับ PHP 8.0 และ PHP 8.1
• คู่มือการโยกย้ายสำหรับ PHP 8.0 และ PHP 8.1
• WordPress และ PHP 8.0 และสถานะปัจจุบัน
• มีอะไรใหม่ใน PHP 8.0 และ PHP 8.1

หลังจากอ่านบทความเหล่านี้แล้ว คุณจะได้รับการอัปเดตอย่างสมบูรณ์เกี่ยวกับสิ่งที่เปลี่ยนแปลงใน PHP 8.x และสิ่งที่คุณต้องทำเพื่อให้โครงการ PHP ของคุณดำเนินไปโดยไม่มีปัญหาใดๆ

หากคุณไม่แน่ใจว่าวิธีที่ดีที่สุดในการเริ่มต้นคืออะไร ไม่มีปัญหา ในการสนทนากับ Juliette เราได้พูดถึงรายละเอียดนี้ และเราจะอธิบายให้คุณทราบในบทความนี้อย่างครบถ้วนที่สุดว่าคุณจะเปลี่ยนไปใช้ PHP 8.x ได้อย่างไร

นอกจากนี้ เราจะอธิบายในกล่องข้อมูลถึงวิธีดำเนินการต่างๆ ใน ​​MyKinsta แผงควบคุมที่เป็นกรรมสิทธิ์ของเราสำหรับไซต์ WordPress แอปพลิเคชัน และฐานข้อมูลทั้งหมดของคุณ

การเปลี่ยนไปใช้ PHP 8.x: วิธีเริ่มต้นใช้งาน

การเปลี่ยนไปใช้ PHP 8.x นั้นฟังดูง่ายและในทางเทคนิคแล้ว โฮสต์หลายแห่งอนุญาตให้คุณระบุเวอร์ชันของ PHP ที่คุณต้องการใช้สำหรับเว็บไซต์ของคุณในแผงการดูแลระบบ ที่ Kinsta การเปลี่ยนเวอร์ชัน PHP สามารถทำได้ด้วยการคลิกเพียงครั้งเดียวในแดชบอร์ด MyKinsta

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

• หากคุณสร้างไซต์ WordPress ของคุณเองด้วยธีมและปลั๊กอินมาตรฐานโดยที่ไม่มีความรู้เกี่ยวกับ PHP มากนัก ให้จ้างนักพัฒนาหรือเอเจนซี่เพื่อตรวจสอบว่าไซต์ของคุณเหมาะสมที่จะทำงานบน PHP 8.x หรือไม่ คุณกำลังมองหาบุคคลที่สามที่สามารถช่วยคุณในเรื่องนี้ได้หรือไม่? จากนั้นดูที่หน้าพันธมิตรของเราซึ่งมีรายชื่อบริษัทที่เชื่อถือได้หลายแห่งที่สามารถช่วยเหลือคุณได้
• หากไซต์ WordPress ของคุณสร้างขึ้นโดยบุคคลภายนอก นักพัฒนา หรือหน่วยงาน โปรดติดต่อพวกเขาเพื่อสอบถามว่าไซต์ของคุณสามารถทำงานบน PHP 8.x ได้หรือไม่
• หากคุณสร้างเว็บไซต์ WordPress ด้วยธีมที่คุณกำหนดเอง เช่น หรือปลั๊กอินที่พัฒนาขึ้นเอง เรามีแผนงานสำหรับคุณด้านล่าง

หากไซต์ของคุณอยู่ใน 1 ใน 2 หมวดหมู่แรก เราขอเชิญชวนให้คุณอ่านบทความส่วนที่เหลือทั้งหมด แต่เราไม่แนะนำให้คุณเริ่มทดสอบไซต์ของคุณเพื่อหาความเข้ากันได้ของ PHP 8 ด้วยตัวคุณเอง ปล่อยให้มืออาชีพ

ไม่ว่าคุณจะเลือกแบบใด เราขอแนะนำให้คุณอย่าเพิ่งเปลี่ยนไซต์ที่ใช้งานจริงของคุณเป็น PHP 8 และ “ดูว่ามันใช้ได้หรือไม่” คุณอยากรู้หรือไม่ว่าเว็บไซต์ของคุณจะมีลักษณะอย่างไร และคุณอดใจรอไม่ไหวแล้วที่จะได้เห็นมันทำงานบน PHP 8? จากนั้นเริ่มการทดสอบภายในสภาพแวดล้อมการจัดเตรียม โฮสต์ที่ดีจะช่วยให้คุณสามารถตั้งค่าสภาพแวดล้อมการแสดงละครได้อย่างง่ายดาย

ในสภาพแวดล้อมชั่วคราว คุณสามารถเปิดใช้งาน PHP 8.x และดูว่าการอัปเดตนี้ทำงานได้ดีกับไซต์ของคุณหรือไม่ นอกจากนี้ยังเป็นไปได้ที่จะทำงานกับสำเนาในเครื่องของไซต์ของคุณ ด้วยเครื่องมือพัฒนา DevKinsta ฟรีของเรา คุณสามารถนำเข้าไซต์ของคุณจากแดชบอร์ด MyKinsta หลังจากนั้นคุณสามารถเปลี่ยนเวอร์ชัน PHP เป็น 8.0 หรือ 8.1

หากคุณไม่พบปัญหาใด ๆ ในสภาพแวดล้อมการจัดเตรียม ก็ไม่ได้แปลว่าไม่มีปัญหาใด ๆ จริง ๆ แผนงานด้านล่างจะบอกคุณว่าทำไม

การทดสอบความเข้ากันได้ของ PHP 8.x: แผนงาน

การทดสอบ: คำสำคัญสำหรับซอฟต์แวร์ที่ดี แม้แต่สำหรับเว็บไซต์ WordPress และส่วนประกอบต่างๆ ของเว็บไซต์ เช่น ธีม ปลั๊กอิน และแกนหลักของ WordPress การทดสอบคือวิธีการเพื่อให้แน่ใจว่าจะไม่เกิดสิ่งต่างๆ ที่คุณไม่ต้องการให้เกิดขึ้น

โครงการพัฒนาซอฟต์แวร์ประกอบด้วยการทดสอบเป็นส่วนใหญ่ ในบทความนี้ เราจะดูเฉพาะการทดสอบที่สามารถช่วยให้คุณเปลี่ยนไปใช้ PHP 8.x ได้อย่างราบรื่น ในบทความของเราเกี่ยวกับเครื่องมือ DevOps คุณจะพบส่วนที่มีชุดเครื่องมือที่คุณสามารถใช้ได้

ประเภทของการทดสอบต่อไปนี้จะกล่าวถึงในบล็อกโพสต์นี้:

มาดูการทดสอบประเภทต่างๆ ที่เราสามารถทำได้อย่างใกล้ชิดยิ่งขึ้น

การวิเคราะห์ทางสถิต (หรือการทดสอบทางสถิต)

ขั้นตอนแรกที่คุณสามารถทำได้ในฐานะนักพัฒนา PHP คือทำการวิเคราะห์โค้ดของคุณด้วยเครื่องมือต่างๆ การวิเคราะห์แบบสแตติกคือกระบวนการวิเคราะห์ซอฟต์แวร์โดยไม่ต้องรันโค้ด ด้วยการวิเคราะห์แบบสแตติก ทำให้สามารถตรวจจับข้อผิดพลาด ตรวจพบปัญหาเกี่ยวกับความเข้ากันได้ของ PHP 8.x บังคับใช้มาตรฐานการเข้ารหัส (เช่น WordPress Coding Standards) และแม้แต่การแก้ไขและล้างโค้ดก็เป็นไปได้

เครื่องมือสำหรับการวิเคราะห์แบบคงที่

คุณสามารถทำการวิเคราะห์แบบสแตติกด้วยเครื่องมือต่างๆ เช่น:

• ความเข้ากันได้ของ PHP
• สดุดี
• PHPStan

ในขณะที่เขียน การตรวจสอบ PHP 8.1 บางส่วนไม่ได้รับการสนับสนุนในรีลีสความเข้ากันได้ของ PHP ล่าสุด การตรวจสอบ PHP 8.1 สามารถอยู่ในรุ่นการพัฒนา ดังนั้นตรวจสอบให้แน่ใจว่าคุณใช้สิ่งเหล่านี้ (สำหรับตอนนี้) เมื่อใช้ PHPCompatibility เพื่อวิเคราะห์โครงการของคุณและดูว่ามีข้อผิดพลาด/คำแนะนำใดบ้าง

การตรวจสอบ PHP 8.1 จะออกในเวอร์ชัน หลัก ใหม่เร็วๆ นี้ หากคุณต้องการรับทราบข่าวสารล่าสุด และคุณมีบัญชี GitHub ให้เปิด GitHub repository ของ PHPCompatibility และไปที่ Watch -> Custom -> Releases ซึ่งคุณสามารถเลือกรับการแจ้งเตือนเมื่อมีการเผยแพร่เวอร์ชันใหม่

PHPCompatibility ซึ่งทดสอบความเข้ากันได้สำหรับ PHP รุ่นใดรุ่นหนึ่ง (หรือช่วงของรุ่น) เท่านั้น ตั้งค่าได้ง่าย คุณจะได้ผลลัพธ์ที่ดีที่สุดหากคุณเรียกใช้เวอร์ชันทดสอบ — ตัวอย่างเช่น 8.0+ (8.0 ขึ้นไป) — ภายใน PHPCompatibility

คุณควรมองหาฟังก์ชันที่เลิกใช้แล้วหรือถูกลบ ค่าเริ่มต้นที่เปลี่ยนแปลงของพารามิเตอร์ฟังก์ชัน จะใช้ concat โดยไม่มีวงเล็บหรือไม่ จะใช้การจับคู่เป็นชื่อฟังก์ชันหรือไม่ (เนื่องจากสงวนไว้ตั้งแต่ PHP 8.0 เป็นต้น)

Psalm และ PHPStan เป็นส่วนเสริมที่ดีและสามารถช่วยคุณโดยการตรวจสอบเพิ่มเติมที่เกี่ยวข้องกับประเภทตัวแปร ข้อเสียของเครื่องมือเหล่านี้คือต้องใช้การกำหนดค่าจำนวนมากเพื่อรับรายงานบน PHP 8.0 และ 8.1 แม้ว่าพวกเขาจะประสบความสำเร็จ คุณก็สามารถคาดหวังผลบวกปลอมมากมาย ผลบวกลวงคือการแจ้งเตือนที่ส่งผิด ซึ่งเกิดจากข้อจำกัดของการวิเคราะห์แบบคงที่

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

สรุป:

• ทำการวิเคราะห์แบบคงที่ด้วย PHPCompatibility, Psalm, PHPStan
• แก้ไขปัญหาที่ถูกต้องตามกฎหมายทั้งหมด

การทดสอบหน่วย

ขั้นตอนต่อไปในกระบวนการคือการทดสอบหน่วย การทดสอบหน่วยเป็นวิธีการทดสอบโค้ดทีละชิ้น ในการทดสอบหน่วย จะมีการพัฒนาการทดสอบเป้าหมายเฉพาะสำหรับแต่ละหน่วย สิ่งนี้จะเกี่ยวข้องกับการวิ่งผ่านสถานการณ์ต่างๆ แต่ละสถานการณ์ได้รับการทดสอบแยกต่างหากจากสถานการณ์อื่นๆ เพื่อให้การทดสอบเป็นอิสระจากกัน

แน่นอนว่าการทำ unit test เพียงอย่างเดียวนั้นไม่เพียงพอ พวกเขายังต้องเรียกใช้ การทดสอบหน่วยเป็นแบบอัตโนมัติที่ดีที่สุดโดยใช้เครื่องมือ CI (การผสานรวมอย่างต่อเนื่อง) เช่น Jenkins, GitHub Actions หรือ Travis

รองรับ PHP หลายเวอร์ชั่น

ในฐานะผู้สร้างปลั๊กอิน หากคุณต้องการสนับสนุน PHP หลายเวอร์ชัน ตรวจสอบให้แน่ใจว่าการทดสอบใน CI นั้นรันกับเวอร์ชัน PHP ทั้งหมดที่คุณสนับสนุน

แน่นอน คุณยังสามารถรองรับเฉพาะเวอร์ชันที่ใหม่กว่าได้ ทางเลือกนั้นขึ้นอยู่กับคุณทั้งหมด

การทดสอบกับ PHP หลายเวอร์ชัน คุณจะต้องใช้ PHPUnit หลายเวอร์ชัน ขึ้นอยู่กับเวอร์ชันของ PHP เนื่องจาก PHPUnit ได้แนะนำการเปลี่ยนแปลงหลายอย่างในช่วงหลายปีที่ผ่านมาซึ่งส่งผลต่อการเขียนแบบทดสอบ ส่วนนี้จึงค่อนข้างยุ่งยาก

ในการหลีกเลี่ยงปัญหานี้ คุณสามารถใช้ PHPUnit Polyfills (เขียนโดย Juliette และสนับสนุนโดย Yoast) สิ่งนี้ช่วยให้คุณเขียนการทดสอบที่ไม่รองรับ PHPUnit 9 อย่างเป็นทางการ (และสามารถรันบน PHP 8.x ได้) จากนั้น Polyfills จะทำให้การทดสอบของคุณทำงานใน PHPUnit 4.x ถึง 9.x และกับ PHP 5.4 ถึง PHP 8.1 (ณ ตอนนี้)[/notice]

เมื่อคุณทำการทดสอบแล้ว ขั้นตอนต่อไปคือตรวจสอบให้แน่ใจว่าปัญหาที่พบในการทดสอบได้รับการแก้ไขแล้ว

ครอบคลุมรหัส

การเรียกใช้การทดสอบเหล่านี้เป็นวิธีที่น่าเชื่อถือที่สุดในการค้นหาความเข้ากันไม่ได้ข้ามเวอร์ชัน

ในการทำเช่นนั้น ให้ใส่ใจกับ การครอบคลุมโค้ด ของการทดสอบของคุณ:

• สมมติว่าคุณมีฟังก์ชัน A และได้เขียนการทดสอบสำหรับฟังก์ชันนั้น และฟังก์ชัน A เรียกฟังก์ชัน B, C และ D เป็นส่วนหนึ่งของตรรกะในฟังก์ชัน
• การทดสอบสำหรับฟังก์ชัน A ถูกเขียนขึ้นเพื่อทดสอบตรรกะของฟังก์ชัน A แต่จะเรียกใช้ฟังก์ชัน B, C และ D ในระหว่างการทดสอบด้วย สำหรับฟังก์ชัน B, C และ D โดยปกติแล้วคุณจะทดสอบเฉพาะ "เส้นทางแห่งความสุข" ซึ่งเป็นสถานการณ์ที่ทุกอย่างดำเนินไปได้ด้วยดี ดังนั้น ฟังก์ชันเหล่านั้นจึงยังไม่ได้รับการทดสอบอย่างสมบูรณ์ แม้ว่า (ส่วนหนึ่งของ) โค้ดในฟังก์ชันเหล่านั้นจะเป็น ดำเนินการระหว่างการทดสอบฟังก์ชัน A
• สำหรับการทดสอบแต่ละครั้งของคุณ ให้ระบุรหัสที่กำลังทดสอบโดยเฉพาะ คุณทำได้โดยการให้ @covers การทดสอบแต่ละครั้ง ด้วยวิธีนี้ B, C และ D จะไม่ถูก "นับ" ในการคำนวณความครอบคลุมของโค้ด ซึ่งช่วยให้คุณเห็นว่าการทดสอบครอบคลุมส่วนใดของโค้ดของคุณ

บ่อยครั้งที่นักพัฒนาเขียนและทดสอบ — บางครั้งก็ไม่รู้ตัว — สำหรับ “เส้นทางแห่งความสุข” ในกรณีเหล่านี้ การทดสอบว่าจะเกิดอะไรขึ้นเมื่อมีการส่งผ่านข้อมูลที่ไม่คาดคิดไปยังฟังก์ชันก็เป็นสิ่งจำเป็นเช่นกัน การทดสอบด้วยค่า/ประเภทที่คาดหวังเท่านั้นไม่เพียงพอ

''ในการทดสอบ คุณต้องแน่ใจว่าฟังก์ชันทำในสิ่งที่ควรทำ แต่ฟังก์ชันไม่ได้ทำในสิ่งที่ไม่ควรทำ'' - Juliette Reinders Folmer คลิกเพื่อทวีต

ส่วนที่สองของข้อความข้างต้นมักถูกลืม เมื่อส่วนนั้นสำคัญกว่าส่วนแรกด้วยซ้ำ จะเกิดอะไรขึ้นถ้าคุณสอบผ่านประเภทที่ไม่ถูกต้อง? คุณได้รับข้อความแสดงข้อผิดพลาดหรือไม่? หรือมีการโยนตัวแปรด้วยฟังก์ชันที่ดำเนินต่อไปตามปกติ? จะเกิดอะไรขึ้นหากมีการส่งค่าที่ไม่คาดคิดไปยังฟังก์ชัน

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

PHP เริ่มเข้มงวดขึ้น

PHP มีความแม่นยำมากขึ้น (เข้มงวด) ในการจัดการกับ "ประเภท" สำหรับฟังก์ชันของ PHP เอง เช่นเดียวกับคุณสมบัติไดนามิก การเปลี่ยนแปลงเหล่านี้โดยทั่วไปมีจุดมุ่งหมายเพื่อช่วยให้นักพัฒนาสามารถส่งมอบโค้ดที่ปราศจากข้อผิดพลาด (ก็เช่น โค้ดที่มีข้อผิดพลาดน้อยลง) แต่สิ่งนี้สามารถนำเสนออุปสรรคในการอัปเกรดสำหรับโค้ดที่มีอยู่แล้วซึ่งเขียนขึ้นตามหลักการ "เก่า" ของ PHP

เนื่องจากไดรฟ์นี้สำหรับข้อความแสดงข้อผิดพลาดที่เป็นประโยชน์มากขึ้นใน PHP คุณจะเห็นว่าการสร้างโค้ดที่มีอยู่ให้เหมาะกับ PHP เวอร์ชันใหม่นั้นต้องใช้เวลามากขึ้นเรื่อยๆ การสร้างโค้ดที่ทำงานบน PHP 5.6 เหมาะสำหรับ PHP 7.0 ใช้เวลาเพียงเล็กน้อยในกรณีส่วนใหญ่ เมื่อเทียบกับการอัปเกรดโค้ดเพื่อให้เหมาะกับ PHP 8.1 และนั่นคือความจริงที่ว่า PHP 7.0 เป็นรุ่น "สำคัญ" ในขณะที่ PHP 8.1 เป็นรุ่น "รองลงมา"

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

การทดสอบหน่วยสามารถทำได้ด้วยเครื่องมือต่างๆ รวมถึง:

• PHPUnit
• การเยาะเย้ย
• พฤติกรรม,
• นักเล่าเรื่อง

เครื่องมือเหล่านี้จำนวนมากสร้างขึ้นจากหรือร่วมกับ PHPUnit

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

การทดสอบการรวมระบบ

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

ดังนั้น เมื่อคุณทดสอบโค้ดของปลั๊กอินหรือธีมในบริบทของ WordPress และใช้เวอร์ชันจริง สิ่งเหล่านี้คือการทดสอบการรวมระบบตามคำนิยาม

WP Test Utils (เขียนอีกครั้งโดย Juliette และสนับสนุนโดย Yoast) เป็นเครื่องมือที่ยอดเยี่ยมสำหรับการทดสอบการรวมระบบ WP Test Utils มีเครื่องมือในการเขียนการรวมระบบและการทดสอบหน่วย ซึ่ง WordPress นั้น "จำลองขึ้น" โดยใช้ Brainmonkey และ Mockery โดยที่ฟังก์ชัน WordPress ที่ใช้กันทั่วไปนั้น "ปลอม" เพื่อให้คุณทดสอบโค้ดของคุณเอง ไม่ใช่โค้ด WordPress

การทดสอบการผสานรวมกับ WordPress เป็นเรื่องที่ยุ่งยากกว่าเพราะเกี่ยวข้องกับการผสานรวมกับ WordPress และชุดทดสอบของ WordPress ปลั๊กอินหรือธีมรองรับ WordPress เวอร์ชันใด คุณต้องพิจารณาว่า PHPUnit เวอร์ชันใดรองรับโดย WordPress เพื่อเรียกใช้การทดสอบในเวอร์ชัน PHP ที่แตกต่างกัน

ตัวอย่างเช่น WordPress 5.6 ถึง 5.8 ใช้ PHPUnit 5 ถึง 7 สำหรับการทดสอบ PHP 5.6 ถึง PHP 8.0 แต่ใน WordPress 5.9 WordPress เองก็ใช้ PHPUnit Polyfills เพื่อการสนับสนุนที่กว้างขึ้น WP Test Utils ทำหน้าที่เป็นสะพานเชื่อมเพื่อเอาชนะความแตกต่างเหล่านี้ทั้งหมด

ต้องการเรียนรู้เพิ่มเติมเกี่ยวกับวิธีเรียกใช้การทดสอบการรวมเข้ากับ WordPress เวอร์ชันต่างๆ รวมถึง WordPress 5.9 ขึ้นไปหรือไม่ จากนั้นอ่านเกี่ยวกับเรื่องนี้บนเว็บไซต์ของ WordPress

การทดสอบด้วยตนเอง

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

ตัวอย่างเช่น ตรวจสอบสิ่งนี้กับผู้เขียนปลั๊กอินและดูว่าพวกเขาระบุว่าเข้ากันได้กับ PHP 8.x หรือไม่ แน่นอนว่าคำถามคือวิธีทดสอบปลั๊กอิน บ่อยครั้งที่คำตอบคือ: โดดเดี่ยว โดยปกติแล้ว ฟังก์ชันของปลั๊กอินจะได้รับการทดสอบร่วมกับ WordPress เพียงอย่างเดียว โดยไม่มีปลั๊กอินอื่นๆ ที่ใช้งานอยู่ และแม้ว่าจะมีการใช้ปลั๊กอินอื่นๆ ในการทดสอบเหล่านี้ เป็นไปได้ว่าปลั๊กอินทั้งหมดที่ คุณ ใช้ไม่ได้เป็นส่วนหนึ่งของการทดสอบ ดังนั้นโปรดใช้คำชี้แจงความเข้ากันได้ดังกล่าวด้วยเม็ดเกลือ

ตัวอย่างเช่น ไซต์ WordPress ที่มีปลั๊กอิน 3 ตัว (A, B และ C) เป็นไปได้ว่าปลั๊กอิน B เช่น ส่งคืนประเภทตัวแปรที่ไม่ถูกต้องผ่านตัวกรอง ซึ่งปลั๊กอิน C ที่ใช้ตัวกรองเดียวกันต้องการทำงานด้วย ซึ่งอาจทำให้เกิดข้อผิดพลาดร้ายแรงได้เนื่องจากประเภทไม่ใช่สิ่งที่คาดหวังอีกต่อไป จากนั้นปลั๊กอิน C จะถูกมองว่าเป็นตัวการของข้อความแสดงข้อผิดพลาด แม้ว่าปลั๊กอิน B จะเป็นผู้กระทำผิดจริงก็ตาม

การทำงานร่วมกันของปลั๊กอิน-ความเข้ากันไม่ได้นั้นเป็นไปไม่ได้ที่จะค้นพบเมื่อทำการทดสอบแบบแยกส่วน ยิ่งปลั๊กอินมีการใช้งานมากเท่าไหร่ ก็ยิ่งมีโอกาสเกิดข้อผิดพลาดมากขึ้นเท่านั้น ตัวอย่างเช่น จะเป็นประโยชน์อย่างมากในการส่งคำขอหน้าเว็บจากเว็บไซต์จริงไปยังสภาพแวดล้อมชั่วคราว (โดยเปิดใช้งานการบันทึกข้อผิดพลาด) เพื่อค้นหาว่ามีอะไรผิดปกติเกิดขึ้นจริง

สำหรับปัญหาประเภทนี้ เจ้าของไซต์มักจะเห็นเฉพาะข้อความว่ามีข้อผิดพลาดกับโค้ดที่เรียกใช้ครั้งล่าสุด (ในกรณีนี้ จากปลั๊กอิน C) แม้ว่าปลั๊กอิน C จะไม่ใช่สาเหตุของปัญหาก็ตาม

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

ทดสอบความพร้อมใช้งานสำหรับปลั๊กอินที่ใช้

สำหรับนักพัฒนาและทีมพัฒนา: ยอมรับรหัสเฉพาะเมื่อมีการทดสอบเท่านั้น ด้วยวิธีนี้ คุณจะมั่นใจได้ว่าไม่จำเป็นต้องมีการทดสอบด้วยตนเองน้อยลง ซึ่งช่วยให้คุณประหยัดเวลาได้มาก

ถามกลยุทธ์การทดสอบหากคุณต้องการซื้อปลั๊กอินหรือธีมเชิงพาณิชย์ ด้วยวิธีนี้ เราร่วมกันสร้างการรับรู้ในหมู่นักพัฒนา/ทีมพัฒนาในชุมชน WordPress เพื่อรับการทดสอบที่สูงขึ้นตามวาระการประชุม และเราทุกคนได้รับประโยชน์

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

''กรุณาต่อตัวตนในอนาคตของคุณด้วย ;-)'' - Juliette Reinders Folmer คลิกเพื่อทวีต

บทบาทของโฮสต์ WordPress และ PHP 8.x

สำหรับเจ้าของไซต์ทั่วไป คำแนะนำจากโฮสต์ของคุณเป็นสิ่งที่พึงปรารถนาอย่างยิ่ง พิจารณาสิ่งต่อไปนี้:

• เอกสารและการอัปเดตสำหรับลูกค้าที่ WordPress Core, ปลั๊กอิน และ/หรือธีม (ในบางกรณี) ไม่รองรับ PHP ข้ามเวอร์ชัน
• ตัวเลือกสำหรับการทดสอบ (เช่น การทำงานกับสภาพแวดล้อมชั่วคราว)
• วิธีการรายงานข้อผิดพลาดและติดต่อฝ่ายสนับสนุน

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

การทำให้ PHP 8.0 หรือ 8.1 พร้อมใช้งานสำหรับลูกค้าในฐานะโฮสต์เว็บเป็นสิ่งหนึ่ง แต่ในการทำเช่นนั้น พวกเขาต้องแน่ใจว่าได้สร้างการรับรู้ในหมู่ลูกค้า เพื่อให้พวกเขาตระหนักว่าปัญหาอาจปรากฏขึ้น ขอแนะนำให้ทดสอบไซต์ของคุณในสภาพแวดล้อมชั่วคราวด้วยเวอร์ชันอื่นที่ไม่ใช่เวอร์ชันที่ใช้งานจริง (การเลือกเวอร์ชัน PHP มีให้ใช้งานตามค่าเริ่มต้นที่ Kinsta)

เวอร์ชัน PHP ขั้นต่ำสำหรับ WordPress

ปัจจุบันกว่า 15% ของเว็บไซต์ทั้งหมดใช้ PHP เวอร์ชัน 7.0 หรือต่ำกว่า สามารถดูได้จากสถิติอย่างเป็นทางการของ WordPress ประมาณ 83% ของไซต์ WordPress ทั้งหมดในปัจจุบันใช้ PHP เวอร์ชัน 7.4 หรือต่ำกว่า โปรดทราบว่า PHP ไม่รองรับสิ่งใดที่ต่ำกว่าหรือเท่ากับเวอร์ชัน 7.4 อีกต่อไป การใช้ PHP เวอร์ชันที่หมดอายุการใช้งานอาจส่งผลให้เกิดปัญหาได้ เนื่องจากไม่มีการเผยแพร่การอัปเดตด้านความปลอดภัยอีกต่อไป

เพื่อหลีกเลี่ยงปัญหา สิ่งสำคัญคือเจ้าของไซต์ WordPress จะต้องทราบและแจ้งเกี่ยวกับเวอร์ชัน PHP ขั้นต่ำที่จะช่วยให้ไซต์ของตนทำงานได้อย่างปลอดภัย ในส่วนของเจ้าของไซต์สามารถแก้ไขเวอร์ชัน PHP ได้ด้วยตนเอง (เป็นไปได้ที่ Kinsta สำหรับแพ็คเกจทั้งหมด) หรือขอให้โฮสต์อัปเดตไซต์เป็นเวอร์ชัน PHP ที่ใหม่กว่า ในกรณีที่รุนแรง คุณสามารถเปลี่ยนไปใช้โฮสต์ที่รองรับเวอร์ชันที่ใหม่กว่าเหล่านี้ได้

เนื่องจาก WordPress ต้องการเวอร์ชันขั้นต่ำ 7.4 เท่านั้น จึงไม่มีแรงจูงใจเพียงพอสำหรับโฮสต์และเจ้าของเว็บไซต์จำนวนมากในการอัปเดตไซต์ของตน และนี่คือความจริงที่ว่า PHP 7.4 ถึงจุดสิ้นสุดในเดือนพฤศจิกายน 2022

หาก WordPress เพิ่มเวอร์ชันขั้นต่ำของ PHP นี่อาจหมายความว่าไซต์จำนวนมากจะไม่รองรับการอัปเดต WordPress เวอร์ชันล่าสุดอีกต่อไป อย่างไรก็ตาม การอัปเดตความปลอดภัยจะยังคงได้รับการเผยแพร่สำหรับเวอร์ชันที่ล้าสมัยเหล่านั้นไปอีกระยะหนึ่ง

สรุป

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

• การวิเคราะห์แบบคงที่
• การทดสอบหน่วย
• การทดสอบการบูรณาการ
• การทดสอบด้วยตนเอง

เมื่อเปลี่ยนไปใช้ PHP 8.x ตรวจสอบให้แน่ใจว่า ทุกอย่าง ได้รับการทดสอบอย่างถูกต้อง นี่เป็นวิธีเดียวที่จะรับประกันได้ว่าไซต์ของคุณจะทำงานได้อย่างถูกต้อง รวดเร็ว และปลอดภัยในเวอร์ชัน PHP ที่ใหม่กว่า

เราขอขอบคุณ Juliette อย่างมากสำหรับการมีส่วนร่วมในบทความนี้และสำหรับงานทั้งหมดของเธอเกี่ยวกับเครื่องมือที่กล่าวถึง!

ภาพถ่ายของ Juliette ถ่ายโดย Jip Moors และใช้โดยได้รับอนุญาต