10 เคล็ดลับในการทำให้การบำรุงรักษา WordPress ราบรื่น

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

เหตุใดการดูแล WordPress ที่เหมาะสมจึงสำคัญ

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

ในกรณีหลัง สิ่งต่าง ๆ มักจะไม่ราบรื่นสำหรับนักพัฒนาที่เข้ามา โดยเฉพาะอย่างยิ่งหากนักพัฒนาก่อนหน้านี้ไม่ปฏิบัติตามแนวทางปฏิบัติที่ดีที่สุดเมื่อจัดการงานบำรุงรักษาของตน

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

1. สำรองข้อมูล!

นี่อาจฟังดูชัดเจนเกินไป แต่อย่างแรกเลย! คุณต้องสำรองข้อมูลไซต์ WordPress ของคุณอย่างถูกต้องและสม่ำเสมอ

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

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

2. ติดตั้งไซต์ WordPress ของคุณในเครื่อง

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

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

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

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

3. ไป Git

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

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

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

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

4. ลบไฟล์ โค้ด และปลั๊กอินที่ไม่จำเป็น

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

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

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

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

5. แสดงความคิดเห็น

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

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

ควรเพิ่มความคิดเห็นเมื่อใดก็ตามที่ฟังก์ชัน/คลาสหรือบล็อกโค้ดไม่ชัดเจน ให้ใช้ฟังก์ชันต่อไปนี้ ตัวอย่างเช่น

 function stripWhiteSapaces(str) { … Return str; }

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

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

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

6. ผ้าสำลี

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

ตัวอย่างเช่น เมื่อใช้ Visual Studio Code เป็น IDE ของคุณ VS Code จะใช้ PHP linter ( php -l ) อย่างเป็นทางการสำหรับการวินิจฉัยภาษา PHP คุณสามารถกำหนดค่ากฎ/ข้อจำกัดสำหรับแต่ละภาษาแยกกันได้ (เช่น PHP, JavaScript, CSS เป็นต้น) คุณสามารถดูรายละเอียดเพิ่มเติมที่ WordPress Coding Standards

• https://make.wordpress.org/core/handbook/best-practices/coding-standards/php/
• https://make.wordpress.org/core/handbook/best-practices/coding-standards/javascript/

เมื่อคุณมีการกำหนดค่าผ้าสำลีแล้ว คุณจะต้องบังคับใช้ นักพัฒนาปัจจุบันและอนาคตของคุณทั้งหมดจำเป็นต้องรวมการกำหนดค่า linting นี้กับ IDE ของตน เพื่อให้โค้ดของพวกเขาปฏิบัติตามกฎ/ข้อจำกัดเดียวกัน มิฉะนั้น ความพยายามส่วนใหญ่ของคุณจะสูญเปล่า

7. ตัวแปรและการตั้งชื่อไฟล์

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

พิจารณาประเด็นสำคัญบางประการ:

1. หลีกเลี่ยงชื่อที่ชัดเจน
2. ให้สั้นเมื่อเป็นไปได้
3. บางครั้งการผนวก "type" ต่อท้ายชื่อไฟล์ก็มีประโยชน์มาก ตัวอย่างเช่น หากเป็นไอคอน คุณสามารถมีบางอย่างเช่น BlackArrowIcon.png หรือหากเป็นภาพพื้นหลังขนาดใหญ่ อาจเป็นเช่น FrontYellowBG.jpg หรือถ้าเป็นไฟล์โค้ด บางครั้งก็ง่ายที่จะรู้ว่าไฟล์นั้นย่อมาจากอะไรเมื่อทำงานกับไฟล์หลายไฟล์ที่เปิดอยู่ในแท็บต่างๆ ใน ​​IDE ตัวอย่างเช่น ถ้ามีคลาสที่มีฟังก์ชันตัวช่วย มันจะมีประโยชน์ถ้าชื่อ HelperClass.php แทนที่จะเป็น Helper.php

สำหรับข้อมูลเพิ่มเติม โปรดดูที่ส่วน Naming Conventions ในคู่มือแนวทางปฏิบัติที่ดีที่สุดของ WordPress

8. WordPress Debugging

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

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

• Kint Debugger
• แถบดีบัก
• ตรวจสอบแบบสอบถาม

9. มี CSS . ที่ดีกว่า

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

หากคุณสนใจที่จะทราบข้อมูลเพิ่มเติมว่าทำไมเทคนิคการจัดแต่งทรงผมที่ค่อนข้างพื้นฐานนี้จึงมีแนวโน้มที่จะเกิดปัญหา คุณสามารถ Google ได้ว่าทำไม CSS จึงน่ารำคาญ หรืออ่านเพิ่มเติมเกี่ยวกับ 5 สิ่งที่น่ารำคาญที่สุดด้วย CSS

ต่อไปนี้คือเคล็ดลับสั้นๆ จากฝั่งของฉันโดยไม่มีรายละเอียดมากนัก:

• บังคับใช้แนวทางการตั้งชื่อที่ดี ใช้วิธีการตั้งชื่อเช่น BEM (Block Element Modifier)
• หลีกเลี่ยงการใส่สไตล์อินไลน์ ใช้สไตล์ชีตภายนอกแทน
• พยายามสร้างรูปแบบที่ใช้ซ้ำได้ทั่วไปทุกครั้งที่ทำได้ โดยไม่ต้องเพิ่มสไตล์เมื่อจำเป็น
• แบ่งสไตล์ออกเป็นหลายไฟล์ตามคุณสมบัติหรือพื้นที่ของเว็บไซต์ หากคุณกังวลว่าจำนวนไฟล์รูปแบบที่สูงขึ้นอาจส่งผลต่อประสิทธิภาพการโหลด คุณสามารถแก้ปัญหานี้ได้โดยใช้ปลั๊กอินแคชที่ดี ซึ่งจะรวมไฟล์หลายไฟล์เป็นไฟล์เดียว
• ใช้ประโยชน์จากตัวประมวลผลล่วงหน้า CSS เช่น SASS, LESS และอื่นๆ

10. รับคำติชมจากนักพัฒนาปัจจุบัน

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