12 ข้อผิดพลาดที่แย่ที่สุดที่นักพัฒนา WordPress ขั้นสูงทำ

WordPress เป็นวิธีที่ได้รับความนิยมอย่างมากในการทำให้ไซต์ทำงานได้อย่างรวดเร็ว อย่างไรก็ตาม ในความเร่งรีบ นักพัฒนาจำนวนมากลงเอยด้วยการตัดสินใจที่น่ากลัว ข้อผิดพลาดบางอย่าง เช่น ปล่อยให้ WP_DEBUG ตั้งค่า true อาจทำได้ง่าย อื่นๆ เช่นการรวม JavaScript ทั้งหมดของคุณเป็นไฟล์เดียว เป็นเรื่องปกติเหมือนกับวิศวกรที่ขี้เกียจ ไม่ว่าคุณจะทำผิดพลาดประการใด อ่านต่อไปเพื่อค้นหาข้อผิดพลาดที่พบบ่อยที่สุด 12 ข้อของ WordPress ที่นักพัฒนาใหม่และมีประสบการณ์ หากคุณพบว่าตัวเองทำผิดพลาดอย่างใดอย่างหนึ่ง อย่าสิ้นหวัง ความผิดพลาดแต่ละครั้งคือโอกาสในการเรียนรู้

1. วางโค้ด JavaScript ของธีม WordPress ลงในไฟล์หลักเดียว

ครั้งหนึ่ง ขณะทำการเพิ่มประสิทธิภาพความเร็วหน้าเว็บสำหรับเว็บไซต์ของลูกค้า ฉันสังเกตว่าพวกเขากำลังใช้ธีมระดับพรีเมียมที่มีไลบรารีทั้งหมดที่พวกเขาใช้อยู่ รวมถึงโค้ดที่กำหนดเองในไฟล์เดียวชื่อ main.js , theme.js หรือ custom.js . การปฏิบัตินี้ไม่ดีด้วยเหตุผลดังต่อไปนี้:

1. ไฟล์สามารถขยายใหญ่ได้ทันเวลาตามธีม โดยได้รับการพัฒนาอย่างจริงจัง และจะเติบโตในฟีเจอร์ต่างๆ และบางครั้งคุณจะเห็นไฟล์ขนาดใหญ่ถึง 1 MB ไฟล์จะถูกโหลดทั่วทั้งไซต์ แม้ว่าบางหน้าจะต้องการโค้ดเพียง 10% จากไฟล์ก็ตาม ซึ่งจะทำให้หน้าดาวน์โหลดนานขึ้นและแสดงผลช้าลง โดยเฉพาะอย่างยิ่งหากแสดงโค้ดการบล็อกในส่วนหัวของหน้า
2. ทำให้การจัดการโค้ดภายในไฟล์ทำได้ยากขึ้น เนื่องจากคุณไม่สามารถใช้ฟังก์ชันต่างๆ เช่น wp_dequeue_script() เพื่อยกเลิกการโหลดโค้ดบางส่วนในบางหน้า เพื่อปรับปรุงความเร็วของเพจหรือเพื่อป้องกันความขัดแย้งกับโค้ด JavaScript อื่นๆ ที่อาจเป็นไปได้ โหลดโดยหนึ่งในปลั๊กอินที่ใช้งานอยู่ แน่นอนว่า ไฟล์สามารถแบ่งออกเป็นหลายไฟล์และจัดคิวใน WordPress ได้ แต่ถ้าในเวลาต่อมา ผู้ดูแลเว็บไซต์ทำการอัปเดตไฟล์ main.js ของธีม กระบวนการทั้งหมดจะต้องเริ่มต้นใหม่ทั้งหมด

2. การใช้ชื่อที่ธรรมดาเกินไปสำหรับตัวแปร ฟังก์ชัน ค่าคงที่ หรือคลาส

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

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

1. การชนกันของชื่อระหว่างโค้ดที่สร้าง และ PHP ภายใน หรือบุคคลที่สาม คลาส ฟังก์ชัน หรือค่าคงที่
2. ความสามารถในการใช้นามแฝง (หรือย่อ) Extra_Long_Names ออกแบบมาเพื่อแก้ไขปัญหาแรกหรือปรับปรุงความสามารถในการอ่านซอร์สโค้ด อันนี้เป็นสิ่งที่ฉันโปรดปรานเพราะฉันมักจะพัฒนาธีมหรือปลั๊กอินที่มีโค้ดจำนวนมาก ด้วยวิธีนี้ ฉันสามารถอ่านและจัดการโค้ดได้อย่างง่ายดายโดยไม่ต้องกังวลเรื่องชื่อยาวที่ไม่ซ้ำกัน

ฉันขอแนะนำความเข้าใจที่ดีเกี่ยวกับเนมสเปซก่อนที่จะใช้เนมสเปซ เนื่องจากเนมสเปซมักนำไปใช้ในทางที่ผิด

ขึ้นอยู่กับโปรเจ็กต์ที่คุณจะเข้าร่วม มีแนวโน้มว่าคุณจะต้องยึดติดกับรูปแบบการเขียนโค้ดที่มีอยู่ เว้นแต่งานของคุณส่วนใหญ่จะแยกจากแบบที่มีอยู่ ในกรณีที่คุณต้องขยายปลั๊กอินหรือธีมที่มีอยู่ซึ่งเป็นไปตามมาตรฐานการเข้ารหัส PHP สำหรับ WordPress แล้ว วิธีที่ดีที่สุดคือยึดติดกับปลั๊กอินเหล่านี้เพื่อให้มีสไตล์ที่สอดคล้องกันเพื่อให้โค้ดสะอาดและอ่านง่าย โปรดทราบว่ามีการนำกฎบางอย่างไปใช้ในระดับสากลเพื่อปรับปรุงประสิทธิภาพโดยไม่คำนึงถึงรูปแบบการเข้ารหัส ตัวอย่างเช่น ควรใช้อัญประกาศเดี่ยว (แทนที่จะเป็นอัญประกาศคู่) เสมอ หากคุณไม่ได้ประเมินสิ่งใดในสตริง นอกจากนี้ โค้ดจะต้องเยื้องเพื่อให้สามารถอ่านได้ โดยเฉพาะอย่างยิ่งหากมีโค้ดที่ซ้อนกัน (เช่น IF s ภายใน IF s, FOREACH s และ FOR s ที่ซ้อนกัน)

3. ไม่ใช้ฟังก์ชันหลักของ WordPress ที่มีอยู่เพื่อศักยภาพที่แท้จริง

เนื่องจาก WordPress มาพร้อมกับชุดไลบรารีที่อัปเดตเป็นประจำซึ่งสามารถเรียกได้ในปลั๊กอินและธีมของเรา วิธีที่ดีที่สุดคือใช้ประโยชน์จากฟังก์ชันหลักที่มีอยู่ให้มากที่สุด ฉันเคยเห็นธีมและปลั๊กอินของ WordPress ที่มีไฟล์อยู่ในไดเรกทอรีทรัพย์สินซึ่งมีอยู่แล้วในไฟล์หลักของ WordPress (เช่น jQuery หรือ Color Picker) นอกจากความจริงที่ว่าแพ็คเกจจะใหญ่ขึ้นและใช้เวลาในการโหลดบนเครือข่ายนานขึ้น คุณยังต้องตรวจสอบให้แน่ใจว่าไลบรารีของบุคคลที่สามทั้งหมดได้รับการอัปเดตเป็นประจำ ซึ่งเป็นอีกสิ่งหนึ่งที่ต้องดูแล

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

4. ไม่ทำให้ปลั๊กอินหรือธีมเปลี่ยนแปลงได้ง่ายผ่านการดำเนินการและตัวกรอง

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

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

5. การพัฒนาด้วย WP_DEBUG ตั้งค่า false

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

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

6. การเขียนโค้ด PHP โดยไม่คำนึงว่าเพจจะถูกแคชในหนึ่งวัน

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

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

หากไคลเอนต์ของคุณติดตั้งปลั๊กอินที่แคชหน้า (เช่น W3 Total Cache หรือ WP Rocket) โดยไม่เรียกเงื่อนไขในธีมหรือปลั๊กอินของคุณ โค้ด PHP ของคุณจะแสดงผลไร้ประโยชน์ หากมีจุดประสงค์เพื่อให้หน้าเว็บตอบสนอง ก็ควรทำในส่วนหน้าผ่านการสืบค้นสื่อและ JavaScript อย่างหลังก็ต่อเมื่อจำเป็นจริงๆ ตามหลักการแล้ว คุณต้องการหลีกเลี่ยงการใช้ JavaScript เพื่อทำให้ไซต์ของคุณตอบสนอง

7. ไม่ติดตามการเปลี่ยนแปลงที่ทำอย่างมืออาชีพผ่านระบบควบคุมเวอร์ชัน เช่น Git

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

แม้ว่าในช่วงเริ่มต้นอาจดูน่ากลัว โดยเฉพาะอย่างยิ่งสำหรับนักพัฒนารุ่นเยาว์ การทำความเข้าใจ Git จะคุ้มค่าเวลา และซอฟต์แวร์ Git GUI เช่น SourceTree (หนึ่งในรายการโปรดของฉัน) เป็นเพียงวิธีที่คุณโต้ตอบกับที่เก็บ Git ของคุณ เส้นโค้งการเรียนรู้ที่สนุกสนานมากขึ้น เมื่อคุณเข้าใจวิธีการทำงานแล้ว ให้พิจารณาตรวจสอบ Git Best Practices and Tips โดย Toptal Developers ซึ่งจะอธิบายอย่างละเอียดมากขึ้นเกี่ยวกับวิธีการใช้งาน Git

8. การจัดคิวไฟล์ CSS และ JavaScript เมื่อไม่ต้องการ

การมีคำขอ HTTP จำนวนมากจะทำให้เว็บไซต์โหลดช้าลง จึงมีคะแนนที่ต่ำกว่าใน Google PageSpeed ​​ซึ่งอาจส่งผลต่อการจัดอันดับการค้นหา นอกจากนี้ยังอาจนำไปสู่ข้อผิดพลาด JavaScript เนื่องจากข้อขัดแย้งระหว่างปลั๊กอิน ตัวอย่างเช่น อาจมีปลั๊กอินสองตัวที่ใช้ไลบรารี jQuery ทั่วไป ซึ่งอาจโหลดสองครั้งและอาจทำให้เกิดปัญหาได้ และนี่คือตัวอย่างที่ดีที่สุด เนื่องจาก jQuery มักจะโหลดบนเว็บไซต์สดหลายครั้ง สิ่งนี้อาจเกิดขึ้นเนื่องจากปลั๊กอินหรือธีมที่เขียนไม่ดี

9. การใช้ไฟล์ .php เพื่อแสดงผล CSS หรือโค้ด JavaScript แทนไฟล์ .css และ . .js แบบสแตติก

ฉันเคยเห็นธีมและแม้แต่ปลั๊กอิน WordPress ที่มีไฟล์เช่น style.php ที่ใช้เพื่อสร้างโค้ด CSS ที่กำหนดเองและพิมพ์ออกมา สิ่งต่างๆ เช่น สี ขนาดฟอนต์ และระยะห่างรอบองค์ประกอบ ถูกตั้งค่าในการตั้งค่าของธีม จากนั้นจึงบันทึกลงในฐานข้อมูล จากนั้นอ่าน style.php (เช่น <link rel='stylesheet' type='text/css' href='css/style.php?ver=1' /> ) และสร้างโค้ด CSS ตามการตั้งค่าแบบกำหนดเองที่ ได้รับการปรับปรุงในแดชบอร์ด

นี่เป็นแนวทางปฏิบัติที่ไม่ดีในแง่ของประสิทธิภาพของ WordPress นี่คือข้อเสียเปรียบหลักที่มาพร้อมกับมัน:

1. เนื่องจากไฟล์ CSS กำลังโหลดภายในแท็ก head (ซึ่งเป็นเรื่องปกติและส่วนใหญ่โหลดในลักษณะนี้) จึงมีปัญหาด้านประสิทธิภาพที่มาพร้อมกับสิ่งนี้ เนื่องจากเบราว์เซอร์ต้องดาวน์โหลดไฟล์ทั้งหมดก่อนที่จะแสดงหน้าเว็บ หากสภาพแวดล้อมของ WordPress ช้าเนื่องจากปลั๊กอินบางตัว จะทำให้เวลาในการโหลดช้าลงอย่างมาก แม้ว่าจะใช้เทคนิคการแคชหรือโหลดเพียงบางส่วนของสภาพแวดล้อม WordPress เพื่อดึงค่าจากฐานข้อมูล ทางที่ดีควรใช้ไฟล์ .css แบบคงที่แทน
2. ในไฟล์ PHP นักพัฒนาซอฟต์แวร์จะอ่านโค้ด (กฎ CSS ผสมกับตัวแปร PHP และประโยคเงื่อนไข) ได้ยากขึ้นเมื่อต้องตรวจสอบบางอย่าง แน่นอน ไฟล์สามารถเรียกใช้ในเบราว์เซอร์ได้ (แม้ว่าฉันแน่ใจว่าเมื่อมันถูกพิมพ์ มันจะไม่เยื้องหรือดูดี) แต่ถ้าคุณมีสำเนาของโครงการในเครื่องและเรียกดูโค้ดของธีมและคุณต้องการ เพื่อค้นหารูปแบบ CSS หรือ JavaScript (ในกรณีที่จะใช้ script.php) จะทำให้อ่านง่ายขึ้น

วิธีแก้ไข: บันทึก CSS ที่กำหนดเองนอกไดเรกทอรีปลั๊กอิน ตัวอย่าง: /wp-content/uploads/theme-name-custom-css/style-5.css ด้วยวิธีนี้ ในกรณีที่ธีมหรือปลั๊กอินได้รับการอัปเดต ไฟล์ที่กำหนดเองจะไม่สูญหาย

10. ไม่ใช้สถาปัตยกรรมที่ถูกต้อง (Code Organisation) สำหรับปลั๊กอินและธีมของ WordPress

ขึ้นอยู่กับขนาดและลักษณะของปลั๊กอิน (เช่น ปลั๊กอินแบบสแตนด์อโลนหรือส่วนขยายปลั๊กอินที่ทำงานเฉพาะเมื่อเปิดใช้งานปลั๊กอินหลัก เช่น WooCommerce) ต้องตั้งค่าสถาปัตยกรรมและการจัดระเบียบโค้ดที่เหมาะสม

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

หากปลั๊กอินจะมีคุณลักษณะที่มีโค้ดจำนวนมาก การใช้วิธีการเข้ารหัส Objected Oriented Programming (OOP) (มีคลาสจำนวนมาก) ก็สมเหตุสมผล ตัวอย่างเช่น หากคุณมีรหัสย่อจำนวนมาก คุณสามารถเก็บมันไว้ในไฟล์คลาสที่แยกจากกัน เช่น class.shortcodes.php หรือมีไฟล์ CSS และ JavaScript ที่ควรโหลดภายในแดชบอร์ดและมุมมองส่วนหน้า จากนั้นคลาสหนึ่งเช่น class.scripts.php สามารถใช้และจัดคิวไฟล์ front-end ภายในวิธีการเช่น enqueue_public_scripts() ในขณะที่จัดคิวไฟล์ที่ต้องการโหลดในพื้นที่ผู้ดูแลระบบภายใน enqueue_admin_scripts()

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

ตามคู่มือปลั๊กอิน WordPress ในขณะที่มีรูปแบบสถาปัตยกรรมที่เป็นไปได้จำนวนมาก พวกเขาสามารถจัดกลุ่มกว้าง ๆ ได้เป็นสามรูปแบบ:

• ไฟล์ปลั๊กอินเดี่ยวที่มีฟังก์ชั่น
• ไฟล์ปลั๊กอินเดี่ยว ที่มีคลาส อ็อบเจ็กต์ที่สร้างอินสแตนซ์ และตัวเลือก ฟังก์ชัน
• ไฟล์ปลั๊กอินหลัก ตามด้วยไฟล์คลาสหนึ่งไฟล์ขึ้นไป

11. ไม่ใช้การรักษาความปลอดภัย WordPress อย่างจริงจังเมื่อเขียนโค้ด

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

เคล็ดลับด้านความปลอดภัยที่สำคัญที่สุดบางประการ ได้แก่

ช่องโหว่ XSS: เพื่อหลีกเลี่ยงสิ่งนี้ ต้องทำสองสิ่ง: ล้างข้อมูลอินพุตและล้างข้อมูลเอาต์พุต ขึ้นอยู่กับข้อมูลและบริบทที่ใช้ใน WordPress มีหลายวิธีในการฆ่าเชื้อโค้ด ไม่ควรเชื่อถือข้อมูลที่ป้อนหรือข้อมูลใด ๆ ที่จะพิมพ์ ฟังก์ชันทั่วไปอย่างหนึ่งสำหรับการป้อนข้อมูลฆ่าเชื้อคือ sanitize_text_field() โดยจะตรวจสอบอักขระ UTF-8 ที่ไม่ถูกต้อง แปลงอักขระ < ตัวเดียวเป็นเอนทิตี HTML ถอดแท็กทั้งหมด ลบการขึ้นบรรทัดใหม่ แท็บ และพื้นที่สีขาวพิเศษและสตริปออคเต็ต สำหรับการพิมพ์ข้อมูล ตัวอย่างที่ดีในการส่งออกลิงก์คือ esc_url() ซึ่งปฏิเสธ URL ที่ไม่ถูกต้อง กำจัดอักขระที่ไม่ถูกต้อง และลบอักขระอันตราย

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

 // Exit if accessed directly if ( ! defined( 'ABSPATH' ) ) exit;

หากไม่ได้กำหนด ABSPATH คงที่ (ซึ่งควรสำหรับการติดตั้ง WordPress ใดๆ) สคริปต์จะหยุดทำงานและไม่พิมพ์อะไรเลย

ใช้ Nonces: ตามที่ระบุไว้ในเอกสารประกอบของ WordPress Nonce คือ "ตัวเลขที่ใช้ครั้งเดียว" เพื่อช่วยปกป้อง URL และรูปแบบจากการใช้ในทางที่ผิดบางประเภท เป็นอันตรายหรืออย่างอื่น

ตัวอย่างเช่น URL ต่อไปนี้ภายในแดชบอร์ดจะถูกใช้เพื่อทิ้งโพสต์: http://example.com/wp-admin/post.php?post=123&action=trash —เมื่อเข้าถึง URL นี้ WordPress จะตรวจสอบข้อมูลคุกกี้การรับรองความถูกต้อง และหากคุณมีสิทธิ์ที่ถูกต้อง (เช่น คุณเป็นผู้ดูแลระบบที่มีสิทธิ์ทั้งหมด) โพสต์นั้นจะถูกลบ

สิ่งที่ผู้โจมตีสามารถทำได้คือทำให้เบราว์เซอร์ของคุณเข้าถึง URL นั้นโดยที่คุณไม่รู้ตัวโดยการสร้างลิงก์บนหน้าของบุคคลที่สามดังในตัวอย่างต่อไปนี้: <img src="http://example.com/wp-admin/post.php?post=123&action=trash" /> เมื่อส่งคำขอไปยัง WordPress เบราว์เซอร์จะแนบคุกกี้การรับรองความถูกต้องของคุณโดยอัตโนมัติ และ WordPress จะถือว่าคำขอนั้นถูกต้อง

นั่นคือเมื่อมี nonce เข้ามาเนื่องจากผู้โจมตีจะไม่สามารถรับค่า nonce (สร้างขึ้นสำหรับผู้ดูแลระบบที่เข้าสู่ระบบ WordPress จริง ๆ ) ได้อย่างง่ายดาย URL คำขอใหม่จะมีลักษณะดังนี้: http://example.com/wp-admin/post.php?post=123&action=trash&_wpnonce=b192fc4204

หากไม่มี nonce ที่ถูกต้อง การตอบกลับ 403 Forbidden จะถูกส่งไปที่เบราว์เซอร์โดย WordPress พร้อมข้อความแสดงข้อผิดพลาดที่เป็นที่รู้จัก: “คุณแน่ใจหรือไม่ว่าต้องการทำสิ่งนี้”

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

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

12. การใช้ฟังก์ชัน WordPress และตัวอย่างโค้ดโดยไม่เข้าใจ

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

ฉันเคยเห็นแนวทางปฏิบัตินี้หลายครั้งแล้วที่ส่วนย่อยของโค้ดถูกคัดลอกภายในสคริปต์ PHP เมื่อมีการใช้งานจริงเพียงหนึ่งในสามของโค้ดนั้น

สิ่งนี้อาจมีข้อเสียบางประการ ได้แก่ :

1. รหัสไม่ได้ใช้รูปแบบเดียวกับรหัสโครงการที่มีอยู่ ใช่ มันสะดวกที่จะคัดลอกและวางตัวอย่างข้อมูลที่ใช้งานได้จริง และถึงแม้สิ่งเหล่านี้จะดีสำหรับโครงการส่วนตัวเล็กๆ ไปจนถึงงานเชิงพาณิชย์ที่ต้องรักษาความสม่ำเสมอของสไตล์ไว้
2. แม้ว่าโค้ดจะทำหน้าที่ของมัน แต่อาจมีฟังก์ชันที่ไม่มีประสิทธิภาพที่ไม่แนะนำสำหรับงานที่ต้องทำให้สำเร็จ หากโค้ดไม่ได้รับการปรับให้เหมาะสม แนวทางปฏิบัติ "คัดลอกและวาง" นี้อาจส่งผลให้ดูแลเว็บไซต์ได้ช้าและยากขึ้น โดยเฉพาะอย่างยิ่งหากมีการใช้ตัวอย่างมากกว่าหนึ่งรายการในสถานที่ต่างๆ ภายในโปรเจ็กต์
3. รหัสอาจไม่ได้รับอนุญาตให้ใช้ซ้ำ และการรวมรหัสในโครงการของลูกค้าอาจทำให้เกิดปัญหาทางกฎหมายได้มากมาย

การปรับปรุงอย่างต่อเนื่อง

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

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