PHP 8.2: WordPress, Plugins และ Developers มีความหมายอย่างไร?

เผยแพร่แล้ว: 2022-12-14

PHP 8.2.0 เปิดตัวเมื่อวันที่ 8 ธันวาคม 2022 ในฐานะการอัปเดตครั้งใหญ่ มีการปรับปรุงประสิทธิภาพ ไวยากรณ์ที่ง่ายขึ้น และความปลอดภัยของประเภทที่มากขึ้นด้วย null , false และ true เป็นประเภทสแตนด์อโลน หนึ่งในการเปลี่ยนแปลงที่ใหญ่ที่สุดที่น่าจะท้าทายนักพัฒนา WordPress คือการแนะนำคลาสแบบ อ่าน อย่างเดียว ซึ่งไม่อนุญาตให้ใช้คุณสมบัติไดนามิก

คุณสมบัติไดนามิกเลิกใช้งานแล้วและจะทำให้เกิดข้อผิดพลาดร้ายแรงใน PHP 9 หรืออาจเป็น PHP 10 ในขณะที่อาจสร้างความเจ็บปวด — โดยเฉพาะอย่างยิ่งสำหรับแกนหลักของ WordPress — การเลิกใช้งานเป็นคุณสมบัติหลักและของขวัญสำหรับนักพัฒนาจาก PHP

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

ติดตามการพัฒนา PHP ใน WordPress

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

ตรงกันข้ามกับ WooCommerce ซึ่งต้องใช้ PHP 7.4 เป็นอย่างต่ำ ปัจจุบัน WordPress core แนะนำเฉพาะ PHP 7.4 หรือสูงกว่าเท่านั้น "ยังใช้งานได้กับ" PHP 5.6.20 ซึ่งถึงวันหมดอายุเมื่อสิ้นปี 2018 โครงการ WordPress บันทึกสิ่งนี้และเตือนว่าการใช้ PHP เวอร์ชันที่ไม่รองรับ "อาจทำให้ไซต์ของคุณเสี่ยงต่อความปลอดภัย" (ข้อกำหนดของ WordPress.org)

โชคดีที่ปัจจุบันมีเพียง 5.1% ของไซต์ WordPress ทั้งหมดที่ใช้ PHP 5.6 และมีเพียง 2% เท่านั้นที่ใช้เวอร์ชันที่เก่ากว่า 20% กำลังใช้ PHP 7.0 ถึง 7.3 และกลุ่มที่ใหญ่ที่สุด (56.7%) กำลังใช้ PHP 7.4 (สถิติ WordPress.org)

น่าเสียดายที่ PHP 7.4 เพิ่งถึงวัน EOL เมื่อปลายเดือนพฤศจิกายน 2022 PHP 8.0 เหลือเวลาน้อยกว่าหนึ่งปีสำหรับการสนับสนุนด้านความปลอดภัยอย่างเป็นทางการจนถึงเกือบปี 2023 เวอร์ชันปัจจุบันและที่ได้รับการสนับสนุนอย่างแข็งขัน PHP 8.1 จะหมดลงในตอนท้าย ของปี 2024 PHP 8.2 ซึ่งเพิ่งเปิดตัวเสถียรเป็นครั้งแรก จะมีการสนับสนุนด้านความปลอดภัยจนถึงเดือนธันวาคม 2025

นี่เป็นวงจรการเปิดตัวที่รวดเร็ว และไม่น่าแปลกใจที่ระบบนิเวศของ WordPress จะพยายามตามให้ทัน ด้วยจำนวนเว็บมากกว่าครึ่งที่ทำงานบน WordPress จึงเป็นเรือลำใหญ่ที่ไม่สามารถเลี้ยวได้อย่างรวดเร็ว มันเป็นการกระทำที่สมดุลมากกว่าการแข่งขันไปสู่ขอบเลือด การข้ามไปใช้ PHP 8 มีคุณประโยชน์มากมาย อย่างไรก็ตาม ด้วยคุณสมบัติการเพิ่มประสิทธิภาพขนาดใหญ่ เช่น การคอมไพล์ PHP แบบ Just-in-Time (JIT) ที่รันไทม์เพื่อการดำเนินการที่รวดเร็วขึ้นโดยใช้หน่วยความจำน้อยลง

การแลกเปลี่ยนระหว่างความเข้ากันได้แบบย้อนกลับและความเสถียร การคิดไปข้างหน้าและนวัตกรรม

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

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

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

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

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

เวลาที่ดีที่สุดในการเพิ่มความต้องการขั้นต่ำของ PHP

การเปิดตัว iThemes Security Pro 7.2 เป็นตัวอย่างที่ดีในการเพิ่มความต้องการ PHP ขั้นต่ำของผลิตภัณฑ์ WordPress เพื่อมอบทั้งนวัตกรรมและความเสถียรให้กับลูกค้าปัจจุบัน

ในการเปิดตัวเวอร์ชั่น 7.2 นั้น iThemes Security Pro ต้องการ PHP 7.3 หรือสูงกว่าและรองรับสูงสุด 8.1 การตัดสินใจอัปเดตข้อกำหนด PHP สำหรับ iThemes Security Pro นั้นเกิดจากการนำเฟรมเวิร์ก WebAuthn ไปใช้ การใช้งานจำเป็นต้องมีไลบรารีที่ต้องการ PHP 7.3+ เพื่อจัดการการเข้ารหัสและคีย์สาธารณะ คุณลักษณะการเข้าสู่ระบบ 2FA, รหัสผ่าน และไบโอเมตริกที่แนะนำใน iThemes Security Pro 7.2 เป็นผลโดยตรงจากการตัดสินใจนี้ ในเวลาที่รหัสผ่านที่ชัดเจนใช้งานไม่ได้ ทีมรักษาความปลอดภัยของ iThemes ได้นำการเข้าสู่ระบบแบบไม่ใช้รหัสผ่านมาสู่ WordPress เป็นครั้งแรกในฐานะประสบการณ์การตรวจสอบผู้ใช้หลัก

เป็นไปได้ที่จะสร้างคุณลักษณะเหล่านี้โดยการเขียนไลบรารี WebAuthn ใหม่เพื่อให้เข้ากันได้กับ PHP เวอร์ชันเก่า แน่นอนว่าจะต้องทำงานมากขึ้นและสร้างรหัสเพิ่มเติมเพื่อบำรุงรักษา หลักสูตรที่ฉลาดกว่าคือการติดตามชุมชน PHP ในระดับปานกลางโดยการใช้การอ้างอิงที่ต้องใช้ PHP 7.3 หรือสูงกว่า ผู้ใช้ส่วนใหญ่อยู่ที่นั่นแล้ว นั่นเป็นเหตุผลที่ทีมพัฒนา iThemes Security ตัดสินใจที่จะเพิ่มข้อกำหนดขั้นต่ำของ PHP สำหรับผู้ใช้ใหม่และผู้ใช้ปัจจุบัน

สำหรับผลิตภัณฑ์ WordPress ที่ลงทุนอย่างมากในโปรแกรมแก้ไขบล็อก Gutenberg เช่น GiveWP การจัดการการเปลี่ยนแปลงอาจเป็นเรื่องที่ท้าทายมากยิ่งขึ้น ความเสถียรและอัตราการเปลี่ยนแปลงที่ช้าในคอร์ WordPress อาจทำให้นักพัฒนา PHP แบ็กเอนด์ผิดหวัง แต่สิ่งนี้ทำให้นักพัฒนา JavaScript/React ของฟรอนต์เอนด์สามารถขับเคลื่อนแพลตฟอร์มไปข้างหน้าได้

Jason Adams ผู้จัดการฝ่ายพัฒนาของ GiveWP ตั้งข้อสังเกตว่าพวกเขาไม่จำเป็นต้องเข้ากันได้แบบย้อนหลัง เพราะพวกเขาสามารถโยกย้ายผู้ใช้ข้ามเวอร์ชันได้เมื่อเครื่องมือแก้ไขไซต์พัฒนาขึ้น อย่างไรก็ตาม “ไม่มีสิ่งที่เรียกว่าการโยกย้ายสำหรับ PHP” เขาแสดงความคิดเห็น ในที่สุด พวกเขาจะต้องปรับให้เข้ากับสถาปัตยกรรม PHP 9 และออกห่างจากคุณลักษณะที่เลิกใช้งานใหม่ใน PHP 8.2

ไม่มี "เวลาที่เหมาะสม" เดียวสำหรับทุกผลิตภัณฑ์ในระบบนิเวศของ WordPress ในการอัปเดตข้อกำหนดขั้นต่ำของ PHP “มันไม่ใช่ปัญหาที่คุณสามารถแก้ไขได้ด้วยปรัชญา” อดัมส์บอกฉัน ขึ้นอยู่กับการตัดสินโดยพิจารณาจากจำนวนผู้ใช้ที่จะได้รับผลกระทบในทางลบจากการเปลี่ยนแปลง หาก 90% ขึ้นไปอยู่ใน PHP 7.2 หรือ 7.4 การเพิ่มข้อกำหนดขั้นต่ำเป็นระดับนั้นสามารถทำได้

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

ประกาศเลิกใช้ขับเคลื่อนการพัฒนาไปข้างหน้า

WordPress.com เพิ่งเปิดตัว PHP 8.2 เป็นตัวเลือกสำหรับแผนธุรกิจและอีคอมเมิร์ซที่เปิดใช้งานฟีเจอร์โฮสติ้ง และในระบบนิเวศของ WordPress.org โค้ดเก่าที่ผ่านการออกแบบมาอย่างดีไม่น่าจะพังหรือไม่ปลอดภัยด้วย PHP เวอร์ชันหลักถัดไป ปล่อย. แม้ว่าโค้ดเบสหลักของ WordPress.org จะรองรับเฉพาะ "เบต้า" สำหรับ PHP 8.0 อย่างเป็นทางการ แต่โดยทั่วไปก็ใช้งานได้ดีกับ PHP เวอร์ชันล่าสุด และปลั๊กอินที่รองรับอย่างดีก็เช่นกัน พวกเขาจะไม่ส่งข้อผิดพลาดร้ายแรงหรือแยกวิเคราะห์ คุณไม่ควรเห็นคำเตือนมากมายเมื่อเปิดการดีบัก คุณอาจเห็นประกาศเกี่ยวกับฟังก์ชันที่เลิกใช้งานจำนวนมาก ซึ่งยังไม่มีข้อผิดพลาด

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

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

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

Timothy Jacobs หัวหน้าผู้พัฒนาด้านความปลอดภัยของ iThemes และ WordPress Core Committer กล่าวว่าการมีคำเตือนการเลิกใช้งานเป็นเรื่องดี พวกเขาผลักดันนักพัฒนาไปสู่การยอมรับโค้ดที่ "ถูกต้องมากขึ้น" และ "เปราะบางน้อยลง" ซึ่งจะมีความปลอดภัยมากขึ้น มีประสิทธิภาพมากขึ้น ป้องกันข้อผิดพลาด และสามารถรับมือกับกรณีขอบได้ดีขึ้น ในมุมมองนี้ ข้อความแจ้ง E_DEPRECATED ที่กรอกบันทึกข้อผิดพลาดของคุณคือ "เหมือนระบบเตือนล่วงหน้าว่าสิ่งต่างๆ จะพังในอนาคต แต่ตอนนี้ยังไม่พัง"

ทำโดยไม่มีคุณสมบัติไดนามิกหลังจาก PHP 8.2

เหตุผลของ Nikita Popov ในการยุติคุณสมบัติไดนามิกใน PHP 9 เป็นตัวอย่างที่ดีของการขับเคลื่อนเชิงวิวัฒนาการของ PHP ไปสู่โค้ดที่ยืดหยุ่นมากขึ้นและรูปแบบการเขียนโปรแกรม:

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

วิดีโอความยาว 2 นาทีของ Brent Roose เกี่ยวกับวิวัฒนาการจาก PHP 5.6 เป็น 8.2 เป็นภาพประกอบที่ชัดเจนและเรียบง่ายซึ่งแสดงให้เห็นว่า PHP มาไกลแค่ไหนตั้งแต่ปี 2014 จนถึงปัจจุบัน การใช้ตัวอย่างของออบเจกต์การถ่ายโอนข้อมูลอย่างง่าย Roose แสดงให้เห็นว่าโค้ด PHP 5.6 ย่อขนาดลงอย่างมากจนเหลือบล็อกโค้ดที่เรียบง่าย ผอมลง และโดยรวมสวยงามยิ่งขึ้นระหว่างทางไปสู่ ​​PHP 8.2 ได้อย่างไร

ดังที่ Roose บันทึกไว้ในเคล็ดลับในการจัดการกับคุณสมบัติไดนามิก (ซึ่งเลิกใช้แล้วใน PHP 8.2) นักพัฒนาควรมีทางวิ่งมากมายเพื่ออัปเดตโค้ดที่มีอยู่ก่อนที่คำเตือนการเลิกใช้งานจะกลายเป็นข้อผิดพลาดร้ายแรง รันเวย์นั้นจะลดลงอย่างรวดเร็ว อย่างไรก็ตาม WordPress เป็นกรณีพิเศษ Tonya Mork มีข้อเสนอที่ยอมรับใน Trac สำหรับการจัดการการเลิกใช้งานคุณสมบัติไดนามิกที่ไม่รู้จักใน WordPress core เธอและ Juliette Reinders Folmer กังวลว่านักพัฒนา WordPress จะมีเวลาไม่เพียงพอในการปรับโครงสร้างรหัสใหม่ ไม่ต้องพูดถึงความท้าทายพิเศษในการรักษาความเข้ากันได้ในอนาคตสำหรับโครงการอายุ 20 ปี Mork, Reinders Folmer และ Sergey Biryukov เป็นฮีโร่ที่ไม่มีใครร้องในงานที่น่ากลัวนี้

ในการอภิปรายเกี่ยวกับคุณสมบัติไดนามิกและวิธีการวิเศษใน PHP 8.2 นั้น Mork และ Reinders Folmer ชี้ให้เห็นว่ารากฐานของ WordPress ใน PHP 3 และ 4 ทำให้มันอยู่ในเอกภพการเขียนโปรแกรมเชิงขั้นตอนที่มั่นคง ในขณะที่ PHP ยังคงพัฒนาต่อไปในฐานะภาษาเชิงวัตถุ นักพัฒนาหลักจำเป็นต้องหาวิธีรักษาพฤติกรรมของโค้ดดั้งเดิมใน PHP ปัจจุบันโดยไม่ทำลายความเข้ากันได้แบบย้อนกลับ “และยังคงทำให้โค้ดดีขึ้นและปลอดภัยยิ่งขึ้น และลดการเลิกใช้คุณสมบัติไดนามิกของ PHP 8.2” ดังที่ Reinders Folmer กล่าว “เรากำลังทำให้ชีวิตของเราลำบากมากจริง ๆ ด้วยกฎการไม่ทำลาย [WordPress core] no [ความเข้ากันได้แบบย้อนกลับ]” เธอกล่าวในวิดีโอ

"มีเหตุผลที่ดี" มอร์คตอบ - "สำหรับผู้ใช้ ผู้ใช้มีความมั่นใจว่าสามารถกดปุ่มนั้นและอัปเกรดได้ และเราคิดถึงความเข้ากันได้แบบย้อนหลังว่าได้ให้ความสำคัญกับมัน เป็นรากฐานที่สำคัญสำหรับเรา … ผู้ใช้จึงสามารถมีความมั่นใจในการอัปเกรด”

การพัฒนาทั้งหมดคือการบำรุงรักษา…

เป็นความท้าทายที่ไม่เหมือนใครในการพยายาม backport PHP ที่ “ทันสมัย” เพื่อทำงานร่วมกับ PHP เวอร์ชันหลักสองเวอร์ชันก่อนหน้าเพื่อรักษาความเข้ากันได้แบบย้อนหลังในคอร์ WordPress นักพัฒนาปลั๊กอินมีงานที่ง่ายกว่ามากในการอัปเดตโค้ดด้วยวิธีที่สามารถใช้ประโยชน์จากคุณสมบัติใหม่ เช่น คลาสแบบอ่านอย่างเดียวของ PHP 8.2 และการเลิกใช้คุณสมบัติไดนามิก งานนี้ส่วนใหญ่เป็นรูปแบบของการบำรุงรักษาด้วย

ในเชิงสถาปัตยกรรม การเปลี่ยนแปลงของ PHP 8+ มุ่งเน้นไปที่แนวคิดการเขียนโปรแกรม เช่น การไม่เปลี่ยนรูป โครงสร้างข้อมูลที่ไม่เปลี่ยนรูป “ไม่ได้แก้ไขปัญหาความปลอดภัยโดยเนื้อแท้” แต่ช่วยให้โค้ดของนักพัฒนาเกิดข้อผิดพลาดน้อยลงและถูกต้องมากขึ้น ตามข้อมูลของ Jacobs:

ฉันจะไม่พูดว่าโครงสร้างข้อมูลที่ไม่เปลี่ยนรูปมีความปลอดภัยโดยกำเนิด และโครงสร้างข้อมูลที่เปลี่ยนแปลงไม่ได้นั้นไม่ปลอดภัย โครงสร้างข้อมูลที่ไม่เปลี่ยนรูปแบบสามารถช่วยลดข้อผิดพลาดในการเขียนโปรแกรมที่อาจนำไปสู่ปัญหาด้านความปลอดภัยได้ การลดจำนวนของสถานะต่างๆ ที่โค้ดของเราสามารถมีอยู่ได้ เราสามารถลดความซับซ้อนของโค้ด และลดโอกาสที่จะเกิดความผิดพลาดได้

เหตุผลที่ดีที่สุดในการรักษาโค้ดให้เป็นมาตรฐานของเวอร์ชัน PHP ที่ได้รับการสนับสนุนคือเพื่อลดความเสี่ยงด้านความปลอดภัย PHP 8.2 นำเสนอสิ่งอำนวยความสะดวกที่เป็นประโยชน์และ “ราวกั้น” ในมุมมองของอดัมส์ แต่เพียงเล็กน้อยที่จะทำให้โปรแกรมเมอร์ตื่นเต้นหรือถูกมองว่าเป็นตัวเปลี่ยนเกม บางอย่าง เช่น แอตทริบิวต์ #[\SensitiveParameter] อาจมีความสำคัญในทางปฏิบัติมากกว่า เนื่องจากอนุญาตให้กรองข้อมูลที่ละเอียดอ่อนออกจากการติดตามสแต็กที่มักจะส่งไปยังบริการของบุคคลที่สาม เปิดตัวใน PHP 8 แอตทริบิวต์เป็นสิ่งที่อดัมส์เลือกสำหรับนวัตกรรมล่าสุดที่ดึงดูดสายตาของเขาสำหรับการเปิดใช้งานบางสิ่งที่คุณไม่สามารถทำได้ก่อนหน้านี้: "อธิบายบางสิ่ง [เช่น คลาส ตัวแปร วิธีการ ฯลฯ] จากมุมมองเมตาดาต้า"

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

…และการบำรุงรักษาทั้งหมดคือศิลปะ

Jeff Atwood มีบล็อกโพสต์เก่าแต่โดดเด่นเรื่อง “The Noble Art of Maintenance Programming” ที่ฉันได้อ่านเมื่อเร็วๆ นี้ ขอบคุณ Kale Davis's Hacker Newsletter Atwood เขียนไว้ว่า "การเขียนโปรแกรมการบำรุงรักษามักถูกมองว่าเป็นงานภารโรง" สิ่งนี้ทำให้ฉันนึกถึงศิลปิน Mirele Laderman Ukeles ผู้ซึ่ง "Maintenance Art Manifesto" ทำให้ฉันนึกถึงการเขียนโปรแกรมและการพัฒนาเว็บไซต์อยู่เสมอ:

สองระบบพื้นฐาน: การพัฒนาและการบำรุงรักษา เปรี้ยวเข็ดฟันทุกการปฏิวัติ หลังปฏิวัติ เช้าวันจันทร์ใครจะเก็บขยะ? […] ระบบการพัฒนาเป็นระบบป้อนกลับบางส่วนที่มีห้องใหญ่สำหรับการเปลี่ยนแปลง ระบบการบำรุงรักษาเป็นระบบป้อนกลับโดยตรงโดยมีพื้นที่น้อยสำหรับการปรับเปลี่ยน

Laderman Ukeles เป็นศิลปินสาวและคุณแม่มือใหม่ในปี 1969 เมื่อเธอเขียนแถลงการณ์และประกาศว่าการบำรุงรักษาคือศิลปะ เธอรู้สึกผิดหวังกับการที่งานศิลปะล้ำสมัยและแรงงานที่มีสถานะสูงถูกแบ่งออกจากงานที่ทำให้พวกเขาเป็นไปได้: การเลี้ยงดูบุตร การสอนทักษะและประเพณีทางศิลปะ หรือเพียงแค่การแสดงศิลปะ เธอจัดแสดงนิทรรศการที่น่าจดจำโดยอิงจากตัวเธอเองที่ทำหน้าที่เป็นภารโรงพิพิธภัณฑ์ จากนั้นเธอใช้เวลาส่วนใหญ่ในอาชีพการงาน (ที่กำลังดำเนินอยู่) ของเธอในฐานะศิลปินในกรมสุขาภิบาลแห่งนครนิวยอร์ก โครงการแรกของเธอในบทบาทนั้นคือการขอบคุณเจ้าหน้าที่สุขาภิบาลทั้งหมด 8,500 คน “ที่ทำให้นิวยอร์กมีชีวิตชีวา”

Atwood มีการเขียนโปรแกรมที่คล้ายกัน เขาอ้างถึงบุคคลสำคัญหลายคนในวิศวกรรมซอฟต์แวร์ที่กล่าวว่าการปฏิเสธงานบำรุงรักษานั้นผิดทั้งหมด Robert L. Glass รู้สึกว่า “การบำรุงรักษาเป็นความท้าทายทางปัญญาที่สำคัญ เช่นเดียวกับการแก้ปัญหา ไม่ใช่ปัญหา” ดังนั้นจึงควรถือเป็นงานที่สำคัญสำหรับผู้ที่มีทักษะมากที่สุด Joel Spolsky เขียนเมื่อนานมาแล้วว่านักพัฒนาขี้เกียจ และเหตุผลที่พวกเขา “ต้องการทิ้งโค้ดและเริ่มต้นใหม่อยู่เสมอ” ก็คือ “การอ่านโค้ดนั้นยากกว่าการเขียน”

ในการสนทนากับ Andy Hunt เดฟ โธมัสแย้งว่า "การเขียนโปรแกรมทั้งหมดคือการเขียนโปรแกรมเพื่อการบำรุงรักษา เพราะคุณไม่ค่อยเขียนโค้ดต้นฉบับ …. คุณใช้เวลาส่วนใหญ่ในโหมดการบำรุงรักษา ดังนั้นคุณอาจกัดกระสุนและพูดว่า “ฉันรักษาตัวตั้งแต่วันแรก” ระเบียบวินัยที่ใช้กับการบำรุงรักษาควรใช้ทั่วโลก” ฮันต์เห็นด้วย “เพียง 10 นาทีแรกเท่านั้นที่โค้ดจะเป็นต้นฉบับเมื่อคุณพิมพ์ในครั้งแรก แค่นั้นแหละ."

ในที่สุด Atwood ก็เอนเอียงไปทางมุมมองนี้ แต่สะท้อนมุมมองนักพัฒนา WordPress ทั่วไปที่ฉันได้ยินจาก Jason Adams และ Timothy Jacobs ศิลปะพิเศษของการพัฒนา / บำรุงรักษา WordPress?

“มันเป็นการกระทำที่สมดุล”

ปลั๊กอินความปลอดภัย WordPress ที่ดีที่สุดเพื่อรักษาความปลอดภัยและปกป้อง WordPress ตอนนี้ลด 35%!

ปัจจุบัน WordPress มีอำนาจมากกว่า 40% ของเว็บไซต์ทั้งหมด ดังนั้นจึงกลายเป็นเป้าหมายที่ง่ายสำหรับแฮ็กเกอร์ที่มีเจตนาร้าย ปลั๊กอิน iThemes Security Pro นำการคาดเดาออกจากความปลอดภัยของ WordPress เพื่อให้ง่ายต่อการรักษาความปลอดภัยและปกป้องเว็บไซต์ WordPress ของคุณ มันเหมือนกับการมีผู้เชี่ยวชาญด้านความปลอดภัยเต็มเวลาเป็นพนักงานที่คอยตรวจสอบและปกป้องไซต์ WordPress ของคุณอย่างต่อเนื่อง

ประหยัด 35% ทันที!