บันทึกวิศวกรรม

วินิจฉัย plugin conflict ใน WordPress โดยไม่เดา

แยกความขัดแย้งอย่างเป็นระบบโดยรักษาหลักฐานและลดความเสี่ยงบน production

การปิดปลั๊กอินแบบสุ่มจน symptom หายไม่ใช่การแก้ conflict เป้าหมายคือเข้าใจว่าการโต้ตอบใดล้มเหลวและเพราะอะไร

ถ้าปิดปลั๊กอินอาจกระทบ checkout login ฟอร์ม หรืองานตามเวลา ควรใช้ staging

1. กำหนดอาการให้แม่น

บันทึก action หน้าเว็บ user role request และ error ก่อนเปลี่ยนสแต็ก

2. ตรวจ log และการเปลี่ยนแปลงล่าสุด

การเปลี่ยน version, PHP upgrade และ config มักช่วยลดขอบเขตที่สงสัยได้เร็ว

3. แยกทีละขอบเขต

คงสภาพแวดล้อมส่วนอื่นไว้และปิดหรือแทนที่องค์ประกอบที่สงสัยเพียงหนึ่งตัว

4. ทดสอบ interaction ไม่ใช่แค่แต่ละ plugin

ปลั๊กอินแต่ละตัวอาจทำงานปกติลำพัง แต่ชนกันผ่าน hook script การเขียนฐานข้อมูล หรือ dependency ร่วม

5. อย่าจบด้วยการแก้ vendor code โดยตรง

การแก้ตรงจะหายเมื่ออัปเดตและทำให้ครั้งต่อไปวิเคราะห์ยากขึ้น ควรใช้ hook compatibility layer หรือ upstream fix

6. ทดสอบ user flow เดิมอีกครั้ง

หลังแก้ ให้ทำ action ที่เคยล้มเหลวซ้ำ และตรวจ flow ที่ใช้ hook หรือข้อมูลเดียวกัน