วิทยาศาสตร์เบื้องหลังการย้าย Drupal 7 ถึง 9 ที่ประสบความสำเร็จ (และทำไมบางคนถึงล้มเหลว)

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

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

การอัพเกรด Drupal 7 ถึง 9 - ความท้าทายขั้นพื้นฐาน

คำถามแรกที่คุณอาจถามตัวเองคือ “ทำไม” การอัพเกรดจาก Drupal 7 เป็น Drupal 9 (ตอนนี้ Drupal 8 ได้ถูกยกเลิกไปแล้ว) ดูเหมือนว่าไม่น่าจะยากขนาดนั้นจากมุมมองของแพลตฟอร์ม

Drupal 8 เปลี่ยนแปลงทุกอย่าง มีการยกเครื่องสถาปัตยกรรมที่สมบูรณ์เพื่อให้ CMS มีความยั่งยืน มีความเกี่ยวข้อง และง่ายต่อการใช้งานในระยะยาว การนำเทคโนโลยีและเฟรมเวิร์กที่ทันสมัยมาใช้ เช่น การเขียนโปรแกรมเชิงวัตถุ, Symfony, Twig, เวอร์ชัน PHP ล่าสุด และอื่นๆ (อีกมากมาย) ทำให้ชุมชน Drupal เติบโตแบบทวีคูณโดยรองรับทักษะที่หลากหลายขึ้นเพื่อช่วยสร้าง Drupal ซึ่งหมายความว่า ในตอนนี้ การหาผู้เชี่ยวชาญเพื่อสร้างและดูแลเว็บไซต์ Drupal ของคุณทำได้ง่ายขึ้น ข่าวดีก็คือการอัปเกรดเป็นเวอร์ชันในอนาคตของ Drupal (เช่น Drupal 8 เป็น Drupal 9) หลังจากการโยกย้ายเริ่มต้นนั้นง่ายมากและไม่ต้องสร้างใหม่

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

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

ความท้าทายในการโยกย้าย Drupal 7 ถึง 9 ทั่วไป

หนึ่งในแหล่งที่มาของความหงุดหงิดที่พบบ่อยที่สุดหลังจากการโยกย้าย Drupal 6/7 ถึง 8/9 คือไม่รู้ว่าจะเริ่มต้นที่ไหนเมื่อจัดการกับปัญหา คุณจะรู้ได้อย่างไรว่าปัญหาที่แท้จริงอยู่ที่ใด ทั้งที่มีหรือไม่มีทักษะในการเขียนโปรแกรม ง่าย - ตรวจสอบบันทึกข้อผิดพลาดของคุณ ฉันรู้ ดูเหมือนว่าคุณกำลังเปิดเวิร์มอีกกระป๋องที่พยายามทำความเข้าใจว่าบันทึกพูดอะไร แต่เราจะแนะนำคุณเกี่ยวกับรายการทั่วไปด้านล่าง

มาเจาะลึกปัญหาที่พบบ่อยที่สุดที่เจ้าของไซต์ Drupal เผชิญหลังจากการโยกย้าย Drupal 7 ไปยัง Drupal 9

เว็บแทบไม่ขึ้น / พัง

1. ปัญหาเซิร์ฟเวอร์: เซิร์ฟเวอร์ของคุณอาจถูกบุกรุกได้หากคุณไม่มีสิทธิ์เพียงพอในการเข้าถึงเซิร์ฟเวอร์ของคุณ การตรวจสอบบันทึกข้อผิดพลาดอย่างละเอียดจะช่วยให้คุณเข้าใจว่าปัญหามาจากที่ใด หากเป็นปัญหาของเซิร์ฟเวอร์ ตรวจสอบให้แน่ใจว่าคุณมีสิทธิ์เพียงพอในการเข้าถึงเซิร์ฟเวอร์ของคุณ ติดต่อผู้ให้บริการโฮสติ้งของคุณเพื่อเพิ่มขีดจำกัดหน่วยความจำของคุณ หากคุณประสบปัญหาการขาดแคลนพื้นที่ หากไม่ได้ผล ให้แจ้งตั๋วที่กล่าวถึงปัญหาเซิร์ฟเวอร์ของคุณ
2. รหัสที่กำหนดเอง: หากเว็บไซต์ Drupal 6/7 ของคุณซับซ้อนกว่าที่คาดไว้ มีโอกาสที่แทนที่จะประเมินรหัสที่กำหนดเองและทำแผนที่อย่างถูกต้องก่อนการโยกย้าย จะมีการดำเนินการยกและเปลี่ยนแบบธรรมดา หากคุณมีเงื่อนไขแบบกำหนดเองที่เริ่มทำงานเมื่อหน้าเว็บของคุณโหลดขึ้น และไม่พบรหัสที่กำหนดเองที่เชื่อมโยงอยู่ คุณจะพบกับหน้าที่ใช้งานไม่ได้ สิ่งแรกที่ต้องทำคือตรวจสอบเพื่อดูว่าคุณได้ประเมินเว็บไซต์อย่างถูกต้องหรือไม่ในการตรวจสอบการย้ายข้อมูล (หากคุณทำอย่างใดอย่างหนึ่ง) เพื่อตรวจสอบโมดูลและโค้ดที่กำหนดเอง หากปัญหาเกิดจากเงื่อนไขแบบกำหนดเองและโค้ดหายไป คุณจะต้องให้ผู้พัฒนา Drupal ของคุณสร้างการติดตั้งโค้ดแบบกำหนดเอง ตามหลักการแล้ว โค้ดที่กำหนดเองควรถูกสร้างขึ้นก่อนที่จะมีการย้ายเนื้อหาใดๆ
3. โมดูล Core/Contrib: บางครั้งคุณอาจพบปัญหาที่ทราบในคอร์หรือโมดูลที่สนับสนุนซึ่งมีวิธีแก้ปัญหา/แพตช์อยู่แล้ว การวิจัยเพียงเล็กน้อยสามารถช่วยระบุสิ่งนี้ได้ ค้นหาและใช้โปรแกรมแก้ไขและคุณควรจะดีไป
4. เวอร์ชัน / ไลบรารี PHP ที่ล้าสมัย: ไซต์ Drupal ใหม่ของคุณอาจยังคงใช้ PHP หรือไลบรารีเวอร์ชันเก่าที่โค้ดของคุณใช้อยู่ ตรวจสอบให้แน่ใจว่าเว็บไซต์ของคุณใช้ PHP เวอร์ชันล่าสุดและไลบรารีอื่นๆ ตรวจสอบว่าตรงตามข้อกำหนดและการกำหนดค่าของระบบทั้งหมดหรือไม่

ไม่สามารถแก้ไขเพจได้ (ปัญหาการอนุญาต)

1. ข้อผิดพลาด 500: หากคุณไม่สามารถแก้ไขหน้าเว็บได้เนื่องจากคุณพบข้อผิดพลาด 500 Internal Server อาจเป็นเพราะสาเหตุหลายประการ (การกำหนดค่าผิดพลาด รหัสไม่ถูกต้อง การสร้างดัชนีผิดพลาด การรวม ฯลฯ) อย่างไรก็ตาม สาเหตุทั่วไปประการหนึ่งก็คือ อาจเป็นเพราะรูปแบบช่องไม่ตรงกันหรือช่องที่ขาดหายไป ตัวอย่างเช่น หากฟิลด์วันที่ของคุณจากเว็บไซต์ Drupal 7 ไม่ได้ถูกย้ายในรูปแบบที่ถูกต้อง หรือค่าไม่ได้ถูกแปลงเป็นรูปแบบ Drupal 9 จะเกิดข้อผิดพลาดขึ้น อีกตัวอย่างหนึ่งคือ ถ้าใน Drupal 7 คุณใช้ช่องรูปภาพ แต่ใน Drupal 9 คุณใช้ช่องสื่อแทน วิธีที่ดีที่สุดในการแก้ไขปัญหานี้คือการแก้ไขสคริปต์การย้ายข้อมูลเพื่อจัดเก็บข้อมูลอย่างถูกต้อง หากมีเพียงไม่กี่ฟิลด์ที่ต้องแก้ไข คุณสามารถสร้าง hook update ได้
2. ข้อผิดพลาด 403: บ่อยครั้ง ข้อผิดพลาด 403 เกิดจากการโอนสิทธิ์ที่ไม่ถูกต้อง ตรวจสอบว่าตั้งค่าการอนุญาตอย่างถูกต้องหรือไม่ หากคุณกำลังใช้โมดูลเพื่อจัดการผู้ใช้ของคุณ ให้ตรวจสอบว่ามีอยู่ใน Drupal 9 หรือไม่ บางครั้ง คุณอาจมี hooks หรือสมาชิกเหตุการณ์ที่จำกัดการเข้าถึงสำหรับผู้ใช้บางคน ตรวจสอบเงื่อนไขเหล่านี้และตรวจสอบให้แน่ใจว่ามีการใช้งานในการติดตั้งใหม่ของคุณด้วย
3. หน้าสิทธิ์ไม่ตอบสนอง: ไซต์ Drupal ของคุณอาจใช้รหัสที่กำหนดเองเพื่อจัดการการอนุญาต หากไม่มีการติดตั้งโค้ดนี้ในไซต์ Drupal 9 ใหม่ คุณอาจไม่สามารถดูหรือแก้ไข (หรือทั้งสอง) หน้าสิทธิ์ได้ ในบางครั้ง เราจะเห็นสถานการณ์ที่ผู้ใช้ถูกโยกย้ายเป็นกลุ่มโดยไม่ได้ย้ายบทบาทและโปรไฟล์ผู้ใช้อย่างเหมาะสม ตามหลักปฏิบัติมาตรฐาน ก่อนย้ายการอนุญาต ผู้พัฒนาควรสร้างการอนุญาตแบบกำหนดเองและกำหนดบทบาทจากบุคคล/สิทธิ์

ประสิทธิภาพของเว็บไซต์ที่น่าสังเวช

1. โมดูลที่ไม่จำเป็น: โมดูลเป็นส่วนสำคัญของไซต์ Drupal ของคุณ ดังนั้นคุณจึงต้องการย้ายข้อมูลด้วยเช่นกัน แต่บางครั้งเราเห็นโมดูล Drupal 7 ที่ล้าสมัยที่ย้ายไปที่ Drupal 9 ซึ่งอาจทำให้เกิดปัญหาได้ทุกประเภท โดยเฉพาะอย่างยิ่งเนื่องจากสามารถชั่งน้ำหนักไซต์ของคุณได้ ต่อไปนี้คือสาเหตุบางประการที่คุณไม่จำเป็นต้องย้ายโมดูลบางส่วน:
   • โมดูล (หรือฟังก์ชันการทำงาน) ได้ย้ายไปที่ Drupal Core แล้ว ตัวอย่างเช่น โมดูลที่สนับสนุนสื่อถูกย้ายไปที่แกนกลางใน Drupal 8.5 ซึ่งไม่จำเป็นต้องใช้โมดูลที่สนับสนุน
   • ฟังก์ชันการทำงานนั้นเรียบง่ายและสามารถแทรกลงในโมดูลที่กำหนดเองอื่นได้ ตัวอย่างเช่น หากโมดูล node::postSave ใช้สำหรับเนื้อหาหนึ่งหรือสองประเภทเท่านั้นเพื่อเลือกว่าผู้ใช้ควรไปที่ใดเมื่อสร้างโหนดแล้ว อาจเป็นไปได้ที่จะย้ายโค้ดไปยังโมดูลที่กำหนดเองแทน
   • ข้อกำหนดสำหรับโมดูลจะต้องได้รับการประเมินใหม่ บางครั้ง การเปลี่ยนแปลงเล็กน้อยในการใช้งานสามารถปรับปรุงประสิทธิภาพของเว็บไซต์ได้อย่างมาก ตัวอย่างเช่น เว็บไซต์ทั้งหมดไม่จำเป็นต้องมีโมดูล Content Moderation เว้นแต่ว่าทีมการตลาดเนื้อหามีขนาดใหญ่และกระจาย ฟีเจอร์เวิร์กโฟลว์งานบรรณาธิการหลักของ Drupal (ฉบับร่าง, เผยแพร่) นั้นดีเพียงพอสำหรับความต้องการทางธุรกิจส่วนใหญ่ที่ไม่ต้องการเวิร์กโฟลว์ที่ซับซ้อน/มีรายละเอียด
   • บางครั้ง มีการติดตั้งโมดูลย่อยพร้อมกับโมดูลต่างๆ แต่ไม่ค่อยได้ใช้/ไม่เคยใช้งาน ควรถอดโมดูลย่อยดังกล่าวออก
2. การจำลองสถาปัตยกรรมแบบเดียวกัน: แม้ว่าการยกและเลื่อนและปัดฝุ่นมือออกจากการย้ายข้อมูลจะง่ายกว่า แต่แทบไม่เคยเป็นวิธีที่ดีเลย โดยเฉพาะอย่างยิ่งถ้าสถาปัตยกรรมรุ่นเก่า (Drupal 6/7) นั้นยุ่งเหยิงและแข็งแกร่งน้อยกว่า การเปลี่ยนแปลงตรรกะ/ข้อกำหนดทางธุรกิจอาจจำเป็นต้องมีโครงสร้างใหม่ทั้งหมด การตรวจสอบไซต์อย่างละเอียดจะบอกคุณอย่างชัดเจนว่าโมดูลใดที่ต้องเก็บไว้และสิ่งใดที่สามารถกำจัดได้อย่างปลอดภัย

การรวมระบบของบุคคลที่สามไม่ทำงานอีกต่อไป

1. เวอร์ชัน API ที่ล้าสมัย: หากเว็บไซต์ของคุณเชื่อมต่อกับเครื่องมือของบริษัทอื่น เช่น Salesforce, Marketo, Mailchimp เป็นต้น การย้ายที่ดำเนินการอย่างไม่เหมาะสมอาจส่งผลต่อการทำงานของการผสานรวมเหล่านี้ บ่อยครั้งที่ API ที่คุณเรียกใช้ในโมดูลการรวม Drupal เป็นเวอร์ชันที่เก่ากว่า การแก้ไขอย่างเดียวคือควรเขียนการผสานรวมในเวอร์ชันล่าสุดของ API บุคคลที่สาม
2. ปัญหาเกี่ยวกับโมดูลการรวม: คุณจะต้องตรวจสอบว่ามีการเรียก API ของบุคคลที่สามในโมดูลการรวมอย่างถูกต้องหรือไม่ พารามิเตอร์ถูกส่งผ่านไปอย่างเหมาะสมหรือไม่? ตรวจสอบว่ามีการตั้งค่าและดึงข้อมูลอย่างไร ตรวจสอบคิวปัญหาสำหรับโมดูลการรวมนั้น อาจมีโปรแกรมแก้ไขที่จำเป็นต้องใช้ ต้องทำการทดสอบอย่างเหมาะสมเพื่อให้แน่ใจว่า API ถูกย้ายไปยัง Drupal 9 อย่างถูกต้อง

ปัญหาทั่วไปและการแก้ไขอื่นๆ

1. การติดตั้งโมดูล: ใช้ผู้แต่งเพื่อติดตั้งโมดูลเสมอ สิ่งนี้จะหลีกเลี่ยงข้อผิดพลาดเนื่องจากการขึ้นต่อกันที่ไม่ถูกต้อง/ไม่พร้อมใช้งาน
2. แหล่งที่มาของ การย้ายข้อมูลไม่ตรงกัน: ไม่ว่าแหล่งที่มาของการย้ายข้อมูลของคุณคืออะไร (CSV, ฐานข้อมูล, JSON, XML) ตรวจสอบให้แน่ใจว่าฟิลด์ต้นทางตรงกับฟิลด์ปลายทาง หากคุณกำลังใช้ CSV เป็นแหล่งที่มาของคุณ โปรดคำนึงถึงลำดับการนำเข้า - ลำดับความสำคัญมีความสำคัญสำหรับการแมปประเภทเนื้อหา
3. เส้นทางของรูปภาพ: หลายครั้งที่ผู้ใช้เพิ่มรูปภาพโดยตรงภายในเนื้อหา CKEditor ภาพเหล่านี้ไม่ได้ไปยังเส้นทางที่กำหนดเสมอไปเมื่อย้ายข้อมูล เนื่องจากโดยปกติแล้วตำแหน่งของภาพจะแตกต่างจากตำแหน่งที่มีไฟล์สื่ออื่นๆ การย้ายถิ่นที่วางแผนไว้อย่างพิถีพิถันควรดูแลปัญหานี้
4. SEO: การโยกย้าย Drupal 7 ถึง 9 ที่ประมาทอาจส่งผลกระทบต่อ SEO ของเว็บไซต์ของคุณได้หลายวิธี ปัญหาที่สำคัญที่สุดประการหนึ่งคือลิงก์เสีย ตรวจสอบให้แน่ใจว่าโครงสร้าง URL และการนำทางที่มีอยู่ได้รับการเก็บรักษาไว้ เนื่องจากการเปลี่ยนแปลงใดๆ อาจนำไปสู่ลิงก์เสียจำนวนมาก ต้องทำการตรวจสอบ SEO อย่างสมบูรณ์เพื่อให้แน่ใจว่าไม่มีสิ่งกีดขวางบนถนน
5. สไตล์ Drupal 7: ปัญหาการโยกย้าย Drupal 7 ถึง Drupal 9 บ่อยครั้ง (โดยเฉพาะปัญหาด้านประสิทธิภาพ) เกิดขึ้นเนื่องจากนักพัฒนาใช้รูปแบบการเข้ารหัสแบบเดียวกับ Drupal 7 แทนที่จะปรับให้เข้ากับการเปลี่ยนแปลงที่เกิดจาก Drupal 8 ตัวอย่าง (ก) วิธีที่คุณฆ่า แคชของหน้าแตกต่างกันมากใน Drupal 8 (b) Drupal 8 มีการจัดการการกำหนดค่าในตัว แต่มักไม่ได้ใช้งานอย่างถูกวิธีหรือได้รับการดูแลอย่างดีในทุกสภาพแวดล้อม (c) นอกจากนี้เรายังพบกรณีที่โครงการ Drupal 8 ยังคงใช้รูปแบบรหัสขั้นตอน